Routing Registries...

Alex P. Rudnev alex at Relcom.EU.net
Mon Feb 9 20:29:22 UTC 1998


Sorry, I forget to add:

> > Exactly there is 3 types of the neighbours:
> > - trusted (for example, I hope MCI should be trusted for everyone; you 
> > can't build access filter for it);
> > - we get info from RIPE or some other DBA (usially it's some peers);
> > - we maintain routing info ourself (customers and some small ISP here).
And this case we should check this information by RIPE or RADB, and then 
by our local registry, and then add it to the local data base... 

> Generally, our response is to use the routing registries to 
You can't do it for your own customers - this registries does not contain 
enougph information for your local routing filters... This is why I 
mentioned not 2 but 3 different schemas.

For now, the problem is not in choosing one of this schemas, the problem 
is in a lot of small and badly-qualified ISP who do not control their 
routes, and are not controlled by their ISP (due to some unknown reasons) 
and so on. 

Anyway this do not protect your from mistakes (we had some funy 
experience when some authoritive person lost 1 digit 
and add wrong network 
(95.x.x.x instead of 195.x.x.x) into RIPE DB; then we have checked this 
and add this to our data base, and it took about 2 weeks to found this 
mistake. This is why the idea of using some authentication or sighning 
(as is to be proposed now, as I know) is important. On the other hand, I 
don't think it's good idea for some small ISP to check all routes he 
receive from the big one (for example, some _VILLAGE_DUBY_ISP get 
conenctivity from some GLOBAL_AFRICA_AND_AZIA) in case if they are sure 
this big one make all such checks itself. 

But it's another issue. All I'd like to note here is _it's 
important to make any kind of control now instead of total absence of 
such control_ - this cause a lot of headache over  the whole internet.
And (in real life) we saw this 3 schemas _where routing information can 
be found_.





More information about the NANOG mailing list