Dear Michael, Before we proceed, can you clarify how exactly draft-ietf-grow-as-path-prepending updates RFC 7454 and RFC 8195?
In relationship to 8195, the only sentence I see is "AS Path Prepending is discussed in Use of BGP Large Communities [RFC8195]." - which is true (8915 contains an example about prepending once), however the rest of the text in draft-ietf-grow-as-path-prepending-10 doesn't seem an 'update' in IETF document logistics parlance? Kind regards, Job On Tue, Feb 06, 2024 at 06:23:13PM +0000, Michael McBride wrote: > Hello grow chairs, > > Any chance we can get a wglc started on this draft after this latest > round of edits? The authors have felt it's ready for quite some time. > It's going on four years now. Please consider. > > Thanks, > mike > > > -----Original Message----- > From: GROW <[email protected]> On Behalf Of Michael McBride > Sent: Tuesday, January 16, 2024 11:21 PM > To: Martin Pels <[email protected]>; [email protected] > Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt > > Hi Martin, > > I just submitted a new version to address your (and Alejandro's) comments. > See my comments in line (MM): > > > -----Original Message----- > From: GROW <[email protected]> On Behalf Of Martin Pels > Sent: Tuesday, January 9, 2024 1:00 AM > To: [email protected] > Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt > > Hi, > > Some comments > ------------- > > Section 3.1 and 4: > As has been mentioned before on this list, I think using the term "route > leak" in this scenario is confusing. Something like "suboptimal" or > "unintended" routing would be a better fit. > > MM: Done. Used both terms in place of route leak. > > 3.2 and 3.3: > These do not appear to be separate problems, but rather two examples of the > same problem (a malicious, shorter route being preferred over a legitimate, > prepended route). > > MM: I think it is ok to describe two similar problems. > > 7: > This only mentions the sending side. There is also security advice to be > given to the accepting side (see section 3.5 and 3.6). Something like > "Accepting routes with extremely long AS_PATHs may cause increased memory > usage and possibly router crashes." > > MM: I inserted exactly that sentence. > > A reference to ASPA may also be useful in this section, since this could help > mitigate the effects of the route leaks described in 3.2 and 3.3. > > MM: Good idea, I added a sentence on ASPA. > > Text nits > --------- > > Abstract: > AS_Path attribute -> AS_PATH attribute > > MM: Done > > multiple entries of an AS -> multiple entries of an ASN > > MM: Done > > This document provides guidance with -> This document provides guidance for > > MM: Done > > 1: > the AS_PATH attribute which -> the AS_PATH attribute, which > > MM: Done > > 2: > today including -> today, including > > MM: Done > > 4: > more then 1 -> more than 1 > > MM: Done > > Thank you! I also added you and Alejandro to the acknowledgements. > Mike > > > > Kind regards, > Martin > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
