Update policy forwarding to support global decapsulation policy

[danameme]

Change Scope

• Add new leaf to policy forwarding to indicate a policy application is global.

Implementations

• Arista
• Cisco
• Juniper

Tree View

@@ -3312,40 +3312,44 @@
         +--rw policy-forwarding
+        |  +--rw config
+        |  |  +--rw global-decap-policy?   string
+        |  +--ro state
+        |  |  +--ro global-decap-policy?   string
         |  +--rw policies
         |  |  +--rw policy* [policy-id]
         |  |     +--rw policy-id    -> ../config/policy-id
         |  |     +--rw config
         |  |     |  +--rw policy-id?   string
         |  |     |  +--rw type?        enumeration

Flatten View

@@ -4784,40 +4784,42 @@
 /openconfig-network-instance:network-instances/network-instance/openconfig-programming-errors:programming-errors/ip-routes/state/total-errors
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding
+/openconfig-network-instance:network-instances/network-instance/policy-forwarding/config
+/openconfig-network-instance:network-instances/network-instance/policy-forwarding/config/global-decap-policy
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/interfaces
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/interfaces/interface
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/path-selection-groups/path-selection-group
@@ -4995,40 +4997,42 @@
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/rules/rule/transport/config/builtin-detail
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/state/type
+/openconfig-network-instance:network-instances/network-instance/policy-forwarding/state
+/openconfig-network-instance:network-instances/network-instance/policy-forwarding/state/global-decap-policy
 /openconfig-network-instance:network-instances/network-instance/protocols
 /openconfig-network-instance:network-instances/network-instance/protocols/protocol

[dplore]

I'd like to add more details on the motivation for this addition:

Current OpenConfig policy-forwarding decapsulation configuration paths for UDP/GUE do not map well to implementations. OC policies can only be attached to interfaces, but multiple vendor hardware implementations only support:

• A single UDP destination port to protocol decapsulation action per INTEGRATED_CIRCUIT (ASIC).
• The decapsulation classification rules apply across an entire ASIC (not per interface).
• The decapsulation classification may or may not include network-instance. Some implementations only support a single network-instance (DEFAULT).
• The UDP destination port to protocol decap mapping may be further constrained to a whole device (ie: the NOS configuration interface requires all ASICs in a multi-ASIC device to be configured with the same destination udp port to protocol decap mapping).

These constraints could be accommodated implicitly in OC models today. One can know these constraints out of band and generate a policy that meets all these un-modeled constraints. While this small addition does not directly attempt to model all these constraints in detail, it makes the decap to network-instance relationship explicit. This should be "good enough" for a user to observe the constraints in the configuration and provides the hint to a NOS that the decap constraints should be applied to this policy.

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 64246ae

[akalluru1]

Copy/pasting the comments from OC community meeting:

• Need to clarify if two policies, should we match and exit on the first policy? Or process both policies?
• What should happen to current implementations? If decapsulate-gre leaf is set in a PBR policy, what should happen?

[dplore]

In the case of two policies, the global should be processed first. If a match is found the actions should be performed and the second policy should not be processed.

/network-instances/network-instance/policy-forwarding/policies/policy/rules/rule/action/config/decapsulate-gre should still be supported. decapsulate-gre could be configured in a global policy or an interface based policy and implementation support may vary.

[dplore]

/gcbrun

[robshakir]

Questions:

• are there existing implementations that we can reference here? (I know that this is implemented for Arista, how does it map elsewhere?)
• in the current approach, there's a global flag being created within a particular policy -- why is this approach chosen vs. the approach of having /network-instances/network-instance/policy-forwarding/config/global-decap-policy = FOO where FOO is the name of the decap policy within the policy list?

(reviewed in 2025-06-03 OpenConfig operators group.)

[dplore]

@danameme please add vendor references for configuring decapsulation

Can you also respond to the quesiton from the OC Operator's meeting:
"""
in the current approach, there's a global flag being created within a particular policy -- why is this approach chosen vs. the approach of having /network-instances/network-instance/policy-forwarding/config/global-decap-policy = FOO where FOO is the name of the decap policy within the policy list?
"""

It seems like the approach of adding 'global-decap-policy' leaf is equivalent to adding a policy type of "DECAP", but is perhaps more simple and explicit. WDYT?

[danameme]

Questions:

• are there existing implementations that we can reference here? (I know that this is implemented for Arista, how does it map elsewhere?)
• in the current approach, there's a global flag being created within a particular policy -- why is this approach chosen vs. the approach of having /network-instances/network-instance/policy-forwarding/config/global-decap-policy = FOO where FOO is the name of the decap policy within the policy list?

(reviewed in 2025-06-03 OpenConfig operators group.)

• I've updated description with existing implementations
• We didn't consider such an approach during initial discussion but it looks good to me. I've updated the PR to reflect this new proposal.

[danameme]

@danameme please add vendor references for configuring decapsulation

Can you also respond to the quesiton from the OC Operator's meeting: """ in the current approach, there's a global flag being created within a particular policy -- why is this approach chosen vs. the approach of having /network-instances/network-instance/policy-forwarding/config/global-decap-policy = FOO where FOO is the name of the decap policy within the policy list? """

It seems like the approach of adding 'global-decap-policy' leaf is equivalent to adding a policy type of "DECAP", but is perhaps more simple and explicit. WDYT?

Yes, I think so. I've updated PR to reflect the proposed approach and updated PR with existing vendor implementations as well.

[akalluru1]

@danameme please add vendor references for configuring decapsulation

Can you also respond to the quesiton from the OC Operator's meeting: """ in the current approach, there's a global flag being created within a particular policy -- why is this approach chosen vs. the approach of having /network-instances/network-instance/policy-forwarding/config/global-decap-policy = FOO where FOO is the name of the decap policy within the policy list? """

It seems like the approach of adding 'global-decap-policy' leaf is equivalent to adding a policy type of "DECAP", but is perhaps more simple and explicit. WDYT?

Couple of issues that I can think of with this approach:

1. what would be the type for the referenced policy in global-decap-policy?
2. As the definition of the policy is disjoint from whether it should be used for decap or not they can come in two different set requests. how would the server implementation decide what do with policy definition but still not referenced by global-decap-policy? If the policy type is going to PBR_POLICY should the server create PBR policy first when it sees the definition & when the reference comes in later should it delete the PBR policy & recreate the decap policy?

@dplore @danameme

[danameme]

@danameme please add vendor references for configuring decapsulation
Can you also respond to the quesiton from the OC Operator's meeting: """ in the current approach, there's a global flag being created within a particular policy -- why is this approach chosen vs. the approach of having /network-instances/network-instance/policy-forwarding/config/global-decap-policy = FOO where FOO is the name of the decap policy within the policy list? """
It seems like the approach of adding 'global-decap-policy' leaf is equivalent to adding a policy type of "DECAP", but is perhaps more simple and explicit. WDYT?

Couple of issues that I can think of with this approach:

1. what would be the type for the referenced policy in global-decap-policy?
2. As the definition of the policy is disjoint from whether it should be used for decap or not they can come in two different set requests. how would the server implementation decide what do with policy definition but still not referenced by global-decap-policy? If the policy type is going to PBR_POLICY should the server create PBR policy first when it sees the definition & when the reference comes in later should it delete the PBR policy & recreate the decap policy?

@dplore @danameme

@akalluru1 please see below responses

1. It will be PBR_POLICY since this approach does not have a new type defined.

2. If the policy type is going to PBR_POLICY should the server create PBR policy first when it sees the definition & when the reference comes in later should it delete the PBR policy & recreate the decap policy?

   Yes. Also, re:garding recreate the decap policy is the new policy still going to be of type PBR_POLICY? If not how will it be different from the one that will be deleted?

[dongping-zhu]

Comparing to the previous option, the new global-decap-policy leaf separates the global policy definition and application. Then, we have following cases.

Creation:
1. policy FOO is defined in the policy list and referred by global-decap-policy leaf at the same time -> the decap group will be created.
2. policy FOO is defined in the policy list first, then it is referred by global-decap-policy leaf -> FOO will be created as a PBR policy first, then it will be converted to a decap group.
3. policy FOO is referred by global-decap-policy leaf first -> request will be rejected because the policy FOO referred by global-decap-policy leaf cannot be found in the policy list.

Deletion:
4. policy FOO is deleted in the policy list and global-decap-policy leaf at the same time -> the decap group will be deleted.
5. policy FOO is deleted in the policy list first -> request will be rejected because the policy FOO referred by global-decap-policy leaf cannot be found in the policy list.
6. policy FOO is deleted in global-decap-policy leaf first, then it is deleted in the policy list -> the decap group will be deleted, but a PBR policy will be created, then the PBR policy will be deleted.

@danameme @dplore Just want to ensure that the above cases and corresponding behaviors make sense, particularly the cases in deletion process.

[dplore]

A platform which only supports decapsulation policies in the form of a single global policy could require any policy containing a decapsulation action to also set global-decap-policy.

So if a client pushes a configuration containing a policy "A" with decapsulate action and there is no global-decap-policy = "A" to such a device, the configuration could be rejected. To have a successful config push, either the global-decap-policy must be set before the policy with decapsulation action is added , or global-decap-policy must be included in the set.