Joel, What we try to point out in this work is that when performing smart selective advertisement of overlapping prefixes, on can put IDR in a state where some ASes forward traffic according to the covering prefix, not knowing about the overlapping one, then let the traffic reach ASes which know about it.
At the junction, an ISP receives traffic forwarded as per the covering prefix, and transit it as per its forwarding state for the overlapping one. The observed transit path can thus become unexpected as per the path propagation policy of that AS. In http://tools.ietf.org/html/draft-cardona-filtering-threats-01 section 3.1.2, AS2 does nothing else then implement usual policy, ensuring that only paths received from customers are advertised to providers and peers. However, with the game being played on an overlapping prefix, it ends up receiving traffic from a non-customer, forwarded as per the covering prefix, and forwards it to a non-customer because a path for the overlapping prefix is in its routers' FIB. So in the draft, we say that AS2 may be not really fancying this forwarding state, because it configured its policy not thinking those transit paths across its network would be doable. okay? Pierre. On Mar 22, 2013, at 5:02 PM, joel jaeggli <[email protected]> wrote: > On 3/21/13 5:40 AM, Pierre Francois wrote: >> >> Hello, >> >> We got some feedback during the last grow session that the "policy >> violations" we describe in the draft >> are not policy violations but forwarding states that one of the ISPs was not >> expecting to see across its network. >> >> Would a renaming of "policy violation" into "unexpected forwarding state" >> across the draft do? > it's important I think, to describe from whose vantage point the state is > unexpected. The path taken by traffic is a result of the expression of the > policy applied by all the participants that influenced the path. The > selective advertisement of more specific paths at the orgin for example is a > deliberate act on the part of the originator to influence path selection > whether for performance, arbitrage or other preference reasons that aren't > expressed in the bgp routing system... > > Mistakes I think readily produce unexpected results, if you do something > wrong it's likely produce a result you didn't expect. >> Cheers, >> >> Pierre. >> >> PS: We were also thinking about "non software defined paths" :-D > All the paths are defined by software. >> >> >> _______________________________________________ >> GROW mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/grow >> > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
