| < draft-ietf-rtgwg-policy-model-23.txt | draft-ietf-rtgwg-policy-model-24.txt > | |||
|---|---|---|---|---|
| skipping to change at page 1, line 14 ¶ | skipping to change at page 1, line 14 ¶ | |||
| Internet-Draft Futurewei | Internet-Draft Futurewei | |||
| Intended status: Standards Track J. Tantsura | Intended status: Standards Track J. Tantsura | |||
| Expires: March 20, 2021 Apstra | Expires: March 20, 2021 Apstra | |||
| A. Lindem | A. Lindem | |||
| Cisco | Cisco | |||
| X. Liu | X. Liu | |||
| Volta Networks | Volta Networks | |||
| September 16, 2020 | September 16, 2020 | |||
| A YANG Data Model for Routing Policy Management | A YANG Data Model for Routing Policy Management | |||
| draft-ietf-rtgwg-policy-model-23 | draft-ietf-rtgwg-policy-model-24 | |||
| Abstract | Abstract | |||
| This document defines a YANG data model for configuring and managing | This document defines a YANG data model for configuring and managing | |||
| routing policies in a vendor-neutral way and based on actual | routing policies in a vendor-neutral way and based on actual | |||
| operational practice. The model provides a generic policy framework | operational practice. The model provides a generic policy framework | |||
| which can be augmented with protocol-specific policy configuration. | which can be augmented with protocol-specific policy configuration. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 9, line 39 ¶ | skipping to change at page 9, line 39 ¶ | |||
| conditions and actions before returning to the calling policy | conditions and actions before returning to the calling policy | |||
| statement and resuming evaluation. The outcome of the called policy | statement and resuming evaluation. The outcome of the called policy | |||
| affects the evaluation of the calling policy. If the called policy | affects the evaluation of the calling policy. If the called policy | |||
| results in an accept-route, then the subroutine returns an effective | results in an accept-route, then the subroutine returns an effective | |||
| boolean true value to the calling policy. For the calling policy, | boolean true value to the calling policy. For the calling policy, | |||
| this is equivalent to a condition statement evaluating to a true | this is equivalent to a condition statement evaluating to a true | |||
| value and evaluation of the policy continues (see Section 5). Note | value and evaluation of the policy continues (see Section 5). Note | |||
| that the called policy may also modify attributes of the route in its | that the called policy may also modify attributes of the route in its | |||
| action statements. Similarly, a reject-route action returns false | action statements. Similarly, a reject-route action returns false | |||
| and the calling policy evaluation will be affected accordingly. When | and the calling policy evaluation will be affected accordingly. When | |||
| the end of the subroutine policy statements is reached, is reached, | the end of the subroutine policy statements is reached, the default | |||
| the default route disposition action is returned (i.e., boolean false | route disposition action is returned (i.e., boolean false for reject- | |||
| for reject-route). Consequently, a subroutine cannot explicitly | route). Consequently, a subroutine cannot explicitly accept or | |||
| accept or reject a route. Rather it merely provides an indication | reject a route. Rather it merely provides an indication that 'call- | |||
| that 'call-policy' condition returns boolean true or false indicating | policy' condition returns boolean true or false indicating whether or | |||
| whether or not the condition matches. Route acceptance or rejection | not the condition matches. Route acceptance or rejection is solely | |||
| is solely determined by the top-level policy. | determined by the top-level policy. | |||
| Note that the called policy may itself call other policies (subject | Note that the called policy may itself call other policies (subject | |||
| to implementation limitations). The model does not prescribe a | to implementation limitations). The model does not prescribe a | |||
| nesting depth because this varies among implementations. For | nesting depth because this varies among implementations. For | |||
| example, some major implementation may only support a single level of | example, some major implementation may only support a single level of | |||
| subroutine recursion. As with any routing policy construction, care | subroutine recursion. As with any routing policy construction, care | |||
| must be taken with nested policies to ensure that the effective | must be taken with nested policies to ensure that the effective | |||
| return value results in the intended behavior. Nested policies are a | return value results in the intended behavior. Nested policies are a | |||
| convenience in many routing policy constructions but creating | convenience in many routing policy constructions but creating | |||
| policies nested beyond a small number of levels (e.g., 2-3) are | policies nested beyond a small number of levels (e.g., 2-3) are | |||
| End of changes. 2 change blocks. | ||||
| 8 lines changed or deleted | 8 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||