[46415] in North American Network Operators' Group
Re: Route filters, IRRs, and route objects
daemon@ATHENA.MIT.EDU (Jake Khuon)
Wed Mar 27 14:07:17 2002
Message-Id: <200203271906.g2RJ6S1x012887@wooj.com>
From: "Jake Khuon" <khuon@NEEBU.Net>
To: Przemyslaw Karwasiecki <karwas@ifxcorp.com>
Cc: nanog@merit.edu
In-reply-to: Przemyslaw Karwasiecki's message of 27 Mar 2002 13:48:09 -0500.
<1017254889.3594.108.camel@brick.ifxcorp.com>
Reply-To: khuon@NEEBU.Net (Jake Khuon)
Date: Wed, 27 Mar 2002 11:06:28 -0800
Errors-To: owner-nanog-outgoing@merit.edu
### On 27 Mar 2002 13:48:09 -0500, Przemyslaw Karwasiecki
### <karwas@ifxcorp.com> casually decided to expound upon nanog@merit.edu
### the following thoughts about "Route filters, IRRs, and route objects":
PK> Why it is required by some providers to generate explicit,
PK> exact route objects, in order to allow routes through
PK> their filters?
Chalk this up to RIPE181 legacy. In those days of yor, you could only
achieve the effect of filtering on those more specifics by registering
seperate route objects. Many route objects in the IRR today are byproducts
of the blind migration which simply converted RIPE181 formatted objects to
RPSL. Although this was great in that it didn't really break anything it
also didn't force folks to really learn RPSL and take advantage of the new
syntax so many people just never bothered to take their objects and properly
convert them.
--
/*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+
| Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- |
| for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S |
+=========================================================================*/
