How to ensure uniqueness across instances of a service

[Johnny Karms Pedersen]

Hi,

Given a YANG service definition as the one described below, how do I ensure that the "accsw port" combination is unique across all instances of the VRF service? The intention is to prohibit one instance of a VRF to overwrite the access-port of another, since only one service can "own" the access port. 

Using 'unique' and 'key' within the access-port list definition, the scope is limited to the list itself I assume, so somehow I guess that it should be defined at the top-level vrf list definition - but how?

-- YANG --

...
list vrf {
      key "name";

      uses ncs:service-data;
      ncs:servicepoint "l3vpn";

      leaf name {
        tailf:info "VRF Name";
        mandatory true;
        type string;
      }
      leaf customer {
        tailf:info "Customer name";
        type leafref {
          path "/ncs:customers/ncs:customer/ncs:id";
        }
      }
      list l3-segment {
        tailf:info "Subnets in VPN";

        key "l3-segment-name";
        unique "l3-segment-name";

        leaf l3-segment-name {
            tailf:info "Unique L3 Segment Name";
            mandatory true;
            type string;
        }
        leaf ipv4-prefix {
          tailf:info "Customer gateway IPv4 address";
          mandatory true;
          type inet:ipv4-prefix;
        }
        list access-port {
          tailf:info "Access ports to assign segment to";

          key "accsw port";
          leaf accsw {
			tailf:info "Access switch";
            type leafref {
              path "/ncs:devices/ncs:devices/ncs:device-name";
            }
          }
          leaf port {
			tailf:info "UNI port";
            type leafref {
              path "/ncs:devices/ncs:device[ncs:name=current()/../accsw]/ncs:config/ios:interface/ios:GigabitEthernet/ios:name";
            }
            must "(not (contains(deref(current())/../ios:description,'uplink')))" {
                  tailf:dependency "/ncs:devices/ncs:device/ncs:config/ios:interface/ios:GigabitEthernet/ios:description";
            }
          }
        }
...

[M02@rt37]

Hello @Johnny Karms Pedersen 

you could enforce this uniqueness at a higher level in the YANG model, specifically within the vrf list. The goal is to prevent any two instances of the VRG service from having the same accsw and port combination.

By using the must  statement at the acces-port level with an XPath that checks all vrf instances, you enforce the uniqueness constraint effectively across the entire model.

---

list vrf {
key "name";

uses ncs:service-data;
ncs:servicepoint "l3vpn";

leaf name {
tailf:info "VRF Name";
mandatory true;
type string;
}
leaf customer {
tailf:info "Customer name";
type leafref {
path "/ncs:customers/ncs:customer/ncs:id";
}
}
list l3-segment {
tailf:info "Subnets in VPN";

key "l3-segment-name";
unique "l3-segment-name";

leaf l3-segment-name {
tailf:info "Unique L3 Segment Name";
mandatory true;
type string;
}
leaf ipv4-prefix {
tailf:info "Customer gateway IPv4 address";
mandatory true;
type inet:ipv4-prefix;
}
list access-port {
tailf:info "Access ports to assign segment to";
key "accsw port";

leaf accsw {
tailf:info "Access switch";
type leafref {
path "/ncs:devices/ncs:devices/ncs:device-name";
}
}
leaf port {
tailf:info "UNI port";
type leafref {
path "/ncs:devices/ncs:device[ncs:name=current()/../accsw]/ncs:config/ios:interface/ios:GigabitEthernet/ios:name";
}
must "(not (contains(deref(current())/../ios:description,'uplink')))" {
tailf:dependency "/ncs:devices/ncs:device/ncs:config/ios:interface/ios:GigabitEthernet/ios:description";
}
}

must "not(../../../../../vrf/l3-segment/access-port[accsw = current()/accsw and port = current()/port and not(current()/../../../../../name = ../../../../../name)])" {
error-message "The combination of accsw and port must be unique across all VRFs";
}
}
}
}

[tohagber]

Hi,

There is also a yang extension that intends to solve such restriction. It is called tailf:unique-selector See YANG extension manual page here: https://developer.cisco.com/docs/nso/guides/ncs-man-pages-volume-5/#tailf_yang_extensions (search unique-selector). 

I don't know which would be most performance using a must or above yang extension, you should test that.

Side note, i see there are multiple leafrefs in above model with absolute paths. If the number vrfs instances is expected to be large it would be good to test how those leafrefs performs on e.g deletion of a device.