Hi Martin, Jeff and colleagues. After some internal discussion, we have submitted the -02 version of the draft, you can find it available here: https://datatracker.ietf.org/doc/html/draft-spaghetti-grow-bcp-ext-comms
In short we adopted your recommedations and we do believe that IXP Route Servers should not scrub completely the BGP Extendend communities as this might be a useful feature for few peers signaling each-other. However, we do believe that BGP Extendend communities related to L3VPNs (route targets) should not be leaked to the Route Servers and they don’t have valid place in Multilateral Peering. This is depicted in section 4. Please have a reading and let us know what do you believe after these modifications. Kind Regards Stavros From: Martin Pels <[email protected]> Date: Saturday, 30 March 2024 at 12:56 To: Stavros Konstantaras <[email protected]> Cc: [email protected] [email protected] <[email protected]>, Jeff Haas <[email protected]> Subject: Re: [GROW] WGADOPTION - draft-spaghetti-grow-bcp-ext-comms - ENDS 04/08/2024 - Apr 8th 2024 Hi Stavros, I support this work. The Extended Communities for RS signaling were always a kludge, so I'd like to see them go away. On 15/03/2024 10:28, Stavros Konstantaras wrote: > Hi Jeff, > > Thank you very much for your comment. As Job said, the draft is > targeting the Route Server infrastructure of Internet Exchange Points, > but do you believe that this is something that needs further > clarification in the draft? There is still some inconsistency in the 01 text. Section 3 talks about Extended Communities as a tool for "IXP Route Server signaling purposes". However, section 4 advises on the use of Extended Communities on the public Internet in general. If I read the discussion correctly, your target for this draft is solely the Route Server signaling case. Then, instead of the current two recommendations, section 4 should only say: "Route Server operators that match on route announcements with Extended Communities for 4-octet ASNs SHOULD replace these configurations with equivalent functionality implemented using Large Communities [RFC8092]." As an additional recommendation, RS operators should communicate a clear timeline for their clients to transition from Extended to Large communities. Finally, the document should update RFC7948, section 4.6.1 to: "Prefixes sent to the route server are tagged with specific standard BGP Communities [RFC1997] or Large BGP Communities [RFC8092] attributes, based on predefined values agreed between the operator and all clients." Kind regards, Martin
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
