Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt
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. Kind Regards Gyan On Thu, Mar 18, 2021 at 11:36 PM
[GROW] Martin Duke's No Objection on draft-ietf-grow-bmp-local-rib-10: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-grow-bmp-local-rib-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib/ -- COMMENT: -- It would help to expand acronyms on first use (RD, VRF, etc.) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Genart last call review of draft-ietf-grow-bmp-local-rib-10
Hi Tim, On 30/03/2021, 04:22, "Tim Evens (tievens)" wrote: > Thank you for your review and catching these nits. Please see my > comments marked [tievens] inline. You can see my pending PR > (https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib/pull/22) for > all these changes. Once approved, I'll submit revision 11. Thanks! > On 3/20/21, 3:33 AM, "Thomas Fossati via Datatracker" > wrote: > * Section 8.2 > * It is not clear to me if saying "and proposes that peer flags are > specific to the peer type" you are asking IANA to modify the > contents and/or structure of the BMP Peer Flags registry? If so, > the request to IANA should be made more explicit. > > > [tievens] I have updated it to: "This document defines that peer flags > are specific to the Loc-RIB instance peer type. As defined in > (Section 4.2)". We do have a problem as IANA did add this flag under > the general table as flag/bit 4, which is incorrect. The flag is F in > position 0, which would be documented as flag 0. The draft requests > that the peer flags be unique by peer type. IANA would need to > create a new table based on the peer type of 3. I understand that the flags space is *very* small and that in hindsight making the flags dependent on the peer types would have been a better choice. However, retroactively changing the wire semantics looks like something that should be treated with care. If you really want to go that way I think the document should contain an analysis of the impact on existing deployments and any dependent tooling around those. The requests to IANA should be made more precise too: for example, what happens to the V, L, A, and O flags? To which peer types would they be associated with in the new table? Or, you could make it someone else's problem, after the 8th flag has been allocated. > * Section 8.3 > * Should "informational message TLV types" be "Initiation Message TLV > type" instead? > > > [tievens] No. Considering the original draft RFC7854 defines some of > the information TLV messages to be specific by type, it required IANA > to create more than one table for informational TLVs as defined in > section 4.4 of RFC7854. RFC7854 defines that Peer UP does have > information TLV String, but fails to identify the type number and does > not request from IANA to define message TLVs for Peer Up. Instead, > RFC7854 does state in Section 4.4 that the defined info TLVs are used > by both INIT and Peer Up messages, but it doesn't make that clear in > the IANA request. I'm thinking that IANA can update the title to > indicate "Initiation and Peer Up" as they use the same registry/table. > RFC8671 also added a new type, which is documented under that table. This IANA situation looks quite intricate. I suggest you clarify exactly what the desired state of the BMP parameters registry is and make it crystal clear in the IANA considerations section because as it stands I don't think it is easily actionable. cheers! PS: Have you considered adding an "Implementation Status" section to the doc (BCP 205) and talk a bit about OpenBMP? IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
