Added next-hop-network-instance under mpls egress config. #1219
Conversation
|
/gcbrun |
|
No major YANG version changes in commit 3edb12b |
|
|
||
| revision "2024-11-12" { | ||
| description | ||
| "Added support for mpls route post decap to a specific |
There was a problem hiding this comment.
Can you please clarify this? What is post decap in this case?
In terms of mpls static LSPs, you have three different scenarios:
- ingress
- transit
- egress
Does decap implies the egress (where the top label is removed by a PE node, and the LSP is terminated)?
There was a problem hiding this comment.
We should remove post decap.
This is for egress LSPs.
The intent is to do a lookup for the nexthop (to determine egress interface and rewrite) in a vrf that is different from the ingress interface's VRF.
For example: in some vpc use case ingress interface is in the default VRF as it's facing the providers network and the egress interface is in a customer specific VRF.
There was a problem hiding this comment.
Ok. In that case, in addition to updating the description, I think this leaf should be moved from static-lsp-common-config to static-lsp-egress-config
There was a problem hiding this comment.
May I kindly request
Ok. In that case, in addition to updating the description, I think this leaf should be moved from
static-lsp-common-configtostatic-lsp-egress-config
I had updated description and can move leaf to egress config, may I kindly request if Nokia platform can support this? I could not find any reference from Nokia public documentation.
As a reference ARISTA support's this using following CLI command:
mpls static top-label vrf pop payload-type ipv4/6
Removed post decap.
| @@ -217,6 +225,14 @@ submodule openconfig-mpls-static { | |||
| "Next hop IP address for the LSP"; | |||
| } | |||
|
|
|||
| leaf next-hop-network-instance { | |||
There was a problem hiding this comment.
As some of the attributes, for ex: next-hop, push-label & etc..., in this grouping are deprecated wondering if this should be part of lsp-next-hops container.
|
Hello Vishnu as discussed on the operators board. Please include vendor config and usecase. Limit augment to only egress LSP. thx |
Rajeev, description is updated with only egress use case and one vendor config. We are looking for a second vendor that can implement similar functionality. Once we find second vendor I will work on the augment part. |
Change Scope
(M) release/models/mpls/openconfig-mpls-static.yang
Packet flow:
An IP in MPLS packet enters the device from the backbone/provider network
The MPLS packet enters from the “DEFAULT” network-instance
The inner IP packet is a customer packet
Goal is to decap/pop a provider MPLS label and lookup on the inner IP packet in the customer’s VRF
Intent is to do a lookup for the nexthop (to determine egress interface and rewrite) in a vrf that is different from the ingress interface's VRF.
For example: in some vpc use case ingress interface is in the default VRF as it's facing the providers network and the egress interface is in a customer specific VRF.
Currently model does not support mpls route to a specific next hop network instance, we are adding support for network instance in which to resolve the next hop.
/network-instances/network-instance/mpls/lsps/static-lsps/static-lsp/egress/config/next-hop-network-instancePlatform Implementations
Arista:
CLI configuration: mpls static top-label vrf pop payload-type ipv4/6
Juniper:
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/vrf-table-label-edit-routing-instances-vp.html