In message <"xlink100.x.910:17.07.95.23.48.56"@xlink.net>, Arnold Nipper writes :
Hank Nussbacher wrote:
On Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) you said:
Simon Poole wrote:
Yakov, if you have data that CIDR is -not- working for new allocations please present it here.
Simon
CIDR doesn't work as it should. We had to inject all of the more specifics of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly.
Can someone explain this a bit more? This sounds like a showstopper for CIDR.
Xlink (AS517) was announcing 194.45.0.0/16 via Ebone. There are some networks within this block announced by PSI. Routing table at PSI looks like
[ deleted for brevity ]
But Sprintlink was routing
[ deleted for brevity ]
TT to Sprintlink didn't help. After 4 days still no response. I've fixed this silly routing by announcing all more specifics.
Arnold
The way this is supposed to work is the originator announces the aggregate and registers in in the IRR. When confident that the aggregate is reaching where it needs to go, the originator stops announcing the components. If you are the originator of these routes, where is PSI getting the routes from? If you are not the originator and are doing a proxy aggregation, you have to be sure that anyone else that the originator is advertising the routes to is either also doing proxy aggregation, or is the intended primary for these routes (or more preferred than you are). In a coordinated multiprovider proxy aggregation, if you can't all withdraw the componenents simultaneously, the least preferred provider needs to withdraw the components first, then the next least preferred, etc, until all providers doing proxy have withdrawn the cpomponents. The only sure way to know if you are going to break things are: 1) check with a reliable IRR (the IRR exists, but there is some question about whether it can be called "reliable"), or 2) try it and see what breaks, or 3) do your best with the less than perfect IRR and the try 2). The problem was not with Sprint if PSI was annoncing the components, unless you were expecting Sprint to proxy aggregate for PSI (which perhaps they hadn't yet agreed to do). A TT would not be the way to request proxy aggregation from another provider. Curtis