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

[David Farmer]

If you keep it as updating RFC 7454, I believe you need to say it does so
in the abstract. Also, somewhere in the document, probably in the
introduction, you need to explain how it updates RFC 7454, that is how this
document relates to RFC 7454.

Thanks.

On Tue, Feb 6, 2024 at 8:42 PM Michael McBride <
michael.mcbr...@futurewei.com> wrote:

> Great thank you David. I kept 7454 in the updates and made the other
> changes. New version now posted.
>
>
>
> mike
>
>
>
>
>
> *From:* David Farmer 
> *Sent:* Tuesday, February 6, 2024 2:34 PM
> *To:* Michael McBride 
> *Cc:* Job Snijders ; grow@ietf.org
> *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 <
> michael.mcbr...@futurewei.com> wrote:
>
> Sounds good, I’ll remove the updates and submit a new version tonight.
>
>
>
> mike
>
>
>
>
>
> *From:* Job Snijders 
> *Sent:* Tuesday, February 6, 2024 12:38 PM
> *To:* Michael McBride 
> *Cc:* grow@ietf.org
> *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 <
> michael.mcbr...@futurewei.com> 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  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 
> Sent: Tuesday, February 6, 2024 11:13 AM
> To: Michael McBride 
> Cc: grow@ietf.org
> 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 +, 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  On Behalf Of Michael McBride
> > Sent: Tuesday, January 16, 2024 11:21 PM
> > To: Martin Pels ; 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  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:
> > 

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

[Michael McBride]

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

mike


From: David Farmer 
Sent: Tuesday, February 6, 2024 2:34 PM
To: Michael McBride 
Cc: Job Snijders ; grow@ietf.org
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 
mailto:michael.mcbr...@futurewei.com>> wrote:
Sounds good, I’ll remove the updates and submit a new version tonight.

mike


From: Job Snijders mailto:j...@fastly.com>>
Sent: Tuesday, February 6, 2024 12:38 PM
To: Michael McBride 
mailto:michael.mcbr...@futurewei.com>>
Cc: grow@ietf.org
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 
mailto:michael.mcbr...@futurewei.com>> 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 
mailto:michael.mcbr...@futurewei.com>> 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 mailto:j...@fastly.com>>
Sent: Tuesday, February 6, 2024 11:13 AM
To: Michael McBride 
mailto:michael.mcbr...@futurewei.com>>
Cc: grow@ietf.org
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 +, 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 mailto:grow-boun...@ietf.org>> On Behalf Of 
> Michael McBride
> Sent: Tuesday, January 16, 2024 11:21 PM
> To: Martin Pels mailto:mp...@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 mailto:grow-boun...@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 

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

[internet-drafts]

Internet-Draft draft-ietf-grow-as-path-prepending-11.txt is now available. It
is a work item of the Global Routing Operations (GROW) WG of the IETF.

   Title:   AS Path Prepending
   Authors: Mike McBride
Doug Madory
Jeff Tantsura
Robert Raszuk
Hongwei Li
Jakob Heitz
Gyan Mishra
   Name:draft-ietf-grow-as-path-prepending-11.txt
   Pages:   13
   Dates:   2024-02-06

Abstract:

   AS Path Prepending provides a tool to manipulate the BGP AS_PATH
   attribute through prepending multiple entries of an ASN.  AS Path
   Prepending is used to deprioritize a route or alternate path.  By
   prepending the local ASN multiple times, ASs can make advertised AS
   paths appear artificially longer.  Excessive AS Path Prepending has
   caused routing issues in the Internet.  This document provides
   guidance for the use of AS Path Prepending, including alternative
   solutions, in order to avoid negatively affecting the Internet.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending-11

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-as-path-prepending-11

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[David Farmer]

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 <
michael.mcbr...@futurewei.com> wrote:

> Sounds good, I’ll remove the updates and submit a new version tonight.
>
>
>
> mike
>
>
>
>
>
> *From:* Job Snijders 
> *Sent:* Tuesday, February 6, 2024 12:38 PM
> *To:* Michael McBride 
> *Cc:* grow@ietf.org
> *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 <
> michael.mcbr...@futurewei.com> 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  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 
> Sent: Tuesday, February 6, 2024 11:13 AM
> To: Michael McBride 
> Cc: grow@ietf.org
> 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 +, 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  On Behalf Of Michael McBride
> > Sent: Tuesday, January 16, 2024 11:21 PM
> > To: Martin Pels ; 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  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 

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

[Michael McBride]

Sounds good, I'll remove the updates and submit a new version tonight.

mike


From: Job Snijders 
Sent: Tuesday, February 6, 2024 12:38 PM
To: Michael McBride 
Cc: grow@ietf.org
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 
mailto:michael.mcbr...@futurewei.com>> 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 
mailto:michael.mcbr...@futurewei.com>> 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 mailto:j...@fastly.com>>
Sent: Tuesday, February 6, 2024 11:13 AM
To: Michael McBride 
mailto:michael.mcbr...@futurewei.com>>
Cc: grow@ietf.org
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 +, 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 mailto:grow-boun...@ietf.org>> On Behalf Of 
> Michael McBride
> Sent: Tuesday, January 16, 2024 11:21 PM
> To: Martin Pels mailto:mp...@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 mailto:grow-boun...@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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fgrow=05%7C02%7Cmichael.mcbride%40
> futurewei.com%7C052597d7319044e8a81f08dc27479aaf%7C0fee8ff2a3b240189c7
> 

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

[Job Snijders]

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 
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  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 
> Sent: Tuesday, February 6, 2024 11:13 AM
> To: Michael McBride 
> Cc: grow@ietf.org
> 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 +, 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  On Behalf Of Michael McBride
> > Sent: Tuesday, January 16, 2024 11:21 PM
> > To: Martin Pels ; 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  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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fgrow=05%7C02%7Cmichael.mcbride%40
> > futurewei.com%7C052597d7319044e8a81f08dc27479aaf%7C0fee8ff2a3b240189c7
> > 53a1d5591fedc%7C1%7C0%7C638428435700366546%7CUnknown%7CTWFpbGZsb3d8eyJ
> > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> > %7C%7C=yqbTOmCV%2BPE27ILiyacESZZQadZINHldOq%2BO1ccU4eY%3D
> > ed=0
> >
> > ___
> > GROW mailing list
> > GROW@ietf.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > 

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

[Michael McBride]

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  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  
Sent: Tuesday, February 6, 2024 11:13 AM
To: Michael McBride 
Cc: grow@ietf.org
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 +, 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  On Behalf Of Michael McBride
> Sent: Tuesday, January 16, 2024 11:21 PM
> To: Martin Pels ; 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  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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fgrow=05%7C02%7Cmichael.mcbride%40
> futurewei.com%7C052597d7319044e8a81f08dc27479aaf%7C0fee8ff2a3b240189c7
> 53a1d5591fedc%7C1%7C0%7C638428435700366546%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C=yqbTOmCV%2BPE27ILiyacESZZQadZINHldOq%2BO1ccU4eY%3D
> ed=0
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fgrow=05%7C02%7Cmichael.mcbride%40
> futurewei.com%7C052597d7319044e8a81f08dc27479aaf%7C0fee8ff2a3b240189c7
> 53a1d5591fedc%7C1%7C0%7C638428435700374465%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C=7EnjKzvAEJrnEUF48O%2BAgAk3jBIZ3ARVbbvQp5UrjoE%3D
> =0
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.

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

[Job Snijders]

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 +, 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  On Behalf Of Michael McBride
> Sent: Tuesday, January 16, 2024 11:21 PM
> To: Martin Pels ; 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  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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Michael McBride]

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  On Behalf Of Michael McBride
Sent: Tuesday, January 16, 2024 11:21 PM
To: Martin Pels ; 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  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

[GROW] I-D Action: draft-ietf-grow-bmp-peer-up-03.txt

[internet-drafts]

Internet-Draft draft-ietf-grow-bmp-peer-up-03.txt is now available. It is a
work item of the Global Routing Operations (GROW) WG of the IETF.

   Title:   BMP Peer Up Message Namespace
   Authors: John Scudder
Paolo Lucente
   Name:draft-ietf-grow-bmp-peer-up-03.txt
   Pages:   7
   Dates:   2024-02-06

Abstract:

   RFC 7854, BMP, uses different message types for different purposes.
   Most of these are Type, Length, Value (TLV) structured.  One message
   type, the Peer Up message, lacks a set of TLVs defined for its use,
   instead sharing a namespace with the Initiation message.  Subsequent
   experience has shown that this namespace sharing was a mistake, as it
   hampers the extension of the protocol.

   This document updates RFC 7854 by creating an independent namespace
   for the Peer Up message.  It also updates RFC 8671 and RFC 9069 by
   moving the defined codepoints in the newly introduced registry.  The
   changes in this document are formal only, compliant implementations
   of RFC 7854, RFC 8671 and RFC 9069 also comply with this
   specification.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-peer-up/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-peer-up-03

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-bmp-peer-up-03

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Last Call (WGLC) for draft-ietf-grow-bmp-peer-up (start 22/Jan/2024 end 6/Feb/2024)

[Paolo Lucente]

Surely Maxence, thanks for your comment. I will update the draft with 
this note.


Paolo


On 25/1/24 07:53, Maxence Younsi wrote:

Dear all,


I support the adoption of draft-ietf-grow-bmp-peer-up.

A small detail I think could be changed is that the definition of a 
string in Section 2 should specify that the length in the TLV's Length 
field is in bytes and not a number of character ("whose length *in 
bytes* is given by [...]" ). It is already specified in Section 3.3:


*  Information Length (2 bytes): The length of the following
   Information field, in bytes.

but not in Section 2:

2.  String Definition

A string TLV is a free-form sequence of UTF-8 characters whose length
is given by the TLV's Length field.  There is no requirement to
terminate the string with a null (or any other particular) character
-- the Length field gives its termination.



Kind regards,

Maxence.


___
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