[netmod] draft-ietf-tictoc-1588v2-yang-05: port-number

[Rodney Cummings <[e-mail]>]

Hi folks,

One of the last topics that we need to resolve for WG Last Call of draft-ietf-tictoc-1588v2-yang-05 is the representation of port-number, which serves as the key to the list of 1588 port data sets (i.e. port-list). I've had some offline discussion with IEEE 1588 WG members, and I'm copying NETMOD members for YANG expertise.

I think we can narrow the possible options to two, so I'm starting a new thread to focus on those.

IEEE Std 1588-2008 is the time sync standard that specifies the information model on which draft-ietf-tictoc-1588v2-yang-05 is based. In IEEE Std 1588-2008, subclause 5.3.5 specifies the following data type to identify each logical port in the 1588 product:
   struct PortIdentity {
      ClockIdentity clockIdentity;
      Uinteger16 portNumber;
   };
IEEE Std 1588-2008 uses this data type as the "portIdentity" of the port in its on-the-wire protocol, state machines, and so on. In other words, in the 1588 standard itself, portIdentity is a "real thing" with real implementation.
 
IEEE Std 1588-2008 also specifies a list of logical ports in each "clock", and portIdentity.portNumber is used as the key to that list of ports.

In the YANG of draft-ietf-tictoc-1588v2-yang-05, we use YANG-style names (e.g. port-list, port-number), but otherwise we've tried to keep consistent to the IEEE Std 1588-2008 information model.

We have a challenge with port-number. If YANG represents port-identity as a container within port-list, YANG does not allow a key to be a leaf within a container, so we cannot use port-identity/port-number as the key to port-list.

It seems that we have two options:

Option 1: Use a leafref
---

YANG summary:

        list port-ds-list {
          key "port-number";
          leaf port-number {
            type uint16;
          }
          container port-identity {
             leaf clock-identity {
                type clock-identity-type;
                config false;
             }
             leaf port-number {
                type leafref{
                   path "../../port-number";
                }
                config false;
             }
          }
        }

This has disadvantages from the YANG perspective, in that port-number is duplicated. The "config false" is intended to mitigate YANG implementation challenges, such that only one value of port-number is provided for configuration.

Option 2: Use a grouping
---

YANG summary:

     grouping port-identity-grouping {
       leaf clock-identity {
         type clock-identity-type;
       }
       leaf port-number {
         type uint16;
       }
     }
     list port-ds-list {
       key "port-number";
       uses port-identity-grouping;
     }

This has disadvantages from the 1588 perspective, in that it is not possible for a 1588-aware management client to "get" portIdentity. We are removing a 1588 "real thing" from the data model in order to accommodate a syntax limitation of YANG. 

Question for NETMOD experts
---

My personal preference is Option 1 (leafref). Nevertheless, if the "config false" does not provide sufficient mitigation for today's YANG implementations, we can go with Option 2. 

Feedback is very much appreciated.

Thanks folks,
Rodney Cummings
Co-author draft-ietf-tictoc-1588v2-yang-05