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

[Michael McBride <[e-mail]>]

Great thank you David. I kept 7454 in the updates and made the other changes. New version now posted.

mike


From: David Farmer <[e-mail]>
Sent: Tuesday, February 6, 2024 2:34 PM
To: Michael McBride <[e-mail]>
Cc: Job Snijders <[e-mail]>; [e-mail]
Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt

In looking at RFC 7454, I would argue that this document updates RFC 7454 by expanding and providing detail to the recommendation "to discourage excessive pretending in such paths" in the first bullet of Section 9, AS Path Filtering.

I don't think this document updates RFC 8195, but I think the reference to RFC 8195 should remain in the introduction and be revised slightly;

Old; "AS Path Prepending is discussed in Use of BGP Large Communities [RFC8195]."

New; "[RFC8195] discusses using BGP Large Communities for traffic engineering through selective AS_PATH prepending."

Also, by the way, I prefer David Farmer to Dave Farmer in the acknowledgment section.

Thanks

On Tue, Feb 6, 2024 at 2:43 PM Michael McBride <[e-mail]<mailto:[e-mail]>> wrote:
Sounds good, I’ll remove the updates and submit a new version tonight.

mike


From: Job Snijders <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 6, 2024 12:38 PM
To: Michael McBride <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt

Dear Michael,

Perhaps a question was taken as a suggestion, but the draft doesn’t describe how it updates either RFC.

Removing the updates section indeed is an option!

Kind regards,

Job

On Tue, 6 Feb 2024 at 21:09, Michael McBride <[e-mail]<mailto:[e-mail]>> wrote:
Hi Job,

That is based on a list comment from a few years ago:

"Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt
Michael McBride <[e-mail]<mailto:[e-mail]>> Fri, 19 March 2021 03:36 UTCShow header

>Is this going to update BCP194/RFC7454? I don't see any reference in the draft.

We probably should. Good suggestion. I was thinking updating 8195 but 7454 appears more appropriate.

We will update the draft, based upon comments from last week, and add 7454 unless we hear otherwise."


We didn't hear otherwise. We can remove the updates section if it doesn't make sense.

Thanks,
mike

-----Original Message-----
From: Job Snijders <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 6, 2024 11:13 AM
To: Michael McBride <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Michael McBride
> Sent: Tuesday, January 16, 2024 11:21 PM
> To: Martin Pels <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Martin Pels
> Sent: Tuesday, January 9, 2024 1:00 AM
> To: [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www/>.
> ietf.org<http://ietf.org/>%2Fmailman%2Flistinfo%2Fgrow&data=05%7C02%7Cmichael.mcbride%40
> futurewei.com<http://futurewei.com/>%7C052597d7319044e8a81f08dc27479aaf%7C0fee8ff2a3b240189c7
> 53a1d5591fedc%7C1%7C0%7C638428435700366546%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C&sdata=yqbTOmCV%2BPE27ILiyacESZZQadZINHldOq%2BO1ccU4eY%3D&reserv
> ed=0
>
> _______________________________________________
> GROW mailing list
> [e-mail]<mailto:[e-mail]>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www/>.
> ietf.org<http://ietf.org/>%2Fmailman%2Flistinfo%2Fgrow&data=05%7C02%7Cmichael.mcbride%40
> futurewei.com<http://futurewei.com/>%7C052597d7319044e8a81f08dc27479aaf%7C0fee8ff2a3b240189c7
> 53a1d5591fedc%7C1%7C0%7C638428435700374465%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C&sdata=7EnjKzvAEJrnEUF48O%2BAgAk3jBIZ3ARVbbvQp5UrjoE%3D&reserved
> =0
>
> _______________________________________________
> GROW mailing list
> [e-mail]<mailto:[e-mail]>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www/>.
> ietf.org<http://ietf.org/>%2Fmailman%2Flistinfo%2Fgrow&data=05%7C02%7Cmichael.mcbride%40
> futurewei.com<http://futurewei.com/>%7C052597d7319044e8a81f08dc27479aaf%7C0fee8ff2a3b240189c7
> 53a1d5591fedc%7C1%7C0%7C638428435700379252%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C&sdata=kCZgZPm5fpy%2BwGYWX3zEncV4DOnA0HADFgjLht4vHOE%3D&reserved
> =0
_______________________________________________
GROW mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/grow


--
===============================================
David Farmer               Email:[e-mail]<mailto:[e-mail]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================