Re: The Gorgon's Knot. Was: Re: Verio Peering Question
Patrick writes: | >Wouldn't it have been easier for small ISP to just aggregate? | >I mean, /19s got through after all! | | No, it would not have helped. Assume the prospective customer has a link | to UUNET and a /24, but wants a second link for [insert reason]. He now | goes to SmallISP.com and asks for info on getting a second T1. Then the | Sprint sales guy calls him and mentions that IF AND ONLY IF he buys a line | from Sprint, will Sprint hear his /24. Let's see. Firstly, this is a valid point, although I wonder how Sprint's sales person could possibly know she or he should call the customer in the first place. Unless Sprint is known to employ psychics, this seems like a bit of a stretch in producing a bete noire. Secondly, /24 is not a small ISP, but wants a small ISP to back-up connectivity to UUNET. Valid goal. However, asking small ISP to ensure the world hears the hole in UUNET's CIDR block is not a good solution. Instead: 1. this is one reason why NAT was invented in the first place, and (hopefully) NAT is feasible for /24 (which is not an ISP) 2. where NAT is impractical or even undesirable, Tony Bates and Yakov Rekhter have a solution in RFC 2260 tailor-made to this situation 3. the maximum 254 things in the /24 can be renumbered into small ISP's PA space and announced to UUWHO with a constraining (set of) community(ies) (NAT, incidentally, was also invented to make renumbering easier) 4. "creative value-added approaches to this problem are sold for $" If the premise that /24 is not an ISP is false, then it should renumber anyway into PA space which is readily available and a generally understood cost of business for transit providers/ISPs. Remember that the /19 boundary is both aligned with RIR policy, which with its slow-start mechanism and fee structure is a really low barrier for a prospective ISP while still putting some costs on consumption of address space, and also small enough that it's not a deadly pain to renumber anything containable by a longer prefix, even without the assistance of NAT. | NOTE: I am not saying this is good or bad, simply saying that what you | suggest would not be useful in this situation. If I cover all the bases, exceptions, and gotchas I will write fewer individual messages but my heaven will they ever be lonnnnnnng! Market research indicates that this is not desired. Sean. PS: | "I realize that this is hard for you to wrap your brain around," but please | believe there may actually be other people on the planet who have the | brains to understand what they are doing and perhaps make a different | decision than you made for a good reason. Requires evidence, and sometimes is undone by subsequent messages. I hope you'll note my tone varies considerably in my various replies to people.
At 07:09 PM 9/28/2001 -0700, Sean M. Doran wrote:
Patrick writes:
| >Wouldn't it have been easier for small ISP to just aggregate? | >I mean, /19s got through after all! | | No, it would not have helped. Assume the prospective customer has a link | to UUNET and a /24, but wants a second link for [insert reason]. He now | goes to SmallISP.com and asks for info on getting a second T1. Then the | Sprint sales guy calls him and mentions that IF AND ONLY IF he buys a line | from Sprint, will Sprint hear his /24.
Let's see. Firstly, this is a valid point, although I wonder how Sprint's sales person could possibly know she or he should call the customer in the first place. Unless Sprint is known to employ psychics, this seems like a bit of a stretch in producing a bete noire.
Gimme a break. s/the Sprint sales guy calls him and/he calls a Sprint sales guy who/ Geez.....
Secondly, /24 is not a small ISP, but wants a small ISP to back-up connectivity to UUNET. Valid goal. However, asking small ISP to ensure the world hears the hole in UUNET's CIDR block is not a good solution.
Why not?
Instead:
1. this is one reason why NAT was invented in the first place, and (hopefully) NAT is feasible for /24 (which is not an ISP)
This would cause depletion of address space faster.
2. where NAT is impractical or even undesirable, Tony Bates and Yakov Rekhter have a solution in RFC 2260 tailor-made to this situation
This does not address performance issues.
3. the maximum 254 things in the /24 can be renumbered into small ISP's PA space and announced to UUWHO with a constraining (set of) community(ies)
(NAT, incidentally, was also invented to make renumbering easier)
All this does is swap the problem around, not solve it.
4. "creative value-added approaches to this problem are sold for $"
Why bother, when ISP-X down the street will "just do it"?
If the premise that /24 is not an ISP is false, then it should renumber anyway into PA space which is readily available and a generally understood cost of business for transit providers/ISPs.
Agreed. -- TTFN, patrick
participants (2)
-
Patrick W. Gilmore
-
smd@clock.org