[13637] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Announcing new route (What besides BGP?)

daemon@ATHENA.MIT.EDU (Alex P. Rudnev)
Wed Nov 12 15:48:48 1997

Date: Wed, 12 Nov 1997 23:24:17 +0300 (MSK)
From: "Alex P. Rudnev" <alex@Relcom.EU.net>
To: Kevin Oberman <oberman@es.net>
cc: Gerald Winters <gerald@merit.edu>, Kevin Oberman <oberman@es.net>,
        Bradley Reynolds <brad@b63695.student.cwru.edu>,
        "Forrest W. Christian" <forrestc@iMach.com>, nanog@merit.edu,
        oberman@es.net
In-Reply-To: <9711121946.AA06128@ptavv.es.net>

We use both RIPE Data base and our own network data base to generate 
STRICT filtering by IP prefixes for our peers and customers (except some 
who are _trusted_ because they are too big or are our providers for the 
european/USA connectivity.




On Wed, 12 Nov 1997, Kevin Oberman wrote:

> Gerald,
> 
> I think there may be an issue of terms here.
> 
> I believe that there is relatively little truly incorrect data in the
> RADB. By "incorrect", I mean data that would result in incorrect or
> missing routing.
> 
> There is a fairly large amount of "obsolete" data that is virtually
> impossible to track down because it is abandoned. Routes that were
> transferred from the PRDB are especially likely to be obsolete, but I
> have stumbled on a number of routes registered to various organization
> and placed in the RADB when the organization either no longer exists
> or no longer is connected using that route.
> 
> This is a less serious problem in that it never results in failed
> routing. It does have some slight security implications, but I don't
> see a really significant way to exploit these.
> 
> The bottom line is that we (ESnet) has been using the IRR to generate
> portions of our router configuration for several years with very good
> results. 
> 
> And I still believe that record expiration will be needed some day
> because the database will accumulate abandoned data and continue to
> grow until things start to get un-manageable. I have no idea how close
> this is to happening, but I suspect that it is NOT near.
> 
> In any case, I think we are in basic agreement.
> -- 
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: oberman@es.net			Phone: +1 510 486-8634
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)


home help back first fref pref prev next nref lref last post