Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt

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 <grow-bounces@ietf.org> On Behalf Of Michael McBride
> Sent: Tuesday, January 16, 2024 11:21 PM
> To: Martin Pels <mpels@ripe.net>; grow@ietf.org
> 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 <grow-bounces@ietf.org> On Behalf Of Martin Pels
> Sent: Tuesday, January 9, 2024 1:00 AM
> To: grow@ietf.org
> 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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow