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

[Jakob Heitz (jheitz)]

You can make a distinction between "cost out" and "de-prefer".
"Cost out" is for removing all traffic from the path so that it can be removed.
"de-prefer" is to make it a backup in case the preferred path fails.
"cost out" should be done with the graceful shutdown community if it is 
supported.

Another note: weight is not signaled in the BGP protocol. It stays in the 
router.

Regards,
Jakob.

From: GROW  On Behalf Of Gyan Mishra
Sent: Monday, March 29, 2021 1:22 AM
To: Michael McBride 
Cc: grow@ietf.org; i-d-annou...@ietf.org
Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt


Hi Mike & Authors

I would like to start my thanking the authors in formulating this much needed 
GROW Best Practice draft to help tackle the elephant in the room on the use of 
excessive pretending by operators on the internet and documenting ramifications 
from excessive pretending.

I would recommend changing the draft from Informational to BCP as this is truly 
a worthy cause to standardize.  I can help provide some more operations 
feedback to help make this draft a BCP for operators use of prepending and 
routing  policies.

The draft is very well written as you have a fine team of authors.

Few additions to section 2 from a Tier 1 such as Verizon from a NOC and 
operations standpoint.

There are a lot of permutations you can get into and I think most are covered 
here already.

From an operations POV the general goal of the NOC is monitoring traffic and 
traffic pattern shifts as well as taking links out of service for upgrades and 
maintenance.  In those instances links are prepended costed out so they don’t 
take traffic in an active / backup setup.

In general the goal is to have all inter provider links to other carrier to 
load balance traffic as evenly as possible some simple and so more complex 
policies involving prepending.

May want to mention prepend is typically outbound and conditional local 
preference is used inbound within for path preference within the operators core.
There maybe some cases where prepend is done inbound to cost out a link but 
generally not done as a lower prepend coming from a peering AS could alter the 
preferred path within the operators AS and have unwanted consequences.

Also the negative ripple effects of outbound prepend done multiple times in the 
same outbound direction by multiple providers chained together cascading effect 
of a growing as path effects that can lead to issues such as route leaking.

Counter prepends in opposing directions by non directly connected peers ripple 
effect of the path vector with excessive prepending.

May also want to talk about BGP atomic aggregates and as-set  and care to be 
taken with aggregation and LPM matching leaked route preference over aggregate 
can lead to unwanted traffic pattern changes.

Use cases:

Conditional preference and prepending making all links conditionally preferred 
and active or backup based on set of conditions.

Conditionally prefer one ISP over another ISP same or different ASBR.

Conditionally prefer one ASBR over another same site or between multiple sites. 
This typically for conditional or non conditional would be done via local 
preference within the operators AS not AS prepend inbound.

Conditionally use one path exclusively and other path solely as backup.

In the diagram I would make it more clear showing A and B as part of AS 1 and D 
and C part of AS 2 and E and F part of AS 3.

So typically within an operator core to most providers use conditional local 
preference inbound  to cost out a link and use local preference since it’s 
above as-path in BGP path selection so that even if E sent a 2x prepend 
outbound that ripple into the providers AS won’t impact the routing so B will 
still route through C and not reroute through shorter path through D.  Local 
preference is non transitive so the operators AS is not affected, however a 
downstream provider connected to AS 1 would see the 2x sent by E and create 
that ripple effect possibly alter the pathing.  That is also another adverse 
affect of using prepending inbound as that prepending as well can have a 
cascading adverse effect.

The cascading prepending adverse effect can happen in both directions.  The 
issue with prepending as a method of costing out a link has similar adverse 
cascading affects with IGP costing of transit links having the same type of 
rippling cascading type adverse affect.

Under alternatives to AS Path prepending for inbound we could mention what I 
stated to use conditional or non conditional local preference as an alternative 
to prepending. Another option to prepending is use of a conditional weight. 
Weight is at the top of the path selection so have to be carful and make 
conditional to account for failover and all scenarios.

Under best practices mention conditional prepending if you have to prepend and 
not ever use non conditional prepending.

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

[Gyan Mishra]

Hi Mike & Authors

