At 06:55 PM 8/16/96 -0400, Curtis Villamizar wrote:
I would make them renumber with a new class c that was not in your CIDR block. Maybe they could get a class C from the swamp?
Are you suggesting that all dual homed networks should be renumbered such that they can't be aggregated and can't be reached from a good part of the Internet. I don't think that is a good idea.
Are suggesting punishing a customer for picking up a second provider by giving them an unroutable prefix? I hope not.
Curtis, Not sure what you mean here concerning 'unroutable' prefixes, but the issue with obtaining an allocation for one of the upstream provider's CIDR block when multihomed *does* have its drawbacks, at least from the end-user perspective. If said prefix (let's say a /24) is announced in the 'allocating' provider's aggregate, and the more specific is announced via the 'other' provider, the more specific will always be preferred. Of course, you can play a few tricks (AS_PATH prepend, etc.), but this situation introduces unique problems. In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates that this is one of the few acceptable instances when allocation can be done by one of the various registries and not by (one of) the upstream service provider(s). I think this is a contributing factor to the overall growth of the global routing table(s), but this is an issue we need to deal with. From an operational perspective, I'd opt for using a prefix which was not allocated from either/any upstream provider. From a global perspective, this contributes to route bloat. :-/ - paul
Not sure what you mean here concerning 'unroutable' prefixes, but the issue with obtaining an allocation for one of the upstream provider's CIDR block when multihomed *does* have its drawbacks, at least from the end-user perspective. If said prefix (let's say a /24) is announced in the 'allocating' provider's aggregate, and the more specific is announced via the 'other' provider, the more specific will always be preferred.
This is brain damaged. Given AS1 ----- Sprint | | | | AS2 ----- anything else not Sprint You can not announce a bit of Sprint space AS1->AS2->MCI as a fallback (note the 'extra' AS hop) because Sprint aggregates your announcement and the longer prefix is announced to the world via <anything else>. Use Sprint space, bye bye fallback. To the best of my knowledge (which ain't that hot), all other providers have discovered suppress-map. randy
In message <m0urb70-00080OC@rip.psg.com>, Randy Bush writes:
Not sure what you mean here concerning 'unroutable' prefixes, but the issue with obtaining an allocation for one of the upstream provider's CIDR block when multihomed *does* have its drawbacks, at least from the end-user perspective. If said prefix (let's say a /24) is announced in the 'allocating' provider's aggregate, and the more specific is announced via the 'other' provider, the more specific will always be preferred.
This is brain damaged. Given
AS1 ----- Sprint | | | | AS2 ----- anything else not Sprint
You can not announce a bit of Sprint space AS1->AS2->MCI as a fallback (note the 'extra' AS hop) because Sprint aggregates your announcement and the longer prefix is announced to the world via <anything else>.
Use Sprint space, bye bye fallback.
To the best of my knowledge (which ain't that hot), all other providers have discovered suppress-map.
randy
Randy, What are you saying is brain damaged? The idea of announcing a dual homed route as part of an aggregate? Or Sprint? You clearly want to avoid using space in any provider that is not willing to suppress your more specific when generating their aggregate, particularly since they can no longer pass the aggregate to you (with your AS in the as-set). We've seen this effect. Using your own aggregate and allowing a customer to dual home, leaving the alternate provider's contribution out of the aggregate is a certainly not brain damaged. Curtis
Mornin' Curtis,
Not sure what you mean here concerning 'unroutable' prefixes, but the issue with obtaining an allocation for one of the upstream provider's CIDR block when multihomed *does* have its drawbacks, at least from the end-user perspective. If said prefix (let's say a /24) is announced in the 'allocating' provider's aggregate, and the more specific is announced via the 'other' provider, the more specific will always be preferred.
This is brain damaged. Given
AS1 ----- Sprint | | | | AS2 ----- anything else not Sprint
You can not announce a bit of Sprint space AS1->AS2->MCI as a fallback (note the 'extra' AS hop) because Sprint aggregates your announcement and the longer prefix is announced to the world via <anything else>.
Use Sprint space, bye bye fallback.
To the best of my knowledge (which ain't that hot), all other providers have discovered suppress-map.
What are you saying is brain damaged? The idea of announcing a dual homed route as part of an aggregate? Or Sprint?
Sprint's policy. And they are *proud* of the policy. To quote ... Sprint is in the process of aggregating as much of the network as we can to reduce the overall number of announcements that need to be made and to avoid having to register each IP block with companie such as ANS for routing through their network. Scott SprintLink NOC Peter's RADB entries are a good giggle, as they can be generally ignored. This policy can not be ignored. What Sprint's policy is actually meant to do is to discourage customers from multi-homing to other providers. What their policy actually does is convince wise folk not to buy from Sprint. randy
On Sat, 17 Aug 1996, Randy Bush wrote:
What Sprint's policy is actually meant to do is to discourage customers ^^^^^^^^^^^^^^^^^^^^^ from multi-homing to other providers. What their policy actually does is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not a bad thing in itself. -dorian
What Sprint's policy is actually meant to do is to discourage customers ^^^^^^^^^^^^^^^^^^^^^ from multi-homing to other providers. What their policy actually does is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not a bad thing in itself.
That depends on who you are and how important your network connectivity is. Clearly if someone has a business plan that calls for their packets to be carried "hot, live" by two different worldwide IP carriers, neither of those can be SprintLink. If I were SprintLink I would think this was a bad thing.
Randy Bush writes:
Not sure what you mean here concerning 'unroutable' prefixes, but the issue with obtaining an allocation for one of the upstream provider's CIDR block when multihomed *does* have its drawbacks, at least from the end-user perspective. If said prefix (let's say a /24) is announced in the 'allocating' provider's aggregate, and the more specific is announced via the 'other' provider, the more specific will always be preferred.
This is brain damaged. Given
AS1 ----- Sprint | | | | AS2 ----- anything else not Sprint
You can not announce a bit of Sprint space AS1->AS2->MCI as a fallback (note the 'extra' AS hop) because Sprint aggregates your announcement and the longer prefix is announced to the world via <anything else>.
Use Sprint space, bye bye fallback.
To the best of my knowledge (which ain't that hot), all other providers have discovered suppress-map.
This is mainly due to the fact that Sprint does not listen to any announcements from its peers for anything within its "non-portable" blocks. Multihoming and expecting fallback to work are two different things I guess. Let's not even mention the AS path length stuff. BTW, Sprint also does not listen to any of its peers ASes through other peers so peering with Sprint and still paying someone for transit services do not help you get more redundancy with Sprint's network. -Hank
Hi Hank,
Not sure what you mean here concerning 'unroutable' prefixes, but the issue with obtaining an allocation for one of the upstream provider's CIDR block when multihomed *does* have its drawbacks, at least from the end-user perspective. If said prefix (let's say a /24) is announced in the 'allocating' provider's aggregate, and the more specific is announced via the 'other' provider, the more specific will always be preferred.
This is brain damaged. Given
AS1 ----- Sprint | | | | AS2 ----- anything else not Sprint
You can not announce a bit of Sprint space AS1->AS2->MCI as a fallback (note the 'extra' AS hop) because Sprint aggregates your announcement and the longer prefix is announced to the world via <anything else>.
Use Sprint space, bye bye fallback.
To the best of my knowledge (which ain't that hot), all other providers have discovered suppress-map.
This is mainly due to the fact that Sprint does not listen to any announcements from its peers for anything within its "non-portable" blocks.
What?!? I.e. if a Sprint customer C is multi-homed and their Sprint line goes down, traffic to C from other Sprint customers will not be able to reach C?
BTW, Sprint also does not listen to any of its peers ASes through other peers so peering with Sprint and still paying someone for transit services do not help you get more redundancy with Sprint's network.
And this is considered good networking architecture? Jeezus! randy
This is mainly due to the fact that Sprint does not listen to any announcements from its peers for anything within its "non-portable" blocks.
What?!? I.e. if a Sprint customer C is multi-homed and their Sprint line goes down, traffic to C from other Sprint customers will not be able to reach C?
Yes. Sean encourage(s/ed) other providers to do the same sort of filtering. He doesn't like the fact that he's still carrying stuff inside his network that he would filter from a peer, but apparently he's hoping that someone else (some other provider) will force the issue for him (inside of Sprintlink).
BTW, Sprint also does not listen to any of its peers ASes through other peers so peering with Sprint and still paying someone for transit services do not help you get more redundancy with Sprint's network.
And this is considered good networking architecture? Jeezus!
It's a reasonable way to make sure that your peers won't f*ck you by redistributing routes for everyone else into you through their session. If that's your goal, you either have to limit the as-paths you'll hear from a peer or not hear routes with any peer's AS through any other peer. And it has the side-benefit of making people realize that they'd better run a *real* network with good connectivity between their interior and all of the exchange points they're at. (Meaning if you peer with someone with this policy, you're on your own as far as connectivity to that someone).
randy
Avi
In message <199608170146.SAA20928@lint.cisco.com>, Paul Ferguson writes:
At 06:55 PM 8/16/96 -0400, Curtis Villamizar wrote:
I would make them renumber with a new class c that was not in your CIDR block. Maybe they could get a class C from the swamp?
Are you suggesting that all dual homed networks should be renumbered such that they can't be aggregated and can't be reached from a good part of the Internet. I don't think that is a good idea.
Are suggesting punishing a customer for picking up a second provider by giving them an unroutable prefix? I hope not.
Curtis,
Not sure what you mean here concerning 'unroutable' prefixes, but the issue with obtaining an allocation for one of the upstream provider's CIDR block when multihomed *does* have its drawbacks, at least from the end-user perspective. If said prefix (let's say a /24) is announced in the 'allocating' provider's aggregate, and the more specific is announced via the 'other' provider, the more specific will always be preferred.
A /24 in the so called "provider independent" space will be blocked by Sprint. That is what I mean be "unroutable". You announce both the aggregate and the more specific. At some point in the topology the more specific can be dropped. For example, if connected to 2 European previders the more specific need not be announced to North America and the other way around. This level of aggregation has yet to be acheived, but nuimbering in preparation for it can't hurt.
Of course, you can play a few tricks (AS_PATH prepend, etc.), but this situation introduces unique problems.
As-path length never overrides more specific but it isn't needed.
In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates that this is one of the few acceptable instances when allocation can be done by one of the various registries and not by (one of) the upstream service provider(s). I think this is a contributing factor to the overall growth of the global routing table(s), but this is an issue we need to deal with. From an operational perspective, I'd opt for using a prefix which was not allocated from either/any upstream provider. From a global perspective, this contributes to route bloat. :-/
From a purely pragmatic standpoint, what good is having a dual homed
draft-hubbard-registry-guidelines-05.txt is wrong on this one. If the route comes from one of the providers CIDR blocks, the other more specific route can be ignored farther away in the topology. If it is a provider independent address it can't be dropped without losing connectivity to it. prefix if Sprint and other major providers drops your prefix and you can't get to places? Better to number into one of the provider's aggregates. The more specific will go to everyone willing to take it and anyone not willing to take the more specific can still get there.
- paul
Curtis
Curtis Villamizar <curtis@ans.net> writes:
In message <199608170146.SAA20928@lint.cisco.com>, Paul Ferguson writes:
In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates that this is one of the few acceptable instances when allocation can be done by one of the various registries and not by (one of) the upstream service provider(s). ...
draft-hubbard-registry-guidelines-05.txt is wrong on this one.
Just for the record: I is one of the few acceptable instances and certainly does not represent common practise, to the contrary! All regional IRs recommend using address space from one of the providers.
If the route comes from one of the providers CIDR blocks, the other more specific route can be ignored farther away in the topology. If it is a provider independent address it can't be dropped without losing connectivity to it.
Correct. Daniel
In message <199608190722.HAA09446@kantoor.ripe.net>, Daniel Karrenberg writes:
Curtis Villamizar <curtis@ans.net> writes:
In message <199608170146.SAA20928@lint.cisco.com>, Paul Ferguson writes:
In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates that this is one of the few acceptable instances when allocation can be done by one of the various registries and not by (one of) the upstream service provider(s). ...
draft-hubbard-registry-guidelines-05.txt is wrong on this one.
Just for the record: I is one of the few acceptable instances and certainly does not represent common practise, to the contrary! All regional IRs recommend using address space from one of the providers.
I think I remember the logic behind this. The end user requests provider independent addresses, insisting that they would sue the registry if they didn't get them. The draft discourages this and so the registry should discourages this but the draft lets them give in. I still think it would be a better draft if this was more strongly discouraged. In 2.1 (page 5): current: b) the ISP is multi-homed, that is, it has more than one simultaneous connection to the global Internet and no connection is favored over the other Note that addresses issued directly from the IRs, (non-provider based), are the least likely to be routable across the Internet. suggested: b) the ISP is multi-homed, that is, it has more than one simultaneous connection to the global Internet, no connection is favored over the other. This practice, while allowed is strongly discouraged for reasons cited below. Note that addresses issued directly from the IRs, (non-provider based), are the least likely to be routable across the Internet, and cannot be further aggregated at points distant in the topology. The more specific routes associated with an dual homed allocations from a provider aggregate can be dropped at a sufficient distance in the Internet topology. For example, in most cases, these more specifics can be dropped from routing information provided to another continent with no change in traffic flow if this very large aggregation boundary is successfully implemented.
If the route comes from one of the providers CIDR blocks, the other more specific route can be ignored farther away in the topology. If it is a provider independent address it can't be dropped without losing connectivity to it.
Correct.
Daniel
Consider this a suggestion. Update the draft at your option. Curtis
In message <199608190722.HAA09446@kantoor.ripe.net>, Daniel Karrenberg writes:
Curtis Villamizar <curtis@ans.net> writes:
In message <199608170146.SAA20928@lint.cisco.com>, Paul Ferguson writes:
In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates that this is one of the few acceptable instances when allocation can be done by one of the various registries and not by (one of) the upstream service provider(s). ...
draft-hubbard-registry-guidelines-05.txt is wrong on this one.
Just for the record: I is one of the few acceptable instances and certainly does not represent common practise, to the contrary! All regional IRs recommend using address space from one of the providers.
I think I remember the logic behind this. The end user requests provider independent addresses, insisting that they would sue the registry if they didn't get them. The draft discourages this and so the registry should discourages this but the draft lets them give in.
Actually, the logic was from multiple ISPs who told us it was imperative in certain instances (as noted in the draft) that multi-homed organizations be given PI space. The registries (although I officially speak only for InterNIC) continue to discourage multi-homed customers from getting PI space. Even though I vowed to never touch the draft again or risk being stricken with the plague - I see your point and will change it to reflect the paragraph below if my co-authors agree. Kim
I still think it would be a better draft if this was more strongly discouraged. In 2.1 (page 5):
current:
b) the ISP is multi-homed, that is, it has more than one simultaneous connection to the global Internet and no connection is favored over the other
Note that addresses issued directly from the IRs, (non-provider based), are the least likely to be routable across the Internet.
suggested:
b) the ISP is multi-homed, that is, it has more than one simultaneous connection to the global Internet, no connection is favored over the other. This practice, while allowed is strongly discouraged for reasons cited below.
Note that addresses issued directly from the IRs, (non-provider based), are the least likely to be routable across the Internet, and cannot be further aggregated at points distant in the topology. The more specific routes associated with an dual homed allocations from a provider aggregate can be dropped at a sufficient distance in the Internet topology. For example, in most cases, these more specifics can be dropped from routing information provided to another continent with no change in traffic flow if this very large aggregation boundary is successfully implemented.
If the route comes from one of the providers CIDR blocks, the other more specific route can be ignored farther away in the topology. If it is a provider independent address it can't be dropped without losing connectivity to it.
Correct.
Daniel
Consider this a suggestion. Update the draft at your option.
Curtis
I think I remember the logic behind this. The end user requests provider independent addresses, insisting that they would sue the registry if they didn't get them. The draft discourages this and so the registry should discourages this but the draft lets them give in.
Actually, the logic was from multiple ISPs who told us it was imperative in certain instances (as noted in the draft) that multi-homed organizations be given PI space. The registries (although I officially speak only for InterNIC) continue to discourage multi-homed customers from getting PI space.
Just to make it unanimous for the RRs, APNIC also discourages PI as much as we're able. However, with respect to reasoning as to why we continue to allocate PI space (regardless of whether it is multi-homed or not), please see RFC 1814. I would find it really interesting to discover how much of the current routing table growth is due to newly allocated prefixes getting announced and how much is the result of a) previously unannounced but allocated networks being injected or b) entropy resulting from movement of networks from one provider to another. In my copious spare time... Regards, -drc
participants (10)
-
Avi Freedman -
Curtis Villamizar -
Daniel Karrenberg -
David R. Conrad -
Dorian R. Kim -
Henry Kilmer -
Kim Hubbard -
Paul A Vixie -
Paul Ferguson -
randy＠psg.com