Augmented attributes interface-ref and metric fields to mpls-static lsp

[Shashank-arista]

• (M) release/models/mpls/openconfig-mpls-static.yang
• (M) release/models/mpls/openconfig-mpls-types.yang
• (M) release/models/mpls/openconfig-mpls.yang
• (M) release/models/mpls/openconfig-mpls-igp.yang
• (M) release/models/mpls/openconfig-mpls-te.yang

Change Scope

• Augmented with below attributes interface-ref, and metric in the path /network-instances/network-instance/mpls/lsps/static-lsps/static-lsp

  +--rw network-instances
     +--rw network-instance [name]
        +--rw mpls
           +--rw lsps
              +--rw static-lsps
                 +--rw static-lsp [name]
                    +--rw ingress
                    |  +--rw config
                    |  |  +--rw interface?        -> /oc-if:interfaces/interface/name
                    |  |  +--rw subinterface?     -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index
                    |  |  +--rw metric?           uint8
                    |  +--ro state
                    |     +--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 transit
                    |  +--rw config
                    |  |  +--rw interface?        -> /oc-if:interfaces/interface/name
                    |  |  +--rw subinterface?     -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index
                    |  |  +--rw metric?           uint8
                    |  +--ro state
                    |     +--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 egress
                       +--rw config
                       |  +--rw interface?        -> /oc-if:interfaces/interface/name
                       |  +--rw subinterface?     -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index
                       |  +--rw metric?           uint8
                       +--ro state
                          +--ro interface?        -> /oc-if:interfaces/interface/name
                          +--ro subinterface?     -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index
                          +--ro metric?           uint8 

Platform Implementations

• Arista: https://www.arista.com/en/um-eos/eos-mpls-commands#xx1141474
  CLI configuration: mpls static top-label top_tag[ bgp peer [peer IP]] [DEST_INTF] NEXTHOP_ADDR ACTION [PRIORITY]

[OpenConfigBot]

No major YANG version changes in commit e6ab4f0

[dplore]

Please add some additional description where pointed out. I will help with an additional implementation reference.

[dplore]

JunOS static-label-switched-path supports options for setting the next hop as an interface, and setting metric. There is no support for payload-type.

Cisco XROS static lsp configuration supports interface as next hop. It does not appear to support metric or payload-type.

So based on three references (EOS as submitted and XROS and JunOS), it seems we have at least two which support metric and nexthop, but only Arista has a concept of 'payload-type'.

Why is payload-type needed?

[dplore]

@Shashank-arista ping for any comments, especially regarding payload type.

[dplore]

/gcbrun

[Shashank-arista]

@Shashank-arista ping for any comments, especially regarding payload type.

Hi @dplore, Sorry for the delay in getting back on this. I tried to investigate more on payload-type requirement. Arista CLI needs a payload-type mandatorily, although today most of hardware platforms depend on auto-decide for inferring it. But still, there is a use case where payload-type would be necessary/used on a certain platform where we would need to skip applying egress ACLs for certain labels which relies on payload-type for the functionality.

[no] mpls static top-label [ intf ] { { swap-label } | { pop [ payload-type { ipv4 | ipv6 } [ access-list bypass ] ] } } [ metric ]

So, it seems payload-type is something not a mandatory attribute but would still be required in certain specific scenario.

[wenovus]

/gcbrun

[dplore]

@Shashank-arista ping for any comments, especially regarding payload type.

Hi @dplore, Sorry for the delay in getting back on this. I tried to investigate more on payload-type requirement. Arista CLI needs a payload-type mandatorily, although today most of hardware platforms depend on auto-decide for inferring it. But still, there is a use case where payload-type would be necessary/used on a certain platform where we would need to skip applying egress ACLs for certain labels which relies on payload-type for the functionality.

[no] mpls static top-label [ intf ] { { swap-label } | { pop [ payload-type { ipv4 | ipv6 } [ access-list bypass ] ] } } [ metric ]

So, it seems payload-type is something not a mandatory attribute but would still be required in certain specific scenario.

Ok. In this scenario since we haven't identified at least 2 vendors that support payload type, nor the intent to add a payload type, nor specific operational use cases I suggest the payload type be removed from the OC model. It could added via an Arista specific yang augment.

[Shashank-arista]

@Shashank-arista ping for any comments, especially regarding payload type.

Hi @dplore, Sorry for the delay in getting back on this. I tried to investigate more on payload-type requirement. Arista CLI needs a payload-type mandatorily, although today most of hardware platforms depend on auto-decide for inferring it. But still, there is a use case where payload-type would be necessary/used on a certain platform where we would need to skip applying egress ACLs for certain labels which relies on payload-type for the functionality.
[no] mpls static top-label [ intf ] { { swap-label } | { pop [ payload-type { ipv4 | ipv6 } [ access-list bypass ] ] } } [ metric ]
So, it seems payload-type is something not a mandatory attribute but would still be required in certain specific scenario.

Ok. In this scenario since we haven't identified at least 2 vendors that support payload type, nor the intent to add a payload type, nor specific operational use cases I suggest the payload type be removed from the OC model. It could added via an Arista specific yang augment.

Sure, @dplore. I have updated the pull request by removing the payload type related changes from OC model. Please review, thanks.

[dplore]

/gcbrun

[dplore]

This LGTM. Last call for comments! I plan to merge this on April 17th, 2024.