Hi, It is late and am just checking email. But... The /24 is more specific than the /19 therefore the /24 take priority. In my opinion AS path length became somewhat redundant with the rise of confederations and BGP doesn't understand bandwidth, latency and congestion. But I didn't write it, I am not that clever and it works and is what we have today. But.... I don't care about the remote de-aggregating AS's local traffic engineering, I care about the reach ability of the IP my customer has requested, and the /19 is a valid route in the route table the origin AS put it there and it is in my local transit feed. Why should I pay in my router for the degaregated AS's traffic engineering which doesnt benefit me, I care about my transit and peers as long as the /19 is reachable. Personally it is the deagregating ASs problem if they have poor transit and peering not mine, maybe if they took ownership of their problem rather than trying to make it everyone else's problem we would not find ourselves in the mess we are currently in with no sign of the problem diminishing or fixing itself. This is not about my router or processor - it is fine thank you with plenty of capacity transits and peers - but that doesn't excuse the generation of dross in the table - I refuse to believe there are justifiable reasons for anywhere near the majority of those 100K+ suspect routes. As a wide general rough rule of thumb, more specifics (if any) for peering should only be getting announced to peers + customers not back up into transit providers. RIPE RIR rules don't deagreagte - period - these ASs should not expect others to carry their extra x prefixes just because they want to stretch the size of their table in a router waiving contest. I know I can dump them, for identical origination ASes, and things will continue to work for me - the trick and my question is how to dynamically classify them so that it is possible to think about dropping them. The question was how? The answer is - seems it cant be done. The main/best I have heard work around seems to be RIR minimum allocation PA space filtering plus defaults to capture the very small number of unique prefixes of PA less than minimum allocation size that would get filtered - as I understand it, it is top of my reading list on my desk tommorow. The idea as much as possible is to go with what is in the routing table not to pin default routes all over the place and to simply try and "easily with minimum maintenance" drop a slice of the dross without impacting customer experience. Thank you to all who suggested solutions. Ben -----Original Message----- From: Deepak Jain [mailto:deepak@ai.net] Sent: 15 January 2008 22:09 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering
But if I can see the /19 in the table, do I care about a load of /24s because the whole of the /19 should be reachable as the origin AS is announcing it somewhere in their network and it is being received my a
transit so should be reachable.
The "presumption" in cases like this is that the /24 may take a different path than the /19 in some or all cases. If you have only a single provider you can safely dump more specifics -- but then, you could just point default. If you *are* multihomed and the /19 and /24 both have the same primacy (first choice in a routing decision and same path) you can safely drop the more specific. The "presumption" is that in some cases the /24 would take a different path than the /19 in a routing fight. How much cost you want to incur for these is your choice. If enough people drop the more specifics, they will go away as well -- if they provided no benefit, fewer would exist. Some of this originates from the peering-contests where folks have "x number of prefixes" which makes them bigger than "y number of prefixes". I'd be interested to see any metrics on rate of growth of allocations longer than RIR limits since Verio instituted then dropped mandatory prefix filters. (vs the rate of growth of prefixes overall). I would guess that they accelerated. Deepak