[Sidrops] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

[Iljitsch van Beijnum <[e-mail]>]

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