Re: [GROW] Proposing a well-known BGP community for Anycast
Max, > On Jul 5, 2022, at 6:40 AM, Maximilian Wilhelm wrote: > after some discussion at RIPE84 we took the time to formalize a draft > to define a well-known BGP community to indicate a given prefix is > carrying Anycast traffic. The intent is to allow ISPs to do well > informed TE, especially in cases where they want to diverge from the > hot potato principle. Thanks for the draft. Minimally, I think the draft is "mostly harmless!" (with no offense to the idea). An advisory community that may help operators shape policy for the documented scenarios might be helpful. I think my major questions for the draft overlap whether an operator has any particular reason to trust the marking to be used to influence their policy. For example, if a /24 marked with the anycast community would bypass your TE and stick to shortest IGP distance, what's the likelihood that someone would intentionally mis-mark routes for this behavior? If we get to the point where this needs a prefix-list to decide what routes you'd trust, especially given the advice about no-export, does the community actually help the operator? -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Working Group Adoption Call: draft-lucente-grow-bmp-tlv-ebit (Ends 02/May/2022)
Dear all, The call for working group adoption ended some time ago, it seems numerous people are in favor of progressing this work in the GROW working group. Authors - please resubmit this draft as 'draft-ietf-grow-bmp-tlv-ebit' Kind regards, Job GROW co-chair On Fri, Apr 08, 2022 at 04:19:19PM +0200, Job Snijders wrote: > Hi GROW, > > At the IETF 113 GROW session Paolo asked whether this working group > could consider adoption for draft-lucente-grow-bmp-tlv-ebit. > > This message is a request to the group for feedback on whether this > internet-draft should be adopted. > > Title: >Support for Enterprise-specific TLVs in the BGP Monitoring Protocol > Abstract: >Message types defined by the BGP Monitoring Protocol (BMP) do >provision for data in TLV - Type, Length, Value - format, either in >the shape of optional TLVs at the end of a BMP message or Stats >Reports TLVs. However the space for Type value is unique and >governed by IANA. To allow the usage of vendor-specific TLVs, a >mechanism to define per-vendor Type values is required. In this >document we introduce an Enterprise Bit, or E-bit, for such purpose. > > The Internet-Draft can be found here: > https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-tlv-ebit > > Please share with the mailing list if you are think this work should be > adopted by GROW, willing to review and/or otherwise contribute to this > draft! > > WG Adoption call ends May 2nd, 2022. > > Kind regards, > > Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposing a well-known BGP community for Anycast
Hi Max, Thank you for publishing this draft. I have few questions after reading it. 1. If I have /24 and I advertise it over N peerings N>1 to my ISP from my DMZ does it automatically become ANYCAST prefix ? 1a. Note that I may have just one real host route in this /24 which I consider a true anycast destination. 2. Are you proposing to make any changes to best path selection based on the presence of the specified community ? 3. As I am sure you realize hot-potato or not-so-hot-potato routing is the result of choosing a best paths with a given next hop. Consideration of correct metric to this next hop is what makes it hot or not. Now with the use of route reflection where RRs are not in the data path that metric is normally fake (possibly hot from perspective of RR but not necessarily hot from the perspective of the client) . That is why I wrote RFC9107 ( https://datatracker.ietf.org/doc/rfc9107/) to allow to use the correct metric. Are mandating use of such tools for prefixes marked with ANYCAST community ? 4. Or alternatively to #3 are you suggesting to always use ADD-PATHS ALL for all prefixes marked with ANYCAST community ? Bottom line you have written good justification why such marking makes sense. But currently draft is missing more description when to mark when advertising given prefix over eBGP sessions (redundant advertisement is a norm these days). There is also no description on expected BGP implementation behavior when such prefixes marked with ANYCAST community are received by BGP speaker. Many thx, R. On Tue, Jul 5, 2022 at 12:40 PM Maximilian Wilhelm wrote: > Hey folks, > > after some discussion at RIPE84 we took the time to formalize a draft > to define a well-known BGP community to indicate a given prefix is > carrying Anycast traffic. The intent is to allow ISPs to do well > informed TE, especially in cases where they want to diverge from the > hot potato principle. > > You can find the draft at > > https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/ > > Happy to share this at the upcoming meeting and hear your thoughts! > > Thanks and best, > Max > > ___ > 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] Proposing a well-known BGP community for Anycast
Dear Max, On Tue, Jul 05, 2022 at 12:40:48PM +0200, Maximilian Wilhelm wrote: > after some discussion at RIPE84 we took the time to formalize a draft > to define a well-known BGP community to indicate a given prefix is > carrying Anycast traffic. The intent is to allow ISPs to do well > informed TE, especially in cases where they want to diverge from the > hot potato principle. > > You can find the draft at > > https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/ > > Happy to share this at the upcoming meeting and hear your thoughts! Thanks for bringing this to the working group! I've added your internet-draft to the agenda. Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Proposing a well-known BGP community for Anycast
Hey folks, after some discussion at RIPE84 we took the time to formalize a draft to define a well-known BGP community to indicate a given prefix is carrying Anycast traffic. The intent is to allow ISPs to do well informed TE, especially in cases where they want to diverge from the hot potato principle. You can find the draft at https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/ Happy to share this at the upcoming meeting and hear your thoughts! Thanks and best, Max ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
