Hi all, I was made aware of this draft in sidrops, and wrote there that I don't think it'll work because the AS in DO is overwritten with _last_ AS that propagates a route over peering rather than the _first_ (origin) AS. Maybe with the L thing everything will still work, but now that I see here that the point is to make it work using existing mechanisms, I don't see how that can happen. The community filters and route maps to make it all work would be way too complex.
Also, if you _really_ want to deploy tomorrow, don't use large communities or extended communities, because those aren't implemented widely enough: use regular communities. But it all comes back to this: if you see a DO, how do you know it's one from multiple hops away that indicates a leak, rather than one from the neighboring AS that is not problematic? My conclusion: this can't work and be deployed realistically with any type of communities. But you know where you can stick information that will be linked to a specific place in the AS path? In the AS path. What if we prepend all prefixes we announce to a peer with a 1, and prepend all prefixes that we receive from a peer wit a 2. So if there's a 1 or a 2 more than one hop beyond our peer AS, we have a leak. Adding a provider - customer indicator is left as an exercise for the reader. The only downside that I see is that with partial deployment, certain paths will be longer while others remain the same length for now, which will have impact on traffic engineering. Iljitsch _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
