Skip to content

Refactor must restriction behavior for BGP MED policies #1312

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.

Sign up for GitHub

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Refactor must restriction behavior for BGP MED policies #1312

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d8558a9
Refactor must restriction behavior for BGP MED policies
earies May 23, 2025
2b95b0f
Merge branch 'master' into bgp-set-med-adjustments
robshakir Jul 1, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
Refactor must restriction behavior for BGP MED policies 
  * (M) release/models/bgp/openconfig-bgp-policy.yang
    - Relocate must restrictions at a container level and specify
      behavior for the MED type 'IGP' and associated actions
    - Increment version to 8.2.0
  • Loading branch information
@earies
earies committed May 23, 2025
commit d8558a9f53456c3d96303cf59176e6b07ee6be4a
43 changes: 30 additions & 13 deletions release/models/bgp/openconfig-bgp-policy.yang
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,13 @@ module openconfig-bgp-policy {
It augments the base routing-policy module with BGP-specific
options for conditions and actions.";

oc-ext:openconfig-version "8.1.0";
oc-ext:openconfig-version "8.2.0";

revision "2025-05-23" {
description
"Refactor must restriction behavior for BGP MED values/actions.";
reference "8.2.0";
}

revision "2024-11-13" {
description
Expand Down Expand Up @@ -1385,24 +1391,19 @@ module openconfig-bgp-policy {

leaf set-med {
type bgp-set-med-type;
must "../set-med-action" {
error-message
"set-med cannot be specified without a valid set-med-action";
}
description
"Set the MED metric attribute in the route update. When set, a
valid `set-med-action` must be specified.";
"Set the MED metric attribute in the route update. When set to
an integer metric, all `set-med-action` options apply. When set
to 'IGP', the `set-med-action` must be set to 'SET'.";
}

leaf set-med-action {
type bgp-set-med-action;
must "../set-med" {
error-message
"set-med-action cannot be specified without a set-med value";
}
description
"When set-med is specified, this leaf is mandatory to set the
appropriate action on the MED metric value.";
"This leaf is mandatory when `set-med` is specified. When
`set-med` is specified as a integer metric, all actions are
valid options. When set to 'IGP', this action must be set to
'SET'.";
}
}

Expand All @@ -1424,6 +1425,14 @@ module openconfig-bgp-policy {
"Configuration data for BGP-specific actions";

uses bgp-actions-config;

must "(set-med != 'IGP' and set-med-action) or" +
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have precedent for this kind of must statement, or is this something that can just be done in descriptions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considered it... encoding desired behaviors in descriptions I've found often gets tricky and leads to various interpretations although that could possibly be cleaned up w/ more precise wording....

Since implementations will codify behaviors around a specification such as YANG, it's well understood to leverage what is in place for consistent behavior that can be ingested programmatically .... What led to this PR was infact just that.... implementation clarifications which triggered a need to express the behavior "better"

Anytime we step outside of YANG language constraints will often result in custom code, increase in complexity, reference to why, etc...

On one end, being loose in the modeling allows flexibility but also is likely to create divergence among implementation interop and interpretation

"(set-med = 'IGP' and set-med-action = 'SET')" {
error-message
"set-med-action must be set to 'SET' when set-med = 'IGP', " +
"otherwise any action must be specified if set-med is an " +
"integer value.";
}
}

container state {
Expand All @@ -1435,6 +1444,14 @@ module openconfig-bgp-policy {

uses bgp-actions-config;
uses bgp-actions-state;

must "(set-med != 'IGP' and set-med-action) or" +
"(set-med = 'IGP' and set-med-action = 'SET')" {
error-message
"set-med-action must be set to 'SET' when set-med = 'IGP', " +
"otherwise any action must be specified if set-med is an " +
"integer value.";
}
}
uses as-path-prepend-top;
uses set-community-action-top;
Expand Down
Loading