I would like to start my thanking the authors in formulating this much
needed GROW Best Practice draft to help tackle the elephant in the room on
the use of excessive pretending by operators on the internet and
documenting ramifications from excessive pretending.

I would recommend changing the draft from Informational to BCP as this is
truly a worthy cause to standardize.  I can help provide some more
operations feedback to help make this draft a BCP for operators use of
prepending and routing  policies.

The draft is very well written as you have a fine team of authors.

Few additions to section 2 from a Tier 1 such as Verizon from a NOC and
operations standpoint.

There are a lot of permutations you can get into and I think most are
covered here already.

>From an operations POV the general goal of the NOC is monitoring traffic
and traffic pattern shifts as well as taking links out of service for
upgrades and maintenance.  In those instances links are prepended costed
out so they don’t take traffic in an active / backup setup.

In general the goal is to have all inter provider links to other carrier to
load balance traffic as evenly as possible some simple and so more complex
policies involving prepending.

May want to mention prepend is typically outbound and conditional local
preference is used inbound within for path preference within the operators
core.
There maybe some cases where prepend is done inbound to cost out a link but
generally not done as a lower prepend coming from a peering AS could alter
the preferred path within the operators AS and have unwanted consequences.

Also the negative ripple effects of outbound prepend done multiple times in
the same outbound direction by multiple providers chained together
cascading effect of a growing as path effects that can lead to issues such
as route leaking.

Counter prepends in opposing directions by non directly connected peers
ripple effect of the path vector with excessive prepending.

May also want to talk about BGP atomic aggregates and as-set  and care to
be taken with aggregation and LPM matching leaked route preference over
aggregate can lead to unwanted traffic pattern changes.

Use cases:

Conditional preference and prepending making all links conditionally
preferred and active or backup based on set of conditions.

Conditionally prefer one ISP over another ISP same or different ASBR.

Conditionally prefer one ASBR over another same site or between multiple
sites. This typically for conditional or non conditional would be done via
local preference within the operators AS not AS prepend inbound.

Conditionally use one path exclusively and other path solely as backup.

In the diagram I would make it more clear showing A and B as part of AS 1
and D and C part of AS 2 and E and F part of AS 3.

So typically within an operator core to most providers use conditional
local preference inbound  to cost out a link and use local preference since
it’s above as-path in BGP path selection so that even if E sent a 2x
prepend outbound that ripple into the providers AS won’t impact the routing
so B will still route through C and not reroute through shorter path
through D.  Local preference is non transitive so the operators AS is not
affected, however a downstream provider connected to AS 1 would see the 2x
sent by E and create that ripple effect possibly alter the pathing.  That
is also another adverse affect of using prepending inbound as that
prepending as well can have a cascading adverse effect.

The cascading prepending adverse effect can happen in both directions.  The
issue with prepending as a method of costing out a link has similar adverse
cascading affects with IGP costing of transit links having the same type of
rippling cascading type adverse affect.

Under alternatives to AS Path prepending for inbound we could mention what
I stated to use conditional or non conditional local preference as an
alternative to prepending. Another option to prepending is use of a
conditional weight. Weight is at the top of the path selection so have to
be carful and make conditional to account for failover and all scenarios.

Under best practices mention conditional prepending if you have to prepend
and not ever use non conditional prepending.

Kind Regards

Gyan


On Thu, Mar 18, 2021 at 11:36 PM Michael McBride <
michael.mcbr...@futurewei.com> wrote:

> *>*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.
>
>
>
> Thanks,
>
> mike
>
>
>
> On Tue, Feb 9, 2021 at 11:29 AM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Global Routing Operations WG of the IETF.
>
> Title   : AS Path Prepending
>

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

[Michael McBride]

>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.

Thanks,
mike

On Tue, Feb 9, 2021 at 11:29 AM 
mailto:internet-dra...@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : AS Path Prepending
Authors : Mike McBride
  Doug Madory
  Jeff Tantsura
  Robert Raszuk
  Hongwei Li
  Jakob Heitz
Filename: draft-ietf-grow-as-path-prepending-03.txt
Pages   : 10
Date: 2021-02-08

