[netmod] YANG model for BGP extended communities

["Jason Sterne (Nokia)" <[e-mail]>]

Hi Jeff,

I’m branching off a separate thread for the extended communities discussion. Is this a good one from the draft for discussion?

  /* 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? 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).

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.

Maybe this issue doesn’t turn out to be a problem for this particular extended community typedef but I’m not sure (implementors could make a mistake with it).

Jason

From: Jeffrey Haas <[e-mail]>
Sent: Thursday, April 13, 2023 4:44 PM
To: Jason Sterne (Nokia) <[e-mail]>
Cc: [e-mail]
Subject: Re: Unknown bits - backwards compatibility



I wish to point you and others concerned on these points to the BGP YANG modeling for Extended Communities, which will have these problems in a different flavor: Known communities will render via the typedefs, unknown will render using the prefix 'raw'.  (See typedef bgp-ext-community-type.)  This headache is already a consideration in every BGP implementation that deals with extended communities in changing meaning.
[>>JTS:] Can you point me to a repository or RFC where I can see this? I’m not familiar with where this YANG work is being done.

Sorry for not including the URL.  This document went to WGLC for IDR a few days ago.  We'll be asking (yet yet yet again) for YANG doctor review.
https://www.ietf.org/archive/id/draft-ietf-idr-bgp-model-16.html

You'll find the typedef issue for extended communities in there, and also the field for unknown bits in the operational state that is the genesis for this conversation.


-- Jeff