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

[Robert Raszuk <[e-mail]>]

Hey Russ,

> o  AS1 is advertising 192.0.2.128/25 to both AS2 and AS3.
> o  AS2 is advertising both 192.0.2.128/25 and 192.0.2.0/24 into AS4.
> o  AS3 is advertising 192.0.2.128/25 into AS4
>
> I am afraid you are too optimistic :) ==
>
> Actually, this is really simple to fix in one of two ways.
>
> First, AS4 could see the overlap on the outbound side, note the
> origin AS is the same, and set the longer prefix to NO_EXPORT.

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.

> Alternatively, the BGP implementation in AS4 could be modified so
> that when running bestpath if a losing route has a specific
> community, it is transferred to the winning route. This would allow
> the winning route to gain the BOUNDED community in processing.

Actually I am not that clear I understand this business reg communities 
marking. How about we consider even much simpler and ASBR local solution:

"If we are advertising on EBGP (so setting next hop self) and there are 
less specific covering more specific routes the more specific can be 
suppressed from advertisement."

Of course the implementation must back walk when the less specific goes 
away, but this is anyway required in all of the above.


> == The most common scenario I see is that AS2 only advertises to AS4
> the aggregate so 192.0.2.0/24. That means that your 192.0.2.128/25
> would never get "BOUNDED" status hence the other path via AS3 will
> continue worldwide via AS4. ==
>
> I rarely see this --because most of the time, folks want to "cover"
> the longer match with a shorter one, in case the longer prefix fails
> for some reason. With a covering route, both ISPs will be used for
> inbound traffic, and not just the one with the remaining longer
> prefix. This has been the recommended configuration for years,
> AFAIK.

If this is PI address given to a customer I actually do not know any ISP 
who would advertise his smaller blocks in addition to his aggregate 
those blocks are taken from. Only for backdoor/multihoming the smaller 
blocks get advertised via some other ISPs, but never directly connected.


> == Contrary as you very well know the alternative proposal
> http://tools.ietf.org/id/draft-marques-idr-aggregate-00.txt seems to
> address the above case as well as all cases you are trying to cover.
> Could you comment and compare both solutions especially as a
> (co-)author of both ;). ==
>
> I prefer the simpler solution presented in the draft we just
> published. Draft-marquis and the virtual aggregation drafts both add

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.

> a lot of complexity to operations, while the BOUNDED community is
> very simple, and can (mostly) be implemented today with no changes to
> BGP, no changes to current traffic engineering, and no increased
> stretch within the SP network. Complexity can always be added, but a
> simple system on which future modifications can be made to cover
> corner cases seems like a better idea to me... :-)

Simple but not simpler ....


Best,
R.