Route filters, IRRs, and route objects
Hello, I would like to ask you for an advice in regards to "proxy registering" of customer route objects in IRR. What is the best current practice in a situation, when your customers want to advertise to you several /18 or /19 but they also have a requirement to be able to advertise some deaggregated routes on top of aggregates. It is very common that they are unable to predict exactly which deaggregated routes they will need to advertise, as they use those to achieve some traffic engineering objectives which change over time. And "over time" does NOT occur once per 30 minutes or so, so they DON'T generate any major BGP fluctuations. Forgive my ignorance, but is my understanding of RPSL correct, that it should be possible to specify routes in a way which will allow cover aggregate plus whole set of possible more specific routes upto certain netmask length. Something like: 10.0.0.0/18^18-24 So why this is uncommon to use such notation to describe routing policy, and use it to generate filters? Why it is required by some providers to generate explicit, exact route objects, in order to allow routes through their filters? Is it really necessary to "explode" route-sets like those 10.0.0.0/m^m-n into 2^(n-m+1) separate route objects to meet requirements of some providers? I believe that this is very common problem, so if there are any places on the web with some "best practice" documents, please point me to them. Thank you, Przemek
### 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 | +=========================================================================*/
In the referenced message, Przemyslaw Karwasiecki said:
Hello,
I would like to ask you for an advice in regards to "proxy registering" of customer route objects in IRR.
What is the best current practice in a situation, when your customers want to advertise to you several /18 or /19 but they also have a requirement to be able to advertise some deaggregated routes on top of aggregates.
If your customer is merely using the deaggregates for TE, why would they need to send the deags with anything but no-export. This would resolve the issue of having to advertise them to your peers, while still allowing the customer to have traffic come in whichever link they chose. The added benefit is that no one else needs to accept additional routes. <snip>
Stephen, Your comment in 100% accurate insituation when TE obectives are localized to our AS and customer AS. Unfortunatelly in some circumstances, (very common in our case) 90% of traffic is actually just merely transited via our AS, and customer needs to have a global visibility of deaggreagated prefixes. Przemek On Wed, 2002-03-27 at 23:03, Stephen Griffin wrote:
In the referenced message, Przemyslaw Karwasiecki said:
Hello,
I would like to ask you for an advice in regards to "proxy registering" of customer route objects in IRR.
What is the best current practice in a situation, when your customers want to advertise to you several /18 or /19 but they also have a requirement to be able to advertise some deaggregated routes on top of aggregates.
If your customer is merely using the deaggregates for TE, why would they need to send the deags with anything but no-export. This would resolve the issue of having to advertise them to your peers, while still allowing the customer to have traffic come in whichever link they chose. The added benefit is that no one else needs to accept additional routes.
<snip>
At 1:48 PM -0500 27/3/02, Przemyslaw Karwasiecki wrote:
Why it is required by some providers to generate explicit, exact route objects, in order to allow routes through their filters?
I worked on the assumption that the customer would think about what they were doing if they had to register them all. It didn't stop people doing it but I think it generated more discussion on what they really wanted to achieve than if we just allowed it automagically. Mark.
participants (4)
-
Jake Khuon -
Mark Prior -
Przemyslaw Karwasiecki -
Stephen Griffin