Clarify policy-forwarding and routing-policy if no rules are present

[dplore]

Change Scope

• Clarify policy-forwarding such that if no rules are present, all packets will be matched

[dplore]

Related to discussion on #1150

[OpenConfigBot]

No major YANG version changes in commit 441428e

[s19nal]

LGTM - updated clarification reads well.

[dplore]

We discussed this a second time in the OC Operators meeting on Nov 26, 2024.
It is observed that policy-forwarding and routing-policy should have the same semantics. At the moment, both are ambiguous about the behavior when there are no rules (policy-forwarding) or no conditions (routing-policy) defined.

For routing-policy, vendor native implementations widely support policies which have no 'conditions' matching all packets.

Example native routing policy configuration: https://gist.github.com/dplore/cff9a4c782f68734adaafff8952fc3cb (Kudos to @oscargdd for sharing this investigation)

So I am updating this description to assert that no rules means match all packets.

[xuqma]

LGTM for BGP routing policies. Thanks Darren.

[dplore]

After a bit more discussion, there was a request to also clarify what happens if there is a routing-policy statement with no condition AND no action, as well as a policy-definition without any statements. These should be treated as errors (grpc error: INVALID_ARGUMENT, netconfig error missing-element).

Note that policy-result is an action. So one may write a valid OC routing-policy which has for example, one statement which as no condition (matching all routes) and a policy-result of ACCEPT_ROUTE.

I will update this pull request accordingly.

[robshakir]

Why is this the right thing to do vs. having an explicit match-all type criteria?

The downside of this API design is that the absence of something means something implicitly -- it seems a better API design to have the presence of something indicate something, which would mean that we should rather have an explicit "match everything" (can be done with matching all src/dst IP addrs)?

[dplore]

There is no right or wrong here. This proposal is made based on precedent as referenced in #1223 (comment) earlier in this PR. The industry precedent is no-condition = matches any and all. This was also discussed in the OpenConfig operator meeting on Nov 26, 2024 with some thoughtful conversation.

The precedent is pretty strong where 5 out of 5 implement that no "condition" means match all. (Not included in the gist of 4 examples is arista EOS, which also defines a route map with no match statements as match all)

I do like the idea of being explicit in general. A number of changes in OC in the last few years have been due to ambiguity. But what is better? Do something different in OC or go with the precedent? In this case, I think the precedent is so strong that it's better to go with no conditions means match all. This change makes this decision explicit via description, but not in the data model/API.

[akalluru1]

After a bit more discussion, there was a request to also clarify what happens if there is a routing-policy statement with no condition AND no action, as well as a policy-definition without any statements. These should be treated as errors (grpc error: INVALID_ARGUMENT, netconfig error missing-element).

Note that policy-result is an action. So one may write a valid OC routing-policy which has for example, one statement which as no condition (matching all routes) and a policy-result of ACCEPT_ROUTE.

I will update this pull request accordingly.

Small clarification, About following:

what happens if there is a routing-policy statement with no condition AND no action, as well as a policy-definition without any statements. These should be treated as errors (grpc error: `INVALID_ARGUMENT`, netconfig error `missing-element`)

• Is this capturing 2 different scenarios, i.e., scenario 1: a routing-policy statement with no condition AND no action & scenario 2: a policy-definition without any statements?
• In both the scenarios error (grpc error: INVALID_ARGUMENT, netconfig error missing-element) should be returned.

[dplore]

After a bit more discussion, there was a request to also clarify what happens if there is a routing-policy statement with no condition AND no action, as well as a policy-definition without any statements. These should be treated as errors (grpc error: INVALID_ARGUMENT, netconfig error missing-element).
Note that policy-result is an action. So one may write a valid OC routing-policy which has for example, one statement which as no condition (matching all routes) and a policy-result of ACCEPT_ROUTE.
I will update this pull request accordingly.

Small clarification, About following:

what happens if there is a routing-policy statement with no condition AND no action, as well as a policy-definition without any statements. These should be treated as errors (grpc error: `INVALID_ARGUMENT`, netconfig error `missing-element`)

• Is this capturing 2 different scenarios, i.e., scenario 1: a routing-policy statement with no condition AND no action & scenario 2: a policy-definition without any statements?
• In both the scenarios error (grpc error: INVALID_ARGUMENT, netconfig error missing-element) should be returned.

Two scenarios as you described.