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

From: <[email-masked]>
Date: Mon, 8 Mar 2021 06:19:50 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, February 9, 2021 1:30 AM
To: [email-masked]
Cc: [email-masked]
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%2F&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978557059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7TnSGyVp7p7innNedC5FT5ssVVOzrxYVyW6Tw5B0N90%3D&amp;reserved=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-03&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=2mJb%2B6acbTyMKNdkVy1UdsJQdxnELMqyh52GQkPFgm8%3D&amp;reserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qIZAlo8WOj85dXLPqQu%2BMq6cILpMdAd%2Ffye2bWYNAac%3D&amp;reserved=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-03&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mrQUS6ldbZk5CW9UcS5npaE4OZVhFBWIA4J%2Fpzat9FE%3D&amp;reserved=0

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:
https://eur03.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uh4ZqEom9mzHg6jws%2B92YRb47qaPnkg5q4G%2Fu2sDm%2BE%3D&amp;reserved=0

_______________________________________________
GROW mailing list
[email-masked]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uEdTSWuNSX%2FnNhgBQwPLLsHVQAV3oq1xYCdDJOXCDSc%3D&amp;reserved=0

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 9 Mar 2021 18:43:34 +0000

[email-masked] 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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 12 Mar 2021 06:33:31 +0000

Thanks Thomas.
I agree to remove the netflow reference.

Regards,
Jakob.

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, March 7, 2021 10:20 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]
Subject: RE: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt

Dear authors,

IE16 bgpSourceAsNumber

Best wishes
Thomas

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, February 9, 2021 1:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt

Abstract:

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 12 Mar 2021 06:49:07 -0800

Thanks for comments Thomas, agreed.

Cheers,
Jeff

> On Mar 11, 2021, at 22:33, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> Thanks Thomas.

---

From: Aftab Siddiqui <[email-masked]>
Date: Fri, 19 Mar 2021 12:10:27 +1100

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 <[email-masked]> wrote:

> https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
>
> 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
>
> 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.
>
> ftp://ftp.ietf.org/internet-drafts/
>
>
> https://www.ietf.org/mailman/listinfo/grow
>

-- 
Best Wishes,

Aftab Siddiqui

---

From: Michael McBride <[email-masked]>
Date: Fri, 19 Mar 2021 03:36:05 +0000

>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 <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-as-path-prepending%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610410515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=IOjQebjZxIXePDA7XsyVfs5CrScH%2FR7LGLnefB%2B97dE%3D&reserved=0>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610410515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=raNOCL0QtHjVknUbbMTnodSqpVfH1TxytRWlLqMp%2FCg%3D&reserved=0>
https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610420512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=m7A0Pv5pLvi%2BMRB9wcMXerH%2FODePRFrLGU5nPWk1blc%3D&reserved=0>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-as-path-prepending-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-grow-as-path-prepending-03&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610420512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=dW3g9v9b7itVBdIPcO%2BMZvx3lFzY5ecDKvHvCBR0fzA%3D&reserved=0>

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<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610430504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=NOzI%2BImzR0eLBI938sqtzAAAVspYv9ALaZgyMLYKTks%3D&reserved=0>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610430504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hKE4c3wbfnZwJJDk%2Fe8sNxUmSw8SOVyRgeXSJc41uN4%3D&reserved=0>

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610440498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=E9jQ7HHXFO86Xgl9acNqqa3sEbJOb%2FOXv%2BwQBv7%2BW%2BM%3D&reserved=0>

--
Best Wishes,

Aftab Siddiqui

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Mar 2021 04:22:00 -0400

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 <
[email-masked]> wrote:

> *>*Is this going to update BCP194/RFC7454? I don't see any reference in
> the draft.
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-as-path-prepending%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610410515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=IOjQebjZxIXePDA7XsyVfs5CrScH%2FR7LGLnefB%2B97dE%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610410515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=raNOCL0QtHjVknUbbMTnodSqpVfH1TxytRWlLqMp%2FCg%3D&reserved=0>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610420512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=m7A0Pv5pLvi%2BMRB9wcMXerH%2FODePRFrLGU5nPWk1blc%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-grow-as-path-prepending-03&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610420512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=dW3g9v9b7itVBdIPcO%2BMZvx3lFzY5ecDKvHvCBR0fzA%3D&reserved=0>
>
>
> until the htmlized version and diff are available at tools.ietf.org
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610430504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=NOzI%2BImzR0eLBI938sqtzAAAVspYv9ALaZgyMLYKTks%3D&reserved=0>
> .
>
> <https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610430504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hKE4c3wbfnZwJJDk%2Fe8sNxUmSw8SOVyRgeXSJc41uN4%3D&reserved=0>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C925e076323744066413708d8ea73d8f3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637517130610440498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=E9jQ7HHXFO86Xgl9acNqqa3sEbJOb%2FOXv%2BwQBv7%2BW%2BM%3D&reserved=0>
>
>
>
>
> --
>
> Best Wishes,
>
>
>
> Aftab Siddiqui
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 31 Mar 2021 00:35:54 +0000

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 <[email-masked]> On Behalf Of Gyan Mishra
Sent: Monday, March 29, 2021 1:22 AM
To: Michael McBride <[email-masked]>
Cc: [email-masked]; [email-masked]
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.

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

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

Thanks,
mike

Abstract:

--
Best Wishes,

Aftab Siddiqui

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347