Then your proposal is not an alternative to Sriram's, but a complement. No?
Regards, Jakob. -----Original Message----- From: Job Snijders <job=40fastly....@dmarc.ietf.org> Sent: Wednesday, March 10, 2021 1:12 AM To: Jakob Heitz (jheitz) <jhe...@cisco.com> Cc: grow@ietf.org Subject: Re: [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation Dear Jakob, On Wed, Mar 10, 2021 at 02:10:24AM +0000, Jakob Heitz (jheitz) wrote: > Job, your suggestion kicks a different goal than > draft-ietf-grow-route-leak-detection-mitigation does. Yes, I'm aware I am suggesting a different approach to solve the problem of route leaks. > draft-ietf-grow-route-leak-detection-mitigation tries to determine > if your neighbor leaked the route to you. > To do that, you need to know how your neighbor received the route > before he sent it to you. > That's what the ASN in the LC is for. Right, so my proposal is that the neighbor does not (knowingly) leak routes to you, negating the need to additionally tag routes with more information than "this route is intended for not-for-peers (Down Only)" I believe the Section 6 'Only To Customer' Attribute described in https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15 can be implemented using the existing well-known NOPEER Attribute. Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow