CIDR deployment

yakov at watson.ibm.com yakov at watson.ibm.com
Mon Mar 14 13:59:04 UTC 1994


Jessica,

>The issues, which I can think of for now, needs to be addressed here are:
>	1. Make sure no non-private ASs which are neither CIDRized nor
>		defaulting to other ASs.

Given the size and the distributed nature of today's Internet, what you
proposing doesn't seem to be a tractable problem.

A more relevant, and certainly more tractable problem would be to find
out whether all the ASs *directly* attached to AS 690 are either (a)
CIDR-capable, or (b) point default to AS 690 or some other AS, and
whether these ASs can register their CIDR prefixes with the MERIT Routing
Policy Database today. Could MERIT provide us with this information ?

>   2. Gain more confidence with the newly deployed CIDR in the networks.
>      More aggressive testing; injecting test CIDR routes to the Internet...

While I have nothing against the concept of gaining "more confidence", I
think that the "more aggressive testing" phase is already in the past.
At this point I don't see "injecting of test CIDR routes to the Internet"
as a valuable way of spending our resources.

A better way to spend our resources and to gain *real* confidence with
the newly deployed CIDR is to follow the strategy used by Havard:

	1. Announce a CIDR aggregate
	2. Remove individual components of the aggregate and
	   test its impact on the connectivity.

I would assume that Havard already has some form of a script that
allows to test the connectivity, and that this script
could be easily modified for use by other sites.

While the test done by Havard doesn't guarantees that removing the
individual components has no impact on *any* of the hosts in the
Internet, it tests for the impact on connectivity to a good sample of
the Internet.  We need to understand that providing the former (a
priory information on whether removing the individual components would
impact connectivity to *any* host in the Internet) is an intractable
problem, while providing the latter (assessing the impact of removing
the individual components on connectivity to some sample of the
Internet) is certainly doable (as shown by Havard).

>   3. Establish procedures for ASs to announce the replacement of individual
>      net routes to aid the detection of potential impact/of removing
>      such routes from the Internet.
>      ....
>      Is  3 days in advance reasonable ?

Announcing the replacement of individual components to the BGPD mailing
list is a fine idea, but it seem to me that we don't need any special
procedures for doing this (after all, all what it takes is just a piece
of e-mail, and that is exactly what Havard did). With respect to whether
"3 days in advance" is reasonable, we'll be better off by sticking with
Havard's strategy, instead of dwelling on this topic.

Yakov.





More information about the NANOG mailing list