public
public copied to clipboard
openconfig
decap-then-lookup OC schema
Propose an OC schema to support/unify the representation of use cases where
- The decapsulation action is controlled by SDN controllers populated network-instance (e.g. via gRIBI).
- And the lookup on the new header happens in another network instance, which is chosen by fields that are not used for resolution.
This will be useful for chained decap-then-lookup TE scenarios.
module: openconfig-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw policy-forwarding
+--rw policies
+--rw policy* [policy-id]
+--rw rules
+--rw rule* [sequence-id]
+--rw action
+--rw config
+--rw decap-lookup , // <------------------------ ** new container proposed **
+--rw network-instance? -> /network-instances/network-instance/config/name
+--rw fallback-network-instance? -> /network-instances/network-instance/config/name
@rolandphung, @aaronmillisor, @adamsimpson1, and @earies to help review before @dplore.
I feel this modeling is too specific to one use case. I am wondering if it can be generalized.
A packet matching a PBF rule with this new decap-lookup action is not guaranteed to be a packet that can be decapsulated and even if it can be decapsulated, the PBF action itself has no control on whether the decapsulation is done or not -- this outcome is entirely based on whether the referenced network-instance (or its fallback) has a matching route with next-hop action that performs decapsulation.
Given this, it seems to me that you could support the new functionality just by introducing one new PBF action called fallback-network-instance at the same level as the existing actions.
A complete action configuration could be:
action
+--network-instance
If an IPinP packet matches this rule, there will be a first lookup in
My 2 cents.
I feel this modeling is too specific to one use case. I am wondering if it can be generalized.
A packet matching a PBF rule with this new decap-lookup action is not guaranteed to be a packet that can be decapsulated and even if it can be decapsulated, the PBF action itself has no control on whether the decapsulation is done or not -- this outcome is entirely based on whether the referenced network-instance (or its fallback) has a matching route with next-hop action that performs decapsulation.
Given this, it seems to me that you could support the new functionality just by introducing one new PBF action called fallback-network-instance at the same level as the existing actions.
A complete action configuration could be: action +--network-instance +--fallback-network-instance
If an IPinP packet matches this rule, there will be a first lookup in and if there is a matching entry in it may or may not perform decapsulation; the OC model is agnostic. If the first lookup in finds no matching route, a second lookup will occur in . Again, the matching entry in may or may not perform decapsulation, and the OC model should not care.
My 2 cents.
I think your proposal missed one more NI that's to be used for post decap lookup? We can sync offline to chat more.
Looks OK to me. The description for decap-network-instance states that this network-instance is expected to have entries that perform decapsulation as a next-hop action. What if it has other types of entries? Should those be ignored so they can never match? I think some text should be included about this.
Why are there decapsulate-mpls-in-udp, decapsulate-gue and decapsulate-gre actions but no decapsulate-ip-in-ip action? Including one of these in combination with decap-network-instance could further specify the types of decapsulation entries that are expected in the decap-network-instance.
Looks OK to me. The description for decap-network-instance states that this network-instance is expected to have entries that perform decapsulation as a next-hop action. What if it has other types of entries? Should those be ignored so they can never match? I think some text should be included about this.
I think the current wording, It is expected that the NI should only contain routes that have next hop action as decapsualtion indicates that vendors can implement needed precondition to avoid having such entries?
Why are there decapsulate-mpls-in-udp, decapsulate-gue and decapsulate-gre actions but no decapsulate-ip-in-ip action? Including one of these in combination with decap-network-instance could further specify the types of decapsulation entries that are expected in the decap-network-instance.
The usage of those leaves are for the policy rules that does match and then the specific decapsulation action. However, this PR is about rely on NI that is controlled by SDN controllers who push the decapsulation action.
We have talked to your team offline several times. I'm not expecting any big concerns.
@adrawatcisco, @nokia1adam, @rolandphung, @aredmon8551 approve to merge? If no objection by 2023-04-11, I"ll go ahead and merge. Thanks.
Just a nit on the process, can we get the relevant pyang output in the description?
Just a nit on the process, can we get the relevant pyang output in the description?
Ah, forgot that. Done. Thanks!
Major YANG version changes in commit 3b408019812cf02b38c7f71781d9e30cd74c1c6b: