NH AFT state MPLS label stack doesn't support duplicates

[akalluru1]

In NH AFT container MPLS label stack, is of type leaf-list, present in following YANG paths:

/network-instances/network-instance/afts/next-hops/next-hop/state/pushed-mpls-label-stack
/network-instances/network-instance/afts/next-hops/next-hop/encap-headers/encap-header/mpls/state/mpls-label-stack

https://github.com/openconfig/public/blob/master/release/models/aft/openconfig-aft-common.yang#L565

    leaf-list pushed-mpls-label-stack {
      type oc-mplst:mpls-label;
      ordered-by user;
      description
        "The MPLS label stack imposed when forwarding packets to the
        next-hop
        - the stack is encoded as a leaf list whereby the order of the
          entries is such that the first entry in the list is the
          label at the bottom of the stack to be pushed.

        To this end, a packet which is to forwarded to a device using
        a service label of 42, and a transport label of 8072 will be
        represented with a label stack list of [42, 8072].

        The MPLS label stack list is ordered by the user, such that no
        system re-ordering of leaves is permitted by the system.

        A swap operation is reflected by entries in the
        popped-mpls-label-stack and pushed-mpls-label-stack nodes.

        This node must be supported in addition to the
        encap-headers/encap-header tree.  A future release of OpenConfig
        will deprecate this node in favor of the
        encap-headers/encap-header subtree.";
    }

https://github.com/openconfig/public/blob/master/release/models/aft/openconfig-aft-common.yang#L672

    leaf-list mpls-label-stack {
      type oc-mplst:mpls-label;
      ordered-by user;
      description
        "A stack of MPLS label values.  The first entry in the list is the
        label at the bottom of the stack.  The bottom of the stack is adjacent
        to the MPLS payload.

        For example, a packet with a label stack of two labels, the bottom
        label being 42 and the top label being 8072 will be represented with
        a leaf-list of [42, 8072].  The resulting packet, starting with the
        beginning of the packet will be '[8072][42][Payload]'.

        Note: a swap operation is reflected by entries in the
        popped-mpls-label-stack and the pushed-mpls-label-stack";
    }

It is not possible to store duplicate values in a leaf-list, i.e., for ex: Above leaf-list can't be set to something like 104103, 101403, 104103, 101403, 104103, 101403, 104103, 101403, 104103, 101403, 104103, 101403, as per YANG 1.0 or 1.1 RFC.

[dplore]

Thanks for raising this issue. Using duplicate label values in the stack should be supported and the OC model does not allow it as leaf list values must be unique for Yang1.0 (and in Yang1.1 for config data).

One way to fix this is a model using a list with two leafs, where a "index" (uint8?) is the key and the label value is another leaf would allow this. Any other thoughts?

Something like:

      list mpls-label-stack {
        key "index";
        description
          "List of MPLS labels.";

        leaf index {
          type leafref {
            path "../config/index";
          }
          description
            "Reference to list key";
        }

        container config {
          description
            "Configuration data for list of entries";

          leaf index {
            type uint8;
            description
              "Index for a label in the list.";
          }
          leaf label {
            type oc-mplst:mpls-label;
            description
              "MPLS label value.";
          }
        }
      }

[akalluru1]

@dplore Thanks for the prompt reply! Suggested approach addresses the concern present in the issue but is it a backward compatible change? since following YANG paths have been present for some time & the type of the attribute would also have to change from leaf-list to list:

/network-instances/network-instance/afts/next-hops/next-hop/state/pushed-mpls-label-stack
/network-instances/network-instance/afts/next-hops/next-hop/encap-headers/encap-header/mpls/state/mpls-label-stack

If the conclusion is to go ahead with deprecating existing leaf-list & adding a new list, as mentioned in your reply, will you be able to take care of making that change in the openconfig public github repo?

[dplore]

Yes I can create the pull-request. I'll make it by creating a new list and deprecating the existing leaf-list.

[romeyod]

I am looking into creating a PR for this.

I am confused by the use of "list" here. As per the style guide: YANG requires leaf nodes that are list keys to be direct descendants of the list statement. Since key leaf nodes must also be members of the list data, they will generally reside in a config or state container

Am I missing something obvious about how to model list for label stack values without key?

[romeyod]

I am looking into creating a PR for this.

I am confused by the use of "list" here. As per the style guide: YANG requires leaf nodes that are list keys to be direct descendants of the list statement. Since key leaf nodes must also be members of the list data, they will generally reside in a config or state container

Am I missing something obvious about how to model list for label stack values without key?

@akalluru1 explained this to me offline