-
Notifications
You must be signed in to change notification settings - Fork 656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added next-hop-network-instance under mpls egress config. #1219
base: master
Are you sure you want to change the base?
Added next-hop-network-instance under mpls egress config. #1219
Conversation
/gcbrun |
No major YANG version changes in commit 3edb12b |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update the PR description to include why the change is being added and update the yang model version numbers.
|
||
revision "2024-11-12" { | ||
description | ||
"Added support for mpls route post decap to a specific |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Change Scope
(M) release/models/mpls/openconfig-mpls-static.yang
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/ingress/config/next-hop-network-instance
/network-instances/network-instance/mpls/lsps/static-lsps/static-lsp/transit/config/next-hop-network-instance
/network-instances/network-instance/mpls/lsps/static-lsps/static-lsp/egress/config/next-hop-network-instance
Platform Implementations
Arista:
CLI configuration: mpls static top-label vrf pop payload-type ipv4/6