this week's CIDR progress report

Sun Apr 24 19:07:35 UTC 1994

 >From list-admin Fri Apr 22 18:19:27 1994
 >
 >Got a list of routes which are not in the NSFnet table but some other places.
 >Spot that one incident that the aggregate is advertised to both routing
 >tables, but there are few specific routes within the aggregate has been 
 >advertised to the NSFNET.  So in terms of connectivity, both can reach all the
 >specific routes destination, but the path would be different.  However, that
 >cause the difference in size of the routing table.  This is just the one I
 >happen to see but there could be more such cases.  This indicates 
 >reason #1 in my previous message.  I also saw a lot of routes in the diff list 
 >looks like testnets but not quite sure.  I  do not have time to do more poking
 >today, I will do it on Monday.
 >
 >						--Jessica 
 >

I would agree that the difference in table size is most likely due to CIX 
issues.  I used to see table size differences of a few hundred routes, which 
I mostly attributed to the few days of lag time in getting new CIX routes 
registered in the PRDB.  

ANS-CIX (AS 1957) has a new policy for the past week or two which is 
to stop automatically registering the CIX-only routes (routes known 
to the CIX which are not registered by another AS 690 service provider) 
in the PRDB.  I understand they are working out a new policy for getting 
these CIX-only routes registed in the PRDB.  This could account for some 
of the table size discrepency.

Also, as service providers register aggregates in the PRDB, AS 1957 
component routes are removed, unless for policy purposes the service 
provider requests and ANS agrees to leave the AS 1957 component networks 
configured.  This could account for several hundred CIX-only component 
routes that have recently disappeared from the AS 690 routing tables, but 
which may still be announced to the CIX.

Also, there always seem to be a handful of routes (maybe about 20 ?) which
are known to the CIX but which are not registered in the PRDB because they 
cannot be verified as having been assigned from address space delegated to 
the InterNIC or RIPE. 

  --Steve Widmayer