Add MPLS static LSP nh-network-instance

[dplore]

Change Scope

• Add a reference for next-hop network-instance for MPLS static LSP's.
• This change is backwards compatible.

Platform Implementations

• Arista EOS static LSP supports configuration of a destination network instance
• Cisco XROS supports this feature but with a different configuration by mapping a static MPLS label to an IP prefix for a specific VRF

Reference operational use case

See featureprofiles#4538

Tree view

pyang -f tree -p release/models/*/* > ~/new-tree.txt 
diff -bU 100 ~/old-tree.txt ~/new-tree.txt

         |           +--rw egress
         |              +--rw config
         |              |  +--rw incoming-label?              oc-mplst:mpls-label
         |              |  x--rw next-hop?                    inet:ip-address
         |              |  x--rw push-label?                  oc-mplst:mpls-label
         |              |  +--rw interface?                   -> /oc-if:interfaces/interface/name
         |              |  +--rw subinterface?                -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/
index
         |              |  +--rw metric?                      uint8
+        |              |  +--rw oc-mpls-ni:next-hop-group
+        |              |     +--rw oc-mpls-ni:config
+        |              |     |  +--rw oc-mpls-ni:name?   -> ../../../../../../../../../oc-ni:static/next-hop-groups/next-hop-group/config/name
+        |              |     +--ro oc-mpls-ni:state
+        |              |        +--ro oc-mpls-ni:name?   -> ../../../../../../../../../oc-ni:static/next-hop-groups/next-hop-group/config/name
         |              +--ro state
         |              |  +--ro incoming-label?   oc-mplst:mpls-label
         |              |  x--ro next-hop?         inet:ip-address
         |              |  x--ro push-label?       oc-mplst:mpls-label
         |              |  +--ro interface?        -> /oc-if:interfaces/interface/name
         |              |  +--ro subinterface?     -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index
         |              |  +--ro metric?           uint8
         |              +--rw lsp-next-hops
         |                 +--rw lsp-next-hop* [index]
         |                    +--rw index     -> ../config/index
         |                    +--rw config
         |                    |  +--rw index?                            uint32
         |                    |  +--rw ip-address?                       inet:ip-address
         |                    |  +--rw push-label?                       oc-mplst:mpls-label
         |                    |  +--rw interface?                        -> /oc-if:interfaces/interface/name
         |                    |  +--rw subinterface?                     -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/su
binterface/index
+        |                    |  +--rw oc-mpls-ni:nh-network-instance?   -> /oc-ni:network-instances/network-instance/config/name
         |                    +--ro state
         |                       +--ro index?                            uint32
         |                       +--ro ip-address?                       inet:ip-address
         |                       +--ro push-label?                       oc-mplst:mpls-label
         |                       +--ro interface?                        -> /oc-if:interfaces/interface/name
         |                       +--ro subinterface?                     -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/su
binterface/index
+        |                       +--ro oc-mpls-ni:nh-network-instance?   -> /oc-ni:network-instances/network-instance/config/name

[OpenConfigBot]

No major YANG version changes in commit a2e2406

[earies]

We have a typedef of network-instance-ref already for this however it sits directly in openconfig-network-instance which I suspect would cause potential recursive import issues in some cases.

Since this is augmenting into that model and already imported, this typedef could be used here instead

[dplore]

Yes, our pattern for preventing recursive imports when referencing network-instance within a network-instance ancestor is to create a -network-instance.yang and augment. So yes, we can't import openconfig-network-instance where that typedef resides.

Are you recommending creating another typedef network-instance-ref within this model file versus what is here?

[earies]

In this case, we could just directly use the typedef that is in openconfig-network-instance but going fwd, I think the better solution to not run into recursive import issues is to put all such definitions in domain "types" modules - any domain can then import another domains type module that doesn't contain direct data trees.

So we wouldn't create another typedef here but we could in openconfig-network-instance-types

[earies]

This relative path reference seems to negate reusable groupings unless it can be ensured its reuse is always at the same depth of a tree. Maybe a absolute path reference rather and if targeting is necessary then maybe XPath functions like current() are in order? (much like in the reusable interface-ref-common)

[dplore]

Are you proposing a path like this?

      type leafref {
        path "/oc-ni:network-instances/oc-ni:network-instance[name=current()]" +
        "/oc-ni:static/oc-ni:next-hop-groups/oc-ni:next-hop-group/oc-ni:config/oc-ni:name
      }

I'm not sure I see a reuse case on the horizon, but this is easier to read and works. Let me know if this is what you were looking for.

[earies]

yep that is precisely what I was thinking and agree, it's always hard to determine how much reuse there will be in reality up front. Some design patterns however will negate reuse even though the intention might have been there to collocate in groupings