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.

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.