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 protected]> On Behalf Of Gyan Mishra Sent: Monday, March 29, 2021 1:22 AM To: Michael McBride <[email protected]> Cc: [email protected]; [email protected] 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. Kind Regards Gyan On Thu, Mar 18, 2021 at 11:36 PM Michael McBride <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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/<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 protected]<mailto:[email protected]> 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 _______________________________________________ GROW mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
