What's the smallest CIDR block Sprint will listen to from an external source in the 207.x.x.x-208.x.x.x range? Is it different than the filters on > /19s in 206.x.x.x-207.x.x.x range? Avi
-----BEGIN PGP SIGNED MESSAGE-----
"Avi" == Avi Freedman <freedman@netaxs.com> writes:
Avi> What's the smallest CIDR block Sprint will listen Avi> to from an external source in the Avi> 207.x.x.x-208.x.x.x range? Is it different than Avi> the filters on > /19s in 206.x.x.x-207.x.x.x Avi> range? - From non-customer BGP peerings we listen to /19s in 206/8. We listen to /18s in 207/8 to the top of the IPv4 unicast space. The nanog email archive should have lots more detail for you. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMM5g4kSWYarrFs6xAQH5/gQAo+8wnZB6X2GVx4ow9ISd/cMsw+2OOYuB NWIo/G6zms7g5GtCabGtlwy8w8xaQnjEI4EIgfBnwm1jyu+QNXNpLkjAfreUt36H NAuNp2y++wzTvTuD8fgyqropx0TlOAP4Z3fV69tNKvqyqkqUcCazN7YyRK4tq+el Ry3KTeVgGgc= =xM6+ -----END PGP SIGNATURE-----
MCI aggregates all its customer's routes into /19's. We have just received our first block of address space from the 207.x.x.x range. If you continue to filter at /18's for the 207.x.x.x range, you won't be able to reach all of MCI's customers. Needless to say MCI would appreciate it if you'd change your policy to be /19's, and I'm sure Sprint's customers would appreciate it as well. Regards, Daniel --------------------------------------------------------------- | Daniel M. Barton Internet: dmbarton@mci.net | | MCI Internet Services World Wide Web: | | Cary, North Carolina, USA http://infopage.mci.net | --------------------------------------------------------------- On Wed, 13 Dec 1995, Sean Doran wrote:
-----BEGIN PGP SIGNED MESSAGE-----
"Avi" == Avi Freedman <freedman@netaxs.com> writes:
Avi> What's the smallest CIDR block Sprint will listen Avi> to from an external source in the Avi> 207.x.x.x-208.x.x.x range? Is it different than Avi> the filters on > /19s in 206.x.x.x-207.x.x.x Avi> range?
- From non-customer BGP peerings we listen to /19s in 206/8.
We listen to /18s in 207/8 to the top of the IPv4 unicast space.
The nanog email archive should have lots more detail for you.
Sean.
Daniel Barton writes: MCI aggregates all its customer's routes into /19's. We have just received our first block of address space from the 207.x.x.x range. If you continue to filter at /18's for the 207.x.x.x range, you won't be able to reach all of MCI's customers. Needless to say MCI would appreciate it if you'd change your policy to be /19's, and I'm sure Sprint's customers would appreciate it as well. ========== Aside from what Daniel says about Sprint and MCI's routing policy mismatch, this statement is interesting on another level. For Dan says: MCI aggregates all its customer's routes into /19's. This is new is it not? Also it says *MCI* does the aggregating and not the customer. Would someone please explain how this differs from what I understand to be Sprints policy which says (i believe) that it is the CUSTOMER's responsibility to aggregate the routes they present to sprint??? Why would MCI do the aggregating? Is such mci policy good for mci or good for the customer or equally good for both? ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************
Aside from what Daniel says about Sprint and MCI's routing policy mismatch, this statement is interesting on another level. For Dan says: MCI aggregates all its customer's routes into /19's. This is new is it not? Also it says *MCI* does the aggregating and not the customer. Would someone please explain how this differs from what I understand to be Sprints policy which says (i believe) that it is the CUSTOMER's responsibility to aggregate the routes they present to sprint???
Why would MCI do the aggregating? Is such mci policy good for mci or good for the customer or equally good for both?
If one gets a /19 and redistributes it to 8 new ISP customers, it is your responsibility to make sure that you only redistribute that /19 - and not any more specifics. If you *know* what those /19s, /18s, ... are, you can put specific aggregate statements into the peering routers. It's trickier when you have some contiguous space (customer X announces a /23 to you and customer Y announces a /23 - and the two /23s can be merged into a /22) that comes from customer's space allocations. You have to detect that aggregation is possible and then statically insert it - and check that it won't break anything (i.e. that customer X doesn't need only the /23 announced because he wants it to override a larger /22). But certainly when you are directly allocated address space, you have a responsibility to aggregate announcements from your customers who are in that space yourself. It doesn't hurt the customer, since the space is administratively yours - if they want to multi-home, their other provider (who obviously does not own the same /19 or /18 or ...) will announce the more specific /22 route and things will be fine for that customer (except that if it's newer address space, Sprintlink customers won't see the second provider's path to that /22 unless the second provider *is* Sprintlink). Avi
MCI aggregates all its customer's routes into /19's. We have just received our first block of address space from the 207.x.x.x range. If you continue to filter at /18's for the 207.x.x.x range, you won't be able to reach all of MCI's customers.
Needless to say MCI would appreciate it if you'd change your policy to be /19's, and I'm sure Sprint's customers would appreciate it as well. ========== Aside from what Daniel says about Sprint and MCI's routing policy mismatch, this statement is interesting on another level. For Dan says: MCI aggregates all its customer's routes into /19's. This is new is it not? Also it says *MCI* does the aggregating and not the customer.
That may hold true internally, however, I suspect that externally, they announce only /16's or /15's. Of course, I could be wrong. What I see right now, is only one announcement from the 207 block...a /19 coming from netaxs, and then some customer of PSI is announcing 5 or so /24's in the 208 block!
Would someone please explain how this differs from what I understand to be Sprints policy which says (i believe) that it is the CUSTOMER's responsibility to aggregate the routes they present to sprint???
Sprint already proxy-aggregates for many of their customers. Most of them probably don't realize it. It doesn't even affect most of them.
Why would MCI do the aggregating? Is such mci policy good for mci or good for the customer or equally good for both?
Depends on the situation as to whether it's detrimental. Proxy-aggregation, as this is called, can alter traffic patterns in dual-homed situations. The change is not always bad, though it is often un-desirable. In general, proxy-aggregation is good for everybody. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)623-9663 Network Engineer -- Regional/National NSPs (Cisco) dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/~dsiegel/ for an ISP."
Depends on the situation as to whether it's detrimental. Proxy-aggregation, as this is called, can alter traffic patterns in dual-homed situations. The change is not always bad, though it is often un-desirable.
In general, proxy-aggregation is good for everybody.
If we had a good method for people to indicate routes that they didn't want to be aggregated, then more proxy aggregation could be done safely.
Depends on the situation as to whether it's detrimental. Proxy-aggregation, as this is called, can alter traffic patterns in dual-homed situations. The change is not always bad, though it is often un-desirable.
In general, proxy-aggregation is good for everybody.
If we had a good method for people to indicate routes that they didn't want to be aggregated, then more proxy aggregation could be done safely.
If I may... The idea of using a routing registry for this purpose has been suggested before. I still think it is a valid approach. Could be very useful in assisting with better proxy aggregation for all. --bill
Depends on the situation as to whether it's detrimental. Proxy-aggregation, as this is called, can alter traffic patterns in dual-homed situations. The change is not always bad, though it is often un-desirable.
In general, proxy-aggregation is good for everybody.
If we had a good method for people to indicate routes that they didn't want to be aggregated, then more proxy aggregation could be done safely.
If I may... The idea of using a routing registry for this purpose has been suggested before. I still think it is a valid approach. Could be very useful in assisting with better proxy aggregation for all.
--bill
Here here. This came up in response to an experiment on the routing table (http://routes.netaxs.com). But unless everyone uses an RR, it is not going to be a useful for building proxy-aggregations on the fly (i.e. without human checking and intervention). Avi
OK. So WHY AREN"T people using the routing registry? If they did would they be able to get around individual peering and transit agreements? Is it a chicken and egg thing. IE what percentage of global routes does the registry have? how does the registry as it stands now save people time, trouble or money? ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************
OK. So WHY AREN"T people using the routing registry? If they did would they be able to get around individual peering and transit agreements? Is it a chicken and egg thing. IE what percentage of global routes does the registry have? how does the registry as it stands now save people time, trouble or money?
for answers to some of these questions, I would point you at the following URL: http://www.merit.edu/routing.arbiter/RA/index.html The IRR has little to do with peering & transit, other than to reflect agreements. Other questions will have to be answered by people in the community. Many people do register in the IRR. Those that don't, won't for a variety of reasons. For some, there is an unwillingness to trust a thirdparty operator coupled with no desire to run a portion of the registry in-house. When these two conditions are found in a large-scale provider, the concept and implementation of the Internet RR are frustrated to the extent that the non-participating provider becomes increasingly unreachable/understandable. They are relegated to peridoc public postings to mailing lists for definitions of their routing policies. I expect that the example set by other large-scale providers would be an incentive. Running a section of the IRR inhouse shows a spirit of cooperation and a desire to share in the global internet. Refusal to do so appears, at least to me, to be an arrogant, egotistical view about any specific providers importance to a working global internet. --bill
-----BEGIN PGP SIGNED MESSAGE-----
"bmanning" == bmanning <bmanning@ISI.EDU>
Bill writes (I hope of me): bmanning> appears, at least to me, to be an arrogant, bmanning> egotistical view about any specific bmanning> providers importance to a working global bmanning> internet. Hm. Pot. Kettle. Black. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMNOscESWYarrFs6xAQHbtwQAoQm0too0d/fccl4oQRDp+/tBsBsiVmg4 22/LKshSiKQbM1MFrVP58WJJ5jWQiZDdjXavtnIwblaQh1T8Jg8WfomxIwqwmUZP IUHjh2lpt/eGbZo7EZQZB9XfB8CW+2G+iA1D3Upq/W20PrauO2xg1IIrHiI26l/0 X1OsqTsbT2Y= =7AKI -----END PGP SIGNATURE-----
Bill writes (I hope of me):
bmanning> appears, at least to me, to be an arrogant, bmanning> egotistical view about any specific bmanning> providers importance to a working global bmanning> internet.
Hm. Pot. Kettle. Black.
Sean.
Reminds me of a Dilbert... Dogbert: "I'm creating a comic strip called 'The Adventures of Boron'" Dilbert: "The Most Boring Man in the entire Universe.." He looks like me! Dogbert: "Geez, What an Ego you have." Sean, when I write about you, you will be named. As to your comments, I will admit to having an opinion that everyone is entitled to. I am -not-, at this time, a provider, so my "arrogant,egotistical view" ought to be taken w/ a grain of salt. --bill
If we had a good method for people to indicate routes that they didn't want to be aggregated, then more proxy aggregation could be done safely.
If I may... The idea of using a routing registry for this purpose has been suggested before. I still think it is a valid approach. Could be very useful in assisting with better proxy aggregation for all.
Let me just say I think the RR has some good uses, i.e. finding out what people intended the routing to look like, etc. I don't really understand how a RR can help with proxy aggregation seeing as the route objects really only provide origin AS and regular aggregation. It seems to me dual homed sites which are the concence of proxy aggregation, can be detected with a reasonably full set of routes, i.e. the second from AS from the origin in the ASPATH being different. (Or some split in the path outside of an AS communinity or confederation). But I don't fully understand all the details of this, so I'm sure someone can correct me if I'm wrong.
Jeremy Porter <jerry@fc.net> writes: I don't really understand how a RR can help with proxy aggregation seeing as the route objects really only provide origin AS and regular aggregation.
It can help in several ways: 1) If you proxy aggregate you put in a route object for the aggregate. This infiormation can be used to track down the cause of problems caused by proxy aggregation. 2) The route object can also contain information about "holes" in an aggregate, which can be quite useful when evaluating aggregation strategies. 3) The routing registry also contains 'aut-num' objects describing the routing policy of each AS: who they peer with, which routes they announce and accept. Given this information the consequences of proxy aggragation can be evaluated/simulated before putting a proxy aggregation in place. Daniel
In message <199512140726.BAA08568@freeside.fc.net>, Jeremy Porter writes:
If we had a good method for people to indicate routes that they didn't want to be aggregated, then more proxy aggregation could be done safely.
If I may... The idea of using a routing registry for this purpose has been suggested before. I still think it is a valid approach. Could be very useful in assisting with better proxy aggregation for all.
Let me just say I think the RR has some good uses, i.e. finding out what people intended the routing to look like, etc.
I don't really understand how a RR can help with proxy aggregation seeing as the route objects really only provide origin AS and regular aggregation.
The additional clues can be found in the aut-num for dual homed AS. If a route is registered with more than one origin AS and you route differently to these two AS, that's a clue to look carefully before proxying too.
It seems to me dual homed sites which are the concence of proxy aggregation, can be detected with a reasonably full set of routes, i.e. the second from AS from the origin in the ASPATH being different. (Or some split in the path outside of an AS communinity or confederation).
The secondary route may not be advertised to you if the primary suppresses the advertisement. For example if previders are A and B and they peer with each other, I may think I can aggregate some prefix over provider A, but B may not be advertising a backup path since it is preferring the same primary through A. Curtis
In message <m0tPwiv-000Nj8C@aero.branch.com>, Jon Zeeff writes:
Depends on the situation as to whether it's detrimental. Proxy-aggregation , as this is called, can alter traffic patterns in dual-homed situations. Th e change is not always bad, though it is often un-desirable.
In general, proxy-aggregation is good for everybody.
If we had a good method for people to indicate routes that they didn't want t o be aggregated, then more proxy aggregation could be done safely.
One way is to register an aut-num if the routes are in a separate AS and correctly indicate what other AS you peer with so others know there are backup paths which are going to have to still work after aggregation is done and not become primary paths. If you don't have an AS then register the route in all the AS you are multihomed to, not just one of them. This is gross, but I don't see a good way around it. In short, the only reason not to aggregate is to preserve correct routing for a dual homed situation (or properly indicate a hole). The means to indicate this is by properly registering the information in the IRR. Then hope the proxy aggregator bothers to look there, but if they don't then you have grounds to yell at them. Otherwise, they can just shrug. Curtis
What I see right now, is only one announcement from the 207 block...a /19 coming from netaxs, and then some customer of PSI is announcing 5 or so /24's in the 208 block!
Yeah, I see those /24s in 208/8 also. I posted to nanog a few weeks ago about it and was surprised to see those routes (still) there this morning. 208.0.1, 208.0.4, 208.0.5, 208.0.9 coming from AS 3847 (Internet Media Network), through PSI. We were just allocated the /19 yesterday in 207/8. Avi
What I see right now, is only one announcement from the 207 block...a /19 coming from netaxs, and then some customer of PSI is announcing 5 or so /24's in the 208 block!
We see these: Network Next Hop Metric LocPrf Weight Path *> 207.8.128.0/19 192.41.177.87 10 0 4969 i * 192.41.177.241 10 0 1239 3491 4969 i * 192.41.177.170 10 0 3830 3491 4969 i * 192.41.177.87 10 0 3491 4969 i * i208.0.1.0 149.20.64.1 10 100 0 1280 3847 ? *>i 149.20.64.1 10 100 0 1280 3847 ? * i208.0.4.0 149.20.64.1 10 100 0 1280 3847 ? *>i 149.20.64.1 10 100 0 1280 3847 ? * i208.0.5.0 149.20.64.1 10 100 0 1280 3847 ? *>i 149.20.64.1 10 100 0 1280 3847 ? * i208.0.9.0 149.20.64.1 10 100 0 1280 3847 ? *>i 149.20.64.1 10 100 0 1280 3847 ? --asp@uunet.uu.net (Andrew Partan)
What I see right now, is only one announcement from the 207 block...a /19 coming from netaxs, and then some customer of PSI is announcing 5 or so /24's in the 208 block!
We see these:
Network Next Hop Metric LocPrf Weight Path *> 207.8.128.0/19 192.41.177.87 10 0 4969 i * 192.41.177.241 10 0 1239 3491 4969 i * 192.41.177.170 10 0 3830 3491 4969 i * 192.41.177.87 10 0 3491 4969 i
I was looking this AM and saw (with different AS-paths) the same thing - I was curious to see if anyone else was announcing in 207/8. Apparently not, yet.
* i208.0.1.0 149.20.64.1 10 100 0 1280 3847 ? *>i 149.20.64.1 10 100 0 1280 3847 ? * i208.0.4.0 149.20.64.1 10 100 0 1280 3847 ? *>i 149.20.64.1 10 100 0 1280 3847 ? * i208.0.5.0 149.20.64.1 10 100 0 1280 3847 ? *>i 149.20.64.1 10 100 0 1280 3847 ? * i208.0.9.0 149.20.64.1 10 100 0 1280 3847 ? *>i 149.20.64.1 10 100 0 1280 3847 ?
Avi
Let me clarify something I incorrectly stated earlier. The MCI provider network (MCI-NETBLKxx) are aggregated into /16s at the borders, not /19s as my earlier note said. As a result, our new 207.0/14 block will be reachable to Sprint, since they will hear the /16s. Regards, Daniel --------------------------------------------------------------- | Daniel M. Barton Internet: dmbarton@mci.net | | MCI Internet Services World Wide Web: | | Cary, North Carolina, USA http://infopage.mci.net | ---------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE-----
""Daniel" == "Daniel M Barton" <dmbarton@mci.net> writes:
Daniel> Let me clarify something I incorrectly stated Daniel> earlier. The MCI provider network Daniel> (MCI-NETBLKxx) are aggregated into /16s at Daniel> the borders, not /19s as my earlier note Daniel> said. Which is a good thing too, since, as we do closest-exit routing towards InternetMCI, whether we hear one prefix in your /14 or 10000, packets will go out the same direction under normal circumstances. Anyone wanting to deal with abnormal circumstances (partitioning of InternetMCI that makes part of a big aggregate unreachable from a border gateway announcing the entire aggregate) is welcomed to study Yakov Rekhter's excellent presentation on the "push" operation. Anyone downstream from us wanting to route differently towards different parts of the big aggregate is welcomed to study Yakov Rekhter's excellent presentation on the "pull" operation. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMNOmkESWYarrFs6xAQFYkgP+OEq1hmM7UAx/UCY/Sfku+w9DeOCkwq/8 oG4Pohy6I96Qrq4DiM0ufqQXRGJed5vzh+kuQrhbALSd2JP7Nfj18/CClcR5xz6/ 9YF2nC9A23dA0MXxsXMb3RNSoGcWyOoRLA0jOekR087uTUNIKQ+jv9uMLQqjazte h2ytLMREXrM= =ja/7 -----END PGP SIGNATURE-----
participants (11)
-
asp＠uunet.uu.net -
Avi Freedman -
bmanning＠ISI.EDU -
Curtis Villamizar -
Daniel Karrenberg -
Daniel M. Barton -
Dave Siegel -
Gordon Cook -
Jeremy Porter -
jon＠branch.com -
Sean Doran