Skip to content

Add new policy type for decapsulation and new leaf for configuring global policy #1288

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

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

Conversation

danameme
Copy link
Contributor

@danameme danameme commented Apr 30, 2025

Change Scope

  • Add new policy forwarding type called DECAP_POLICY for decapsulation.
  • Add new leaf to policy forwarding to indicate a policy application is global.

These are new enhancements being proposed to policy forwarding to allow implementations configure and apply decapsulation policies.

Tree View

@@ -3226,43 +3226,45 @@
         +--rw policy-forwarding
         |  +--rw policies
         |  |  +--rw policy* [policy-id]
         |  |     +--rw policy-id    -> ../config/policy-id
         |  |     +--rw config
         |  |     |  +--rw policy-id?   string
         |  |     |  +--rw type?        enumeration
+        |  |     |  +--rw global?      boolean
         |  |     +--ro state
         |  |     |  +--ro policy-id?   string
         |  |     |  +--ro type?        enumeration
+        |  |     |  +--ro global?      boolean
         |  |     +--rw rules
         |  |        +--rw rule* [sequence-id]
         |  |           +--rw sequence-id        -> ../config/sequence-id
         |  |           +--rw config
         |  |           |  +--rw sequence-id?   uint32

Flatten View

 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/config
+/openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/config/global
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/config/policy-id
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/config/type
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/state
+/openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/state/global
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/state/policy-id
 /openconfig-network-instance:network-instances/network-instance/policy-forwarding/policies/policy/state/type

@dplore
Copy link
Member

dplore commented May 1, 2025

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
Copy link
Member

dplore commented May 1, 2025

/gcbrun

@OpenConfigBot
Copy link

OpenConfigBot commented May 1, 2025

No major YANG version changes in commit 64246ae

@akalluru1
Copy link
Contributor

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
Copy link
Member

dplore commented May 13, 2025

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
Copy link
Member

dplore commented May 16, 2025

/gcbrun

@robshakir
Copy link
Contributor

robshakir commented Jun 3, 2025

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.)

@robshakir robshakir moved this from Ready to discuss to Waiting for author in OC Operator Review Jun 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Waiting for author
Development

Successfully merging this pull request may close these issues.

5 participants