==
( )
/-------( AS2 )--------\
( ) / ( ) \ ( ) ( )
( AS1 ) ( AS4 )-----( AS5 )
( ) \ ( ) / ( ) ( )
\-------( AS3 )--------/
( )
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.
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.
==
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.
==
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 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... :-)
:-)
Russ
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
