-
Notifications
You must be signed in to change notification settings - Fork 658
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
Add gre
and mpls
containers under next-hops aft entry state. Add ttl
and tos
under gre, mpls and ip-in-ip aft entry state for telemetry.
#879
Closed
+122
−8
Closed
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
68a9e7e
* (M) aft/openconfig-aft-common.yang
romeyod dd3774f
Addressed review comments
romeyod af0a0c9
Adding auto-size
romeyod b131e42
Add gre and mpls containers under next-hops aft entry state. Add ttl …
romeyod 478746d
remove nhg-name and auto-size
romeyod 1113d66
changed ttl and tos type to uint8
romeyod a69ea22
updated documentation for default value
romeyod File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
If multiple labels are getting added and each label has its own tos/ttl values then what should be the values?
Should these mpls specific leaves tos/ttl kept under "pushed-mpls-label-stack"?
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.
@romeyod any comments on this suggestion?
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.
Missed following up on this, let me get back to you about this. [ my understanding is this TTL/TOS is for the next-hop and need to clarify what it means wrt mpls labels ]
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.
@krishna-juniper Thanks for the suggestion
pushed-mpls-label-stack
is of typeoc-mplst:mpls-label
which is also used in other models. Example:popped-mpls-label-stack
,start-label-value
more occurencesInstead of adding ttl/tos to
oc-mplst:mpls-label
and affecting unrelated models, we can do the following:define a
typedef encap-outer-header-state
with ttl and tosand
in place of mpls container, under
next-hop/state
at the same level aspushed-mpls-label-stack
we defineThis new
leaf-list pushed-mpls-label-header-state
will have ordered entries with tos/ttl corresponding topushed-mpls-label-stack
Let me know what you think about this proposal.
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.
The approach assumes implicit correlation between labels and ttl/tos. (labels coming from pushed-mpls-label-stack, ttl/tos coming from pushed-mpls-label-header-state).
By adding label stack as part of new container(container for encap-outer-header-state + pushed labels) we can avoid this implicit correlation at the cost of redundant information.
what are your thoughts on this approach?
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.
Is this approach supported on any system? Please can we provide multi-vendor examples if we are going to make such a change?
Note that changes around how the MPLS label stack is being pushed have implications in gRIBI and are backwards compatible. I'd like to make sure we're supporting a use case that is actually supported here, since it also has overhead for those that don't care about this.
I also don't really like this typedef being a single leaf -- i think we rather need to think about how this is actually user friendly to parse.
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.
I agree with you @robshakir. We should not be make existing
pushed-mpls-label-stack
backward incompatible in anyway. Hence I proposed a new leaf/leaf listpushed-mpls-label-header-state
that focuses only on the ttl/tos use case.I do think we need to work together and come up with a more user friendly layout. Will appreciate any inputs or existing precedence references.