Re: Additions to the NSFNET policy-based routing database
From gih@aarnet.edu.au Tue Jul 12 19:27:23 1994
On the 8 July update the following entry was added to the NSFNET policy routing database...
203.0/10 AUSTRALIA-CIDR-BLK C:AU 1:372 2:297
Expanded listing, sorted by country, then by organization: ==========================================================
...
Australia ---------
AARNet NIC, GPO Box 1142, Canberra, ACT, 2601, AUSTRALIA 1:372 Nasa Science Network (FIX-West) 2:297 Nasa Science Network (FIX-East) -------- 203.0/10 AUSTRALIA-CIDR-BLK (AU)
On the 12th July I noted the following updates...
203.5.31/24 NET-TAU-AU C:AU 1:372 2:297 203.5.215/24 SILCARBURNIE-AU C:AU 1:372 2:297
......
203.6.125/24 AUS-GOV-DEF5-AU C:AU 1:372 2:297 203.6.126/24 AUS-GOV-DEF5-AU C:AU 1:372 2:297 203.6.127/24 AUS-GOV-DEF5-AU C:AU 1:372 2:297
It would appear to make some sense to remove all the specific announcements from the CIDR block 203.0/10 from the NSFNET PRDB, as long as NASA is announcing 203.0/10 to the NSFNET at FIX WEST, but as these come via NASA I was wondering what the story is.
regards,
Geoff Huston AARNet
(in the interests of a smaller NSFNET routing table!)
Geoff, NASA may have reasons for doing it this way. In general, we encourage everyone to register any more-specific component pieces not needed in the NSFNET/ANSnet configuration files in the Merit RRDB rather than in the PRDB. We have a "no configure" option flag in the PRDB to prevent a more specific route from being configured if people tell us, but bypassing the PRDB for direct RRDB registration is now the preferable option in such "no configure" cases. --Steve Widmayer / Merit
Folks, Although I've gone ahead and configured on aggregate for AU, I'm not in a position right now to utilize it. Thus, we will continue to request that specific nets get added. Thanks, Jeff
From: jeff@nsipo.nasa.gov Date: Thu, 14 Jul 94 18:20:28 -0700 Although I've gone ahead and configured on aggregate for AU, I'm not in a position right now to utilize it. Thus, we will continue to request that specific nets get added. Although Jeff may have additional reasons---his situation is a bit more complex than ours---I just wanted to point out that DSI is in a similar situation (as described), and does not need to do this. Like NSI, the DSI is not capable of using aggregates internally, yet we _do_ have aggregates in the PRDB (with no more-specific routes listed) that are working fine (199.54/15 and 199.56.160/19). We advertise individual (classful) nets within these blocks to NSFnet, and they only propagate the aggregate to the rest of the net. -MAP
participants (3)
-
jeff＠nsipo.nasa.gov -
Michael A. Patton -
Steven K. Widmayer