-
Notifications
You must be signed in to change notification settings - Fork 659
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
New set-as-path BGP action, and support last AS for for setting AS path. #1148
base: master
Are you sure you want to change the base?
Conversation
/gcbrun |
No major YANG version changes in commit fd28c04 |
Removed the extra comma and rebased against master. |
/gcbrun |
68a38ff
to
bffc29b
Compare
/gcbrun |
set-as-path action"; | ||
|
||
leaf-list as-paths { | ||
type union { |
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 think this need to be ordered-by-user .
Is there precedence for this in existing implementations or is this intended to be a new feature request?
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.
Good call. Updated type with ordered-by user
.
IIUC, only Arista support replacing the entire AS path with [set as-path match all replacement] (https://www.arista.com/en/um-eos/eos-acls-and-route-maps#xx1313923). This is the recommended Arista implementation for the existing as-path-expand
in Juniper, which is also vendor specific unefortunately. I am not sure which one fits the model better (neither is ideal due to single-vendor support). set-as-path
might be slightly more generic based on our past discussions. Kindly share your thoughts please.
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, we can declare OC which achieves an operational use case that multiple vendors only deliver by different syntax/schema and semantics.
In this case I think the guiding principle is intact, in that the use case can be delivered by multiple vendors. It is ok for OC to adopt a syntax that looks more like one implementation than the others, when they are all different. The alternative is for OC to contrive some schema that that no existing implementation has, just to be different. I'd rather go with what operators have some rough consensus is "easy enough" to use.
b8f43f3
to
61d8291
Compare
fb94dc8
to
b9068be
Compare
/gcbrun |
2 similar comments
/gcbrun |
/gcbrun |
LGTM, moving to last call for Jan 16, 2025 |
30ffc7e
to
bdeb512
Compare
Thanks Darren! I have fixed the revisions based on the previous check result. |
Change Scope
/routing-policy/policy-definitions/policy-definition/statements/statement/actions/bgp-actions/set-as-path
(a list of ASNs or last-as)oc-bgp-pol
instead ofoc-bgp-types
.New paths after the model update:
Platform Implementations