Actually, I'll reply to this one for the context. Acee's response was a hidden one-liner. (Thanks, Outlook...)
On Sat, Nov 19, 2022 at 07:00:26PM +0100, Robert Raszuk wrote: > Hey Acee, > > Well actually YANG model for extended communities seems to be defined in > BGP model. > > REF: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model > > So perhaps it is not best idea to keep the same thing defined differently > in multiple RFCs ? The BGP YANG document spent a lot of work around extended communities and what a complete pain it was to deal with them in the model. While we discussed our changes tersely in email and also during updates in IDR, the issues are roughly: 1. Extended communities receive regular work and new code point assignments. 2. In YANG, we're specifying them as typedefs. You cannot augment a typedef in YANG. You must replace it. We've chosen to make our extended community type in the BGP YANG module IANA maintained, which at least makes this process less difficult. (How much less difficult is to be judged by the future.) 3. What do you do about implementations that need to operationally display and configure extended communities that aren't well-known types? The choice we made in the BGP YANG module was to support a "raw" mode. However, this means that policy may need to be able to deal with processing both a raw and a well-known ("cooked") format. To provide some level of consistency, the extended community operational state was split between a raw-only format and a "human readable" one in different leafs. My errata spawned because I had looked at the l3vpn model.[1] Its import types were using the RFC 8294 definitions, which were going to be different than the ones present in the BGP YANG module. Why? Because while BGP needs to be able to generically able to deal with Extended Communities, the VPN modules have different requirements: They only need route-targets. However, it was apparent that even though the use cases overlap that the maintenance issues we discovered for the BGP YANG module were going to be the same. What should be done? Unclear. While it'd be "nice" if the well known definitions for the use cases served by the route-targets for RFC 8294 were identical for the BGP YANG module, they can't completely identical typedefs. We're likely to need to do something to update RFC 8294. A full analysis of the users of those types would need to be done. Only after that can we decide what actions to take. Personally, I'm happy to be mostly done with the heavy lift on the work for the BGP YANG module, and know that this discussion will form part of the WGLC comments on that document. I'm not sure I'd want to drive RFC 8294-bis. That said, I'm happy to supply feeback on it. I'm happy to give a presentation on these topics at next rtgwg. -- Jeff [1] My total "author" input was spending time with the other authors at a couch during a prior IETF. This module was one of the various that were going to be dependent on the BGP YANG work. It's gotten no attention from me in years. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
