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

Hi, Iljitch,

The document is being revised by the authors.
The rewrite of any DO will be going away as part of that, as will L.
The end result will be that the Large communities (for RLP) will be a
complete list of all DO ASNs (i.e. as appropriate to the topology wrt
transit relationships), and nothing else new.
This makes it simple, reliable, deployable, and scalable, and allows
non-adjacent ASNs to identify/stop leaks (even if an intermediate ASN
deliberately allows the leak to pass, for whatever reason.)
(BTW: You should only ever receive DO-marked prefixes from upstream transit
providers, or from a peer where the peer ASN is the only DO=N value.)

Putting a first entry for blocking leaks at the top of route-maps won't
interfere with any other route-map mechanics.
If a route-map didn't previously exist, it will need to but consist only of
the block.
Route-maps for blocking will only need to be modified or created on
customer and peer facing connections.
Transit connections won't have the need or ability to detect leaks; this is
a trade-off on simplicity, reliability, and scalability.

Brian

On Tue, Jul 2, 2019 at 3:22 AM Iljitsch van Beijnum <iljitsch=
40muada.com@dmarc.ietf.org> wrote:

> 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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>