Abstract:
   AS Path Prepending provides a tool to manipulate the BGP AS_Path
   attribute through prepending multiple entries of an AS.  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,to the internet community, with how best to utilize AS Path
   Prepending in order to avoid negatively affecting the internet.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-03
https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-as-path-prepending-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
GROW mailing list
GROW@ietf.org

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

[Aftab Siddiqui]

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

On Tue, Feb 9, 2021 at 11:29 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Global Routing Operations WG of the IETF.
>
> Title   : AS Path Prepending
> Authors : Mike McBride
>   Doug Madory
>   Jeff Tantsura
>   Robert Raszuk
>   Hongwei Li
>   Jakob Heitz
> Filename: draft-ietf-grow-as-path-prepending-03.txt
> Pages   : 10
> Date: 2021-02-08
>
> Abstract:
>AS Path Prepending provides a tool to manipulate the BGP AS_Path
>attribute through prepending multiple entries of an AS.  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,to the internet community, with how best to utilize AS Path
>Prepending in order to avoid negatively affecting the internet.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-03
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-as-path-prepending-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>


-- 
Best Wishes,

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

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

[Jeff Tantsura]

Thanks for comments Thomas, agreed.

Cheers,
Jeff

> On Mar 11, 2021, at 22:33, Jakob Heitz (jheitz)  wrote:
> 
> Thanks Thomas.
> I agree to remove the netflow reference.
> 
> Regards,
> Jakob.
> 
> -Original Message-
> From: thomas.g...@swisscom.com  
> Sent: Sunday, March 7, 2021 10:20 PM
> To: michael.mcbr...@futurewei.com; dmad...@kentik.com; 
> jefftant.i...@gmail.com; rob...@raszuk.net; Jakob Heitz (jheitz) 
> 
> Cc: grow@ietf.org
> Subject: RE: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt
> 
> Dear authors,
> 
> Speaking as a network operator, I think your draft has merit and I agree BGP 
> as-path prepending is misused on the Internet and a best common practice 
> draft is welcomed.
> 
> I like to comment on section 3.4
> https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-03#section-3.4
> 
> You are referring to the impact of BGP as-path length onto IPFIX.
> 
> To my current knowledge, there are only 4 well known IPFIX entities 
> registered at IANA related to BGP as-path
> 
> https://www.iana.org/assignments/ipfix/ipfix.xhtml
> 
> IE16 bgpSourceAsNumber
> IE17 bgpDestinationAsNumber
> IE128 bgpNextAdjacentAsNumber
> IE129 bgpPrevAdjacentAsNumber
> 
> None of them contain the entire BGP as-path array. Only the first or last BGP 
> ASN of the path array for source and destination IPv4/6 address of the flow.
> 
> The reason to my knowledge is that for UDP transport, which is one of the 
> options to export IPFIX and the most supported, does not support 
> segmentation. Thus limiting IPFIX of the amount data records and values 
> within a record which can be exposed per message even to a lower value than 
> RFC 7011 defines with 65535 bytes as maximum message size.
> 
> https://tools.ietf.org/html/rfc7011#section-10
> https://tools.ietf.org/html/rfc7011#section-10.3.3
> 
> The BGP as-path array could be potentially be exposed with code points from 
> the private enterprise number space. If that would be the case than same 
> operational considerations would apply than in RFC 8549 section 7 described 
> since BGP communities are also array's.
> 
> https://tools.ietf.org/html/rfc8549#section-7
> 
> Therefore I either recommend to remove the IPFIX/Netflow relevant part from 
> the draft or clearly state the scenario where with private enterprise number 
> BGP as-path array is exposed and refer to example implementations as they are 
> nonstandard.
> 
> Best wishes
> Thomas
> 
> -Original Message-----
> From: GROW  On Behalf Of internet-dra...@ietf.org
> Sent: Tuesday, February 9, 2021 1:30 AM
> To: i-d-annou...@ietf.org
> Cc: grow@ietf.org
> Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Global Routing Operations WG of the IETF.
> 
>Title   : AS Path Prepending
>Authors : Mike McBride
>  Doug Madory
>  Jeff Tantsura
>  Robert Raszuk
>  Hongwei Li
>  Jakob Heitz
>Filename: draft-ietf-grow-as-path-prepending-03.txt
>Pages   : 10
>Date: 2021-02-08
> 
> Abstract:
>   AS Path Prepending provides a tool to manipulate the BGP AS_Path
>   attribute through prepending multiple entries of an AS.  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,to the internet community, with how best to utilize AS Path
>   Prepending in order to avoid negatively affecting the internet.
> 
> 
> The IETF datatracker status page for this draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-as-path-prepending%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978557059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7TnSGyVp7p7innNedC5FT5ssVVOzrxYVyW6Tw5B0N90%3Dreserved=0
> 
> There are also htmlized versions available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CU

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

