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.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
