Dear Alvaro, Thank you for your detailed comments. I will work on the edits during the weekend and after recheck in our small co-author group, I'll push the next version.
May I ask you to give more details on this part of your comment? > Also, I believe the specification is not complete. Can you amplify what parts of mechanics are missing? ср, 9 июн. 2021 г. в 22:40, Alvaro Retana <[email protected]>: > Dear authors: > > Thank you for your work on addressing the route leaks problem! > > I think the document still needs a lot of work. In general, the > precision in the language is not what I would expect from a Standards > Track document. Also, I believe the specification is not complete. > Please see details inline. > > Instead of returning the document to the WG, and because it is short, > I am including a long list of suggestions below. Given all the > proposed changes, we will eventually need to run a new WGLC explicitly > including the grow WG -- I have cc'd them in this message as well. > > > Thanks! > > Alvaro. > > > [Line numbers from idnits.] > > > ... > 14 Route Leak Prevention using Roles in Update and Open messages > 15 draft-ietf-idr-bgp-open-policy-15 > > [minor] s/Update and Open/UPDATE and OPEN BGP > > > [major] Throughout the document the concept of "sending prefixes" (or > sometimes announcing them) is used -- I understand that these are > common phrases. However, that is not the terminology used in rfc4271. > Please use "route advertisement" (and variations) instead. Note that > "propagated" is also ok. > > > 17 Abstract > > 19 Route leaks are the propagation of BGP prefixes which violate > 20 assumptions of BGP topology relationships; e.g. passing a route > 21 learned from one lateral peer to another lateral peer or a > transit > 22 provider, passing a route learned from one transit provider to > 23 another transit provider or a lateral peer. Existing > approaches to > 24 leak prevention rely on marking routes by operator > configuration, > 25 with no check that the configuration corresponds to that of the > eBGP > 26 neighbor, or enforcement that the two eBGP speakers agree on the > 27 relationship. This document enhances BGP OPEN to establish > agreement > 28 of the (peer, customer, provider, Route Server, Route Server > client) > 29 relationship of two neighboring eBGP speakers to enforce > appropriate > 30 configuration on both sides. Propagated routes are then marked > with > 31 an Only to Customer (OTC) attribute according to the agreed > 32 relationship, allowing both prevention and detection of route > leaks. > > [minor] > > OLD> > This document enhances BGP OPEN to establish agreement of the (peer, > customer, provider, Route Server, Route Server client) relationship of > two neighboring eBGP speakers to enforce appropriate configuration on > both > sides. Propagated routes are then marked with an Only to Customer (OTC) > attribute according to the agreed relationship, allowing both prevention > and detection of route leaks. > > Suggestion> > This document enhances the BGP OPEN message to establish an agreement of > the relationship between two eBGP speakers in order to enforce > appropriate > configuration on both sides. Propagated routes are then marked > according > to the agreed relationship, allowing both prevention and detection of > route > leaks. > > > ... > 94 1. Introduction > > 96 A BGP route leak occurs when a route is learned from a transit > 97 provider or lateral peer and then announced to another provider > or > 98 lateral peer. See [RFC7908]. These are usually the result of > 99 misconfigured or absent BGP route filtering or lack of > coordination > 100 between two eBGP speakers. > > [nit] s/peer. See [RFC7908]./peer [RFC7908]. > > > [nit] s/between two eBGP speakers./between autonomous systems. > > > 102 The mechanism proposed in > 103 [I-D.ietf-grow-route-leak-detection-mitigation] uses large- > 104 communities to perform detection and mitigation of route leaks. > 105 While signaling using communities is easy to implement and > deploy > 106 quickly, it normally relies on operator-maintained policy > 107 configuration, which is vulnerable to misconfiguration > [Streibelt]. > 108 The community signal can also be stripped at the ISP boundaries -- Best regards, Alexander Azimov
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