[Jakob Heitz (jheitz)]

Thanks Thomas.
I agree to remove the netflow reference.

Regards,
Jakob.

-Original Message-
From: thomas.g...@swisscom.com  
Sent: Sunday, March 7, 2021 10:20 PM
To: michael.mcbr...@futurewei.com; dmad...@kentik.com; jefftant.i...@gmail.com; 
rob...@raszuk.net; Jakob Heitz (jheitz) 
Cc: grow@ietf.org
Subject: RE: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt

Dear authors,

Speaking as a network operator, I think your draft has merit and I agree BGP 
as-path prepending is misused on the Internet and a best common practice draft 
is welcomed.

I like to comment on section 3.4
https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-03#section-3.4

You are referring to the impact of BGP as-path length onto IPFIX.

To my current knowledge, there are only 4 well known IPFIX entities registered 
at IANA related to BGP as-path

https://www.iana.org/assignments/ipfix/ipfix.xhtml

IE16 bgpSourceAsNumber
IE17 bgpDestinationAsNumber
IE128 bgpNextAdjacentAsNumber
IE129 bgpPrevAdjacentAsNumber

None of them contain the entire BGP as-path array. Only the first or last BGP 
ASN of the path array for source and destination IPv4/6 address of the flow.

The reason to my knowledge is that for UDP transport, which is one of the 
options to export IPFIX and the most supported, does not support segmentation. 
Thus limiting IPFIX of the amount data records and values within a record which 
can be exposed per message even to a lower value than RFC 7011 defines with 
65535 bytes as maximum message size.

https://tools.ietf.org/html/rfc7011#section-10
https://tools.ietf.org/html/rfc7011#section-10.3.3

The BGP as-path array could be potentially be exposed with code points from the 
private enterprise number space. If that would be the case than same 
operational considerations would apply than in RFC 8549 section 7 described 
since BGP communities are also array's.

https://tools.ietf.org/html/rfc8549#section-7

Therefore I either recommend to remove the IPFIX/Netflow relevant part from the 
draft or clearly state the scenario where with private enterprise number BGP 
as-path array is exposed and refer to example implementations as they are 
nonstandard.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, February 9, 2021 1:30 AM
To: i-d-annou...@ietf.org
Cc: grow@ietf.org
Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : AS Path Prepending
Authors : Mike McBride
  Doug Madory
  Jeff Tantsura
  Robert Raszuk
  Hongwei Li
  Jakob Heitz
Filename: draft-ietf-grow-as-path-prepending-03.txt
Pages   : 10
Date: 2021-02-08

Abstract:
   AS Path Prepending provides a tool to manipulate the BGP AS_Path
   attribute through prepending multiple entries of an AS.  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,to the internet community, with how best to utilize AS Path
   Prepending in order to avoid negatively affecting the internet.


The IETF datatracker status page for this draft is:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-as-path-prepending%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978557059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7TnSGyVp7p7innNedC5FT5ssVVOzrxYVyW6Tw5B0N90%3Dreserved=0

There are also htmlized versions available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2mJb%2B6acbTyMKNdkVy1UdsJQdxnELMqyh52GQkPFgm8%3Dreserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qIZAlo8WOj85dXLPqQu%2BMq6cILpMdAd%2Ffye2bWYNAac%3Dreserved=0

A diff

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

[Nick Hilliard]

thomas.g...@swisscom.com wrote on 08/03/2021 06:19:

