Re: NSFnet-approved nets inside non-approved aggregate

[Dave Morton <[e-mail]>]

>In <[e-mail]>, <[e-mail]> wrote:
>
>> Having everyone in AlterNet who is not NSFNET compliant renumber
>> is prima facie unworkable.  

Sean - I fully agree that it would be an impossible task - it is though,
one of the alternatives you could have listed albeit the worst one.
I am not seriously suggesting it as a solution - I doubt either Alternet
or anyone else including the ISPs customers would be enthused.....

>> AlterNet is probably the most paranoid of all NACR-submitters, as they
>> will not submit a NACR without a letter from their subscribers stating
>> the specifically acceptable things they will be using the NSFNET
>> backbone service for, and they generally require the letter writers
>> to do such things as list the NSFNET-using organizations they
>> will be doing joint research with and so forth.
>
>Well, as someone who has largely inherited AlterNet's "prudent"
>AUP-implementation policy, I think I can comment a bit here.
>
>> It would have been nice though if AlterNet had set its policies so
>> that people who would agree to the NSFNET AUP would be numbered one
>> way and the people who wouldn't ever do so would get numbered another
>> way.  However, The Way Things Are Done got in the way... :(
>
>> Perhaps a change in that approach to something like "letter first,
>> allocate addresses next, then commercial routing and NACR" could help
>> AlterNet avoid announcing further more-specific networks instead of
>> aggregating people into a new pair of big CIDR blocks; one which is
>> AUP compliant and one which is not and will not be.  (Or maybe two per
>> coast, or eight altogether or something).  It's not perfect and there
>> will still be changes, but it will help.
>
>This is simply not practical. It is impossible to educate a customer
>to the point where they can make a rational decision about whether
>they want/qualify for NSFNET access as part of the pre-sales
>process, before number allocation. Quite often a customer will not
>realise they need NSFNET access until after they have been connected
>for some time, and then try and connect to an NSFNET site.  Or they
>start up a new project which qualifies them for NSFNET access.
>
>Asking them to renumber half-way down the line is not reasonable.

I must agree with Keith here. If the customer is a large one with one or
more class Bs he will simply refuse - what does one do then ?

What has not yet been mentioned I noticed is the even worse situation of
customers changing provider and thus splitting CIDR blocks. In effect its 
the same as AUP/non-AUP allocation above. This will also have an affect 
on routing table size - what to do in these cases ?

>The only predicition that we have found you can sensibly make about
>customer's NSFNET requirements, is that they longer they have been
>with us, the more likely they are to have/want NSFNET routing. It is
>possible this problem is more acute outside the US, where for
>starters people have less idea what the National Science Foundation
>is in the first place.
>
>I'm afraid *all* of these 142 overlaps are explicit and deliberate
>announcements to ensure only AUP routes get through to the NSFNET.
>I could withdraw them tomorrow if the NSF made the decision that it
>is in the interest of the Internet to aggreate the AUP.
>
>In fact, I'll probably do this anyway, as it is quite clear to me
>several of my European competitors are already advertising AUP
>aggregates with non-AUP networks in them. Why should my network be
>run with inferior practices and connectivity to theirs, never mind
>the benefit to the community as a whole ?
>
>*Please* can we have a sensible ruling from the NSF or action from
>MERIT, bending the rules a bit more for another 3 months can't hurt
>as much as not doing so.

I agree and second that,
Dave