Re: [Technical Errata Reported] RFC8294 (7255)

[Jeffrey Haas <[e-mail]>]

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.