The BGP as-path array could be potentially be exposed with code
points from the private enterprise number space. If that would be the
case than same operational considerations would apply than in RFC
8549 section 7 described since BGP communities are also array's.

Thomas,

I agree in theory that this would be a nice idea but I'm concerned about 
the performance impact it might have on ipfix / netflow implementations. 
 Normal operating cases would include situations where the as path 
changed during the lifetime of the flow (what do you do here? ignore the 
change?  update the cache and dump the original path? store multiple 
flows?), to lookup performance characteristics (AS path can be very 
long).  It would be advisable to solicit input from equipment 
manufacturers before rushing ahead with something like this, because 
highly performant netflow / ipfix is generally handled in hardware, and 
there may be limited options in terms of flexibility.


Nick

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

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

[Thomas.Graf]

Dear authors,

Speaking as a network operator, I think your draft has merit and I agree BGP 
as-path prepending is misused on the Internet and a best common practice draft 
is welcomed.

I like to comment on section 3.4
https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-03#section-3.4

You are referring to the impact of BGP as-path length onto IPFIX.

To my current knowledge, there are only 4 well known IPFIX entities registered 
at IANA related to BGP as-path

https://www.iana.org/assignments/ipfix/ipfix.xhtml

IE16 bgpSourceAsNumber
IE17 bgpDestinationAsNumber
IE128 bgpNextAdjacentAsNumber
IE129 bgpPrevAdjacentAsNumber

None of them contain the entire BGP as-path array. Only the first or last BGP 
ASN of the path array for source and destination IPv4/6 address of the flow.

The reason to my knowledge is that for UDP transport, which is one of the 
options to export IPFIX and the most supported, does not support segmentation. 
Thus limiting IPFIX of the amount data records and values within a record which 
can be exposed per message even to a lower value than RFC 7011 defines with 
65535 bytes as maximum message size.

https://tools.ietf.org/html/rfc7011#section-10
https://tools.ietf.org/html/rfc7011#section-10.3.3

The BGP as-path array could be potentially be exposed with code points from the 
private enterprise number space. If that would be the case than same 
operational considerations would apply than in RFC 8549 section 7 described 
since BGP communities are also array's.

https://tools.ietf.org/html/rfc8549#section-7

Therefore I either recommend to remove the IPFIX/Netflow relevant part from the 
draft or clearly state the scenario where with private enterprise number BGP 
as-path array is exposed and refer to example implementations as they are 
nonstandard.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, February 9, 2021 1:30 AM
To: i-d-annou...@ietf.org
Cc: grow@ietf.org
Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : AS Path Prepending
Authors : Mike McBride
  Doug Madory
  Jeff Tantsura
  Robert Raszuk
  Hongwei Li
  Jakob Heitz
Filename: draft-ietf-grow-as-path-prepending-03.txt
Pages   : 10
Date: 2021-02-08

Abstract:
   AS Path Prepending provides a tool to manipulate the BGP AS_Path
   attribute through prepending multiple entries of an AS.  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,to the internet community, with how best to utilize AS Path
   Prepending in order to avoid negatively affecting the internet.


The IETF datatracker status page for this draft is:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-as-path-prepending%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978557059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7TnSGyVp7p7innNedC5FT5ssVVOzrxYVyW6Tw5B0N90%3Dreserved=0

There are also htmlized versions available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2mJb%2B6acbTyMKNdkVy1UdsJQdxnELMqyh52GQkPFgm8%3Dreserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qIZAlo8WOj85dXLPqQu%2BMq6cILpMdAd%2Ffye2bWYNAac%3Dreserved=0

A diff from the previous version is available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown

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

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : AS Path Prepending
Authors : Mike McBride
  Doug Madory
  Jeff Tantsura
  Robert Raszuk
  Hongwei Li
  Jakob Heitz
Filename: draft-ietf-grow-as-path-prepending-03.txt
Pages   : 10
Date: 2021-02-08

Abstract:
   AS Path Prepending provides a tool to manipulate the BGP AS_Path
   attribute through prepending multiple entries of an AS.  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,to the internet community, with how best to utilize AS Path
   Prepending in order to avoid negatively affecting the internet.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-03
https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-as-path-prepending-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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