add NEXT-STATEMENT to policy-result-type #949
Conversation
|
Major YANG version changes in commit e0372f6: |
|
Compatibility Report for commit e0372f6: |
dplore
changed the title
|
What is the operational use case that we're envisaging for In a similar vein, what's the case where there is ambiguity w.r.t |
|
What is expected behavior if all matching statement has NEXT_STATEMENT action? |
Co-authored-by: Óscar González de Dios <[email protected]>
Then the default apply-policy action is applied (default-import-policy default-export-policy leaves). This is either REJECT or ACCEPT. |
|
IOS-XR 'pass' is not same as 'NEXT-STATEMENT'. It Carrie's semantics of "conditionally accepted" unless explicitly dropped in subsequent statements. |
Yes, but...
|
Co-authored-by: Óscar González de Dios <[email protected]>
Co-authored-by: Óscar González de Dios <[email protected]>
Co-authored-by: Óscar González de Dios <[email protected]>
That's interesting. it looks like Cisco's and Arista's policy evaluation may be quite different from Juniper's, which looks the most similar to OpenConfig to me: Cisco: "If a policy modifies a route, by default the policy accepts the route.", "If a policy does not modify the route, by default the route is dropped." I didn't look deeper into Arista, but in Cisco, whether a particular policy matched a route changes the default behaviour of the route. aka. when mapped to OpenConfig, the default-(import/export)-policy changes depending on whether a particular policy matched and had a
So the default policy type has a YANG default value: https://openconfig.net/projects/models/schemadocs/yangdoc/openconfig-network-instance.html#network-instances-network-instance-inter-instance-policies-apply-policy-config-default-import-policy Per the standard this means even if not configured, it will still have the value of REJECT. |
In OC I think one could produce this behavior using |
Today in Google, we have policies which make use, in some cases extensively, of both of these policy-result-type semantics. I will refer them to you offline. Regarding ambiguity in the current model: In the current model, there is only a description at the beginning of the module which says, "If the condition is not satisfied, then evaluation proceeds to the next policy statement." But what if the condition is satisfied and there is no |
I believe this does not work in all cases, In this case, changing However as you pointed out Arista has a |
|
We don't have explicit support of NEXT-POLICY defined by multiple implementations, but we do for NEXT-STATEMENT. |
Lets take an example. Wherhas in OpenConfig NEXT_STATEMENT (and juniper next-term): |
example:Cisco: the 10.0.0/24 will be dropped. OpenConfig , JUNIPER the 10.0.0/24 will be accepted. |
In arista
Note: we should prevent jumping backwards.. It become too fragile - forever loops. perhaps next_statement-name/next_policy-name is too much. |
I think this is not correct? pass is "accept and continue". This policy would accept 10.0.0/24. Ref: cisco ios xr route policy disposition |
The 10.0.0/24 is matching statement 2 (10.0/16-32, so /16 or any more specific, that is also 10.0.0/24) with explicit drop. |
There was a problem hiding this comment.
Please consider replacement of lines 43-87 by following:
Route policy evaluation:
Policy definitions are referenced in routing protocol
configurations using import and export configuration statements.
The arguments are members of an ordered list of named policy
definitions which comprise a policy chain, and optionally, an
default final dispositinn action for policy chain (i.e., reject
or accept) applied to routes that does not match conditions of
any statement of any policy in chain, or none of matching
statement has final dispositinn action (acept or reject).
If default final dispositinn action for policy chain is not
explicitly specifird, implicit default action is reject.
Note: This file contains definition of single policy, wherehas
definition of policy chain and default final dispositinn action
for policy chain are properties of protocol's policy application,
and are defiend as part of protocols model. The text in this
paragraph provides context information.
Evaluation of each policy definition proceeds by evaluating its
corresponding individual policy statements in order. When a
condition statement in a policy statement is satisfied, the
corresponding action statement is executed. If the action
statement has a final disposition configured as policy result, either
accept-route or reject-route, evaluation of the current policy definition
stops, and no further policy statements are evaluated. In case there is a
policy chain, no further policy definitions in the chain are evaluated.
If the action statement has the NEXT_STATEMENT policy result, all the
defined actions are exectued and policy evaluation proceeds to the next
statement. If statement is last in current policy, and current policy is
not the last policy of the policy chain, policy evaluation proceeds to
the first statement of next policy. If statement is last in current policy,
and current policy is the last policy of the policy chain, default final
disposition action for policy chain is applied.
If the action statement has the NEXT_POLICY policy result, all the
defined actions in this stetement are exectued, evaluation of statements
within the current policy stops and evaluation proceeds to the first
statement of next policy in the chain. If statement is last in current
policy, and current policy is the last policy of the policy chain, default
final disposition action for policy chain is applied.
Policy 'subroutines' (or nested policies) are supported by
allowing policy statement conditions to reference another policy
definition which applies conditions and actions from the
referenced policy before returning to the calling policy
statement and resuming evaluation. If the called policy
results in an accept-route (either explicit or by default), then
the subroutine returns an effective true value to the calling
policy. Any other policy result action - reject-route, next_statement,
next_policy - returns false. If the subroutine returns true,
the calling policy continues to evaluate the remaining conditions of current
stement (using a modified route if the subroutine performed any changes to
the route), and if also satisfied executes statement's action. If the
subroutine returns true, evaluation proceeds to next statement or policy.
";
|
I am changing the scope of this PR back to be only NEXT-STATEMENT since we are only finding 1 instance of NEXT-POLICY functionality. |
dplore
changed the title
|
Hello Darren, hello all. Sorry to react late. Here in Orange group we have our +20 IP backbone networks worldwide, which are built with various vendors routers (mainly: Cisco XR, Juniper, Nokia, Huawei). For more than 20 years, in our engineering guidelines history, the routers configurations templates converged to obtain most generic and most re-usable config as possible. In this spirit, we have a wide usage of NEXT-STATEMENT, and also NEXT-POLICY. When automating the production using openconfig yang we would like the possibility to keep following behavior: example: export route-policy [ policy1 policy2 policy3] if inside policy1, even statement x1 has result accept, we would policy 1 : task A These kind of configuration of chained policies are widely used among +50000 backbone routers inside Orange networks. NOKIA: |
|
In these Juniper config extract, we have 3 chained policies, each policy has got a determined scope, "action next-policy" is useful. ORANGE operational network config extract JUNIPER: same spirit, chained policies used in context of L3VPN routing-instance (-> oc : network-instance ) CUST-VRF-LDAFRA_BVPN { |
|
@TANTRAN1
It is philosofical question if we want OpenConfig to be suprset of all vendors capabilities or rather reduced set. If former, you will have very flexible OpenConfig but then each vendor will support only partially. The net result would be that operator will either generate vendor-aware configuration what defeat purpose of vendor agnosticity of OpenConfig. Or will self limit and use only subset of OpenConfig common to all vendors it uses. And this would make high acceptance barier for new vendor. So other form of vendor lock-in. |
|
Hello rszarecki Juniper & Nokia: have "next-policy" in their implem. I know, The good example of configuration to discuss , which requires "next-policy" is the ones I provide with JUNIPER (action next-policy written in numerous terms policy-statements, not only the end of policy) Question "2-cent" : is the "next-statement" put at the last entry of a policy_1, makes start the evaluation of the policy_2 , even prefix matched conditions of policy_1 ? do you see a mean to replace effect of "next-policy" by usage of "next-statement" ? If not, I maintain the need to re-open the request of having "next-policy" ...... considering the potential impact of rewriting all RPL for some Nokia/Juniper customers Thanks |
|
Hello rszarecki I do agree some other operators may use simpler RPL (without need of "next-policy") but not our case, we must assume it. |
* Update release/models/policy/openconfig-routing-policy.yang * add continue to policy-result-type --------- Co-authored-by: Óscar González de Dios <[email protected]>
Change Scope
NEXT-STATEMENTto the typedef forroute-policy-result.NEXT-STATEMENTas the default.clarify the expected behavior if there is a match for a policy, but no policy-result is
specified.
This change adds a default where there previously was none. So if an implementation performs some other action than
NEXT-STATEMENTby default, it could be a breaking change.Platform Implementations
This result type corresponds to the the following policy match actions in existing implementations.
NEXT-STATEMENTNEXT-STATEMENT. It differs in thatpassmeans both accept-route and continue. In OC,NEXT-STATEMENTonly means move to the next action in the policy.NEXT-STATEMENT. Arista's continue statement has additional parameters not contemplated in this PR.