Re: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04

[Robert Raszuk <[e-mail]>]

>> I don't think this is as simple as this ... Remember that when the
>> less specific (/24) goes away the AS4 must readvertise the more
>> specifics not to break routing. So therefor I do not think that any
>> simple policy would work. The choice/decision what to advertise and
>> what not must be done at best path run.
>
> Sure --but won't best path be run when the best path towards a
> specific destination falls out of the table?

Best path today does not compare /16 and /24. In Pedro's proposal it does.

>> Actually I am not that clear I understand this business reg
>> communities marking. How about we consider even much simpler and
>> ASBR local solution:
>
> A local ASBR only solution won't work for various reasons, so let's
> not. :-)

I think it works. The example is comparing all best path eligible
attributes of less and more specific during best path and if the less
specific would win suppress the more specific.

I am only not sure if we really need to compare all. For example I am
not sure that like in your proposal it really matters if the more
specific was received over the same session as less specific (provided
that actually happens that often as you say :-)

> So what you are saying is that if a provider owns 10.1.0.0/16, and
> gives out 10.1.1.0/24 to a customer to advertise through some other
> provider the customer is connected to, the provider would never
> advertise 10.1.1.0/24 as well as 10.1.0.0/16? Why not? Since the
> longest match always wins, what you're saying is that the provider
> that handed out the address space would end up routing through the
> competing provider (the customer's other provider) to reach the
> customer, because there is a longer match being advertised by the
> customer through the competing provider.
>
> That doesn't make any sense to me.

That has been for years common recommendation of any RIR ... That's the 
value of PA addresses. Multihomers were told to get PI which indeed does 
not make the BGP table smaller.

Examples:

"Announcement of initial allocation as a single entity"
http://meetings.ripe.net/ripe-53/presentations/rou-ps-rou.pdf

"Advertisement of more specific prefixes should not be used unless
absolutely necessary and, where sensible, a covering aggregate
should also be advertised.  Further, LIRs should use BGP methods
such as NO_EXPORT [RFC-1997] and NOPEER [RFC-3765] or provider-specific
communities, as described in [RIPE-399] to limit the propagation of
more specific prefixes in the routing table."
SRC: ripe-532.txt


>> Just to be very clear .. VA (any of the VA drafts) does not talk
>> about the same problem. For one it does not stop BGP from
>> advertising anything and second it is intra-domain solution.
>
> Right --the VA drafts increase stretch and don't reduce the total
> table size for anyone.

It never intended to. It reduces the local RIB/FIB size. I am not even 
sure why you are comparing apple to oranges here :)

Best,
R.