Re: NSFnet-approved nets inside non-approved aggregate

Dave Morton <Dave.Morton@ecrc.de> Tue, 10 January 1995 12:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01684; 10 Jan 95 7:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01680; 10 Jan 95 7:46 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa03956; 10 Jan 95 7:46 EST
Received: from ecrc.de (ecrc.de [141.1.1.1]) by merit.edu (8.6.9/merit-2.0) with SMTP id HAA26547 for <bgpd@merit.edu>; Tue, 10 Jan 1995 07:33:14 -0500
Received: from scorpio.ecrc.de by ecrc.de with SMTP id AA25360 ( for <bgpd@merit.edu>); Tue, 10 Jan 1995 13:31:38 +0100
Received: from acrab25.ecrc.de by scorpio.ecrc.de (4.1/SMI-3.2) id AA07081; Tue, 10 Jan 95 13:31:37 +0100
Date: Tue, 10 Jan 95 13:31:37 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Morton <Dave.Morton@ecrc.de>
Message-Id: <9501101231.AA07081@scorpio.ecrc.de>
To: curtis@ans.net, keith@pipex.net, peter@goshawk.lanl.gov, smd@cesium.clock.org
Subject: Re: NSFnet-approved nets inside non-approved aggregate
Cc: bgpd@merit.edu

>In <95Jan6.180317pst.5870@cesium.clock.org>;, <smd@cesium.clock.org>; 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