Re: [netmod] YANG model for BGP extended communities

[Jeffrey Haas <[e-mail]>]

> On Apr 13, 2023, at 5:16 PM, Jason Sterne (Nokia) <[e-mail]> wrote:
> 
> Hi Jeff,
>  
> I’m branching off a separate thread for the extended communities discussion. Is this a good one from the draft for discussion?

It is, thanks.  Since this is an item we want significant scrutiny on in the model, it's good to get the wider attention than more targeted YANG doctor review.

Note: OpenConfig has a flavor of this headache as well.  We chose to go a slightly different direction in addressing it.

>  
>   /* BGP Extended Community Types. */
>  
>   typedef bgp-ext-community-type {
>     type union {
>       type string {
>         pattern 'route\-target:(6[0-5][0-5][0-3][0-5]|'
>               + '[1-5][0-9]{4}|[1-9][0-9]{1,4}|[0-9]):'
>               + '(4[0-2][0-9][0-4][0-9][0-6][0-7][0-2][0-9][0-6]|'
>               + '[1-3][0-9]{9}|[1-9]([0-9]{1,7})?[0-9]|[0-9])';
>         /*
>          * description
>          *   "Type 0x00, Sub-Type 0x02: Route-Target
>          *    route-target:(ASN):(local-admin)
>          *    2 octets global administrator and 4 octets local
>          *    administrator.";
>          * reference
>          *   "RFC 4360: BGP Extended Communities Attribute,
>          *    Section 4.";
>          */
>       }
>  
> …snip…
>  
>       type string {
>         pattern 'route\-origin:'
>               + '(4[0-2][0-9][0-4][0-9][0-6][0-7][0-2][0-9][0-6]|'
>               + '[1-3][0-9]{9}|[1-9]([0-9]{1,7})?[0-9]|[0-9])'
>               + '(6[0-5][0-5][0-3][0-5]|[1-5][0-9]{4}|'
>               + '[1-9][0-9]{1,4}|[0-9])';
>         /*
>          * description
>          *   "Type 0x02, Sub-Type 0x03: Route-Origin
>          *    route-origin:(ASN):(local-admin)
>          *    4 octets global administrator and 2 octets local
>          *    administrator.";
>          * reference
>          *   "RFC 5668: 4-Octet AS Specific BGP Extended Community,
>          *    Section 4.";
>          */
>       }
>  
>       type string {
>         // raw with 8 octets
>         pattern 'raw:'
>              + '([0-9A-Fa-f][0-9A-Fa-f]:){7}'
>              + '[0-9A-Fa-f][0-9A-Fa-f]';
>       }
>     }
>     description
>       "Type definition for extended community attributes.
>        It includes a way to specify a 'raw' string that
>        is followed by 8 bytes of octet string to support
>        new and experimental type definitions.";
>     reference
>       "RFC 4360: BGP Extended Communities Attribute.";
>   }
>  
> Things can get tricky with unions in YANG, especially if things overlap. Are there values that one could configure as “raw:…” that overlap with the other union members?

Absolutely for several reasons.  This also happens in current implementations.  Here are an example:

You wish to set an extended community, however there is no type currently assigned to it.  An example that Junos had as a transitional headache was we didn't provide named community support for RFC 8097 validation communities for RPKI.  Code that's in the process of going through our shipping process will tag a "valid" community as "origin-validation:valid".  However, in the absence of this code support, it was possible to tag it in juniper's raw format as "0x4300:0:0".

If you're a legacy user that will get the new code, your configuration will still work for configuration on the raw format.  Similarly, it'll match in policy because the string format will parse internally to the same match criteria when it's an explicit value.

Where things get messy is what to do with wildcard matching.  In our implementation's case, you might want to match on the fact that it is a validation extended community.  The syntax would be "origin-validation:*"  

Accommodating such matches in YANG is going to be challenging.  The policy module integration is going to require a lot of attention.




> The raw value and the “other value” (that overlaps) would be considered completely different & separate tokens in YANG.  In other words, it isn’t really valid to set a “raw” value in a NETCONF server, but then fetch the configuration and see a different value (i.e. auto converted by the server to the known non-raw equivalent).

Exactly.  And in the YANG case, "raw" is added as a leaf-list so that implementations requiring fully stable match criteria can match against the raw formats when necessary.  Basically, if you know you can't match a known type, you match the raw and it'll continue to work.  But if you want to match the known, you can also do that - and that's the common expected case.

This accommodation is modeled as the following in the policy module:

      container match-ext-community-set {
        description
          "Match a referenced extended community-set according to the
           logic defined in the match-set-options leaf.";
        leaf ext-community-set {
          type leafref {
            path "/rt-pol:routing-policy/rt-pol:defined-sets/"
               + "bgp-defined-sets/ext-community-sets/"
               + "ext-community-set/name";
          }
          description
            "References a defined extended community set.";
        }
        leaf ext-community-match-kind {
          type enumeration {
            enum ext-community {
              description
                "Perform the match against the ext-community RIB
                 attribute.";
            }
            enum ext-community-raw {
              description
                "Perform the match against the ext-community-raw RIB
                 attribute.";
            }
          }
          default ext-community;
          description
            "Extended communities may be matched by the ext-community
             RIB attribute, or the ext-community-raw RIB attribute.
             This leaf selects which leaf to perform the match
             operation against.";
        }
        uses rt-pol:match-set-options-group;
      }

Note the "match-kind" lets you choose how you match.

>  
> A more intuitive example for me is thinking about TCP ports. This is an example of a potentially problematic union:
>                Union {
>                    Type uint16;
>                    Type enumeration {
>                        Enum ssh {
>                            Value 22;  <- could actually be any other number (not significant)
>                        }
>                } 
> YANG sees the values “ssh” and “22” as completely separate independent values/tokens.
>  
> If the typedef was used for state (config false) then it gets tricky to decide what to return for the value of a leaf of this type (when the port is 22). A human user sees 22 and ssh as the same thing, but YANG doesn’t.

Understood.  In something more strongly typed as a format, like CBOR, then such distinctions might be easier.  However, it's not the general YANG case.

I think the BGP model is likely okay in this respect since the Extended Community modeling is expected to be always a string of some sort.  However, careful maintenance of the prefixes in the pattern will need to be done with no ambiguity.  Sadly, this the fundamental issue that the RFC 8294 extended community types like "route-target" has.  Since it lacks a distinguishing token for its variations, you can't mix RFC 8294 types with general BGP extended community types.

At some point, I'll have to raise that as an issue with RTGWG/IDR/BESS but it'll likely have to wait closer to next IETF.  It's going to make working on the other VPN protocols for BGP hilarious.

-- Jeff