< draft-ietf-rtgwg-policy-model-22.txt   draft-ietf-rtgwg-policy-model-23.txt >
RTGWG Y. Qu RTGWG Y. Qu
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Standards Track J. Tantsura Intended status: Standards Track J. Tantsura
Expires: March 19, 2021 Apstra Expires: March 20, 2021 Apstra
A. Lindem A. Lindem
Cisco Cisco
X. Liu X. Liu
Volta Networks Volta Networks
September 15, 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-22 draft-ietf-rtgwg-policy-model-23
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 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 19, 2021. This Internet-Draft will expire on March 20, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 39 skipping to change at page 5, line 39
are useful across many routing protocols. are useful across many routing protocols.
o A structure that allows routing protocol models to add protocol- o A structure that allows routing protocol models to add protocol-
specific policy conditions and actions though YANG augmentations. specific policy conditions and actions though YANG augmentations.
There is a complete example of this for BGP [RFC4271] policies in There is a complete example of this for BGP [RFC4271] policies in
the proposed vendor-neutral BGP data model the proposed vendor-neutral BGP data model
[I-D.ietf-idr-bgp-model]. [I-D.ietf-idr-bgp-model].
o A reusable grouping for attaching import and export rules in the o A reusable grouping for attaching import and export rules in the
context of routing configuration for different protocols, VRFs, context of routing configuration for different protocols, VRFs,
etc. This also enables creation of policy chains and expressing etc. This also enables creation of policy chains, i.e., a list of
default policy behavior. policies applied in order, and expressing default policy behavior.
The module makes use of the standard Internet types, such as IP The module makes use of the standard Internet types, such as IP
addresses, autonomous system numbers, etc., defined in RFC 6991 addresses, autonomous system numbers, etc., defined in RFC 6991
[RFC6991]. [RFC6991].
4. Route policy expression 4. Route policy expression
Policies are expressed as a sequence of top-level policy definitions Policies are expressed as a sequence of top-level policy definitions
each of which consists of a sequence of policy statements. Policy each of which consists of a sequence of policy statements. Policy
statements in turn consist of simple condition-action tuples. statements in turn consist of simple condition-action tuples.
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 chain is reached, the default route the end of the subroutine policy statements is reached, is reached,
disposition action is returned (i.e., boolean false for reject-route the default route disposition action is returned (i.e., boolean false
unless an alternate default action is specified for the chain). for reject-route). Consequently, a subroutine cannot explicitly
Consequently, a subroutine cannot explicitly accept or reject a accept or reject a route. Rather it merely provides an indication
route. Rather it merely provides an indication that 'call-policy' that 'call-policy' condition returns boolean true or false indicating
condition returns boolean true or false indicating whether or not the whether or not the condition matches. Route acceptance or rejection
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
discouraged. Also, implementations should have validation to ensure discouraged. Also, implementations should have validation to ensure
that there is no recursion amongst nested routing policies. that there is no recursion amongst nested routing policies.
5. Policy evaluation 5. Policy evaluation
Evaluation of each policy definition proceeds by evaluating its Evaluation of each policy definition proceeds by evaluating its
corresponding individual policy statements in order. When all the corresponding individual policy statements in order. When all the
condition statements in a policy statement are satisfied, the condition statements in a policy statement are satisfied, the
corresponding action statements are executed. If the actions include corresponding action statements are executed. If the actions include
either accept-route or reject-route actions, evaluation of the either accept-route or reject-route actions, evaluation of the
current policy definition stops, and no further policy definitions in current policy definition stops, and no further policy statement are
the chain are evaluated. evaluated. If there are multiple policies in the policy chain,
subsequent policies are not evaluated. Policy chains are sequences
of policy definitions (described in Section 4).
If the conditions are not satisfied, then evaluation proceeds to the If the conditions are not satisfied, then evaluation proceeds to the
next policy statement. If none of the policy statement conditions next policy statement. If none of the policy statement conditions
are satisfied, then evaluation of the current policy definition are satisfied, then evaluation of the current policy definition
stops, and the next policy definition in the chain is evaluated. stops, and the next policy definition in the chain is evaluated.
When the end of the policy chain is reached, the default route When the end of the policy chain is reached, the default route
disposition action is performed (i.e., reject-route unless an disposition action is performed (i.e., reject-route unless an
alternate default action is specified for the chain). alternate default action is specified for the chain).
Note that the route's pre-policy attributes are always used for Note that the route's pre-policy attributes are always used for
skipping to change at page 12, line 34 skipping to change at page 12, line 34
9. YANG module 9. YANG module
The routing policy model is described by the YANG modules in the The routing policy model is described by the YANG modules in the
sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are
referenced here since they are referenced in the YANG model but not referenced here since they are referenced in the YANG model but not
elsewhere in this document. elsewhere in this document.
9.1. Routing policy model 9.1. Routing policy model
<CODE BEGINS> file "ietf-routing-policy@2020-08-17.yang" <CODE BEGINS> file "ietf-routing-policy@2020-09-16.yang"
module ietf-routing-policy { module ietf-routing-policy {
yang-version "1.1"; yang-version "1.1";
namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy"; namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
prefix rt-pol; prefix rt-pol;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
reference "RFC 6991: Common YANG Data Types"; reference "RFC 6991: Common YANG Data Types";
skipping to change at page 15, line 32 skipping to change at page 15, line 32
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT
RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be
interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when,
and only when, they appear in all capitals, as shown here. and only when, they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX; This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices."; see the RFC itself for full legal notices.";
revision "2020-08-17" { revision "2020-09-16" {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Routing Policy Configuration Model for Service "RFC XXXX: Routing Policy Configuration Model for Service
Provider Networks"; Provider Networks";
} }
/* Identities */ /* Identities */
identity metric-type { identity metric-type {
skipping to change at page 22, line 36 skipping to change at page 22, line 36
description description
"Configuration data for a prefix definition."; "Configuration data for a prefix definition.";
leaf ip-prefix { leaf ip-prefix {
type inet:ip-prefix; type inet:ip-prefix;
mandatory true; mandatory true;
description description
"The IP prefix represented as an IPv6 or IPv4 network "The IP prefix represented as an IPv6 or IPv4 network
number followed by a prefix length with an intervening number followed by a prefix length with an intervening
slash character as a delimiter. All members of the prefix slash character as a delimiter. All members of the prefix
set should be of the same address family as the prefix-set set MUST be of the same address family as the prefix-set
mode."; mode.";
} }
leaf mask-length-lower { leaf mask-length-lower {
type uint8; type uint8;
description description
"Mask length range lower bound. It should not be less than "Mask length range lower bound. It MUST not be less than
the prefix length defined in ip-prefix."; the prefix length defined in ip-prefix.";
} }
leaf mask-length-upper { leaf mask-length-upper {
type uint8 { type uint8 {
range "1..128"; range "1..128";
} }
must "../mask-length-upper >= ../mask-length-lower" { must "../mask-length-upper >= ../mask-length-lower" {
error-message "The upper bound should not be less" error-message "The upper bound MUST not be less"
+ "than lower bound."; + "than lower bound.";
} }
description description
"Mask length range upper bound. "Mask length range upper bound.
The combination of mask-length-lower and mask-length-upper The combination of mask-length-lower and mask-length-upper
define a range for the mask length, or single 'exact' define a range for the mask length, or single 'exact'
length if mask-length-lower and mask-length-upper are length if mask-length-lower and mask-length-upper are
equal. equal.
skipping to change at page 23, line 29 skipping to change at page 23, line 29
Example: 192.0.2.0/24 (an exact match) would be Example: 192.0.2.0/24 (an exact match) would be
expressed as prefix: 192.0.2.0/24, expressed as prefix: 192.0.2.0/24,
mask-length-lower=24, mask-length-lower=24,
mask-length-upper=24"; mask-length-upper=24";
} }
} }
grouping match-set-options-group { grouping match-set-options-group {
description description
"Grouping containing options relating to how a particular set "Grouping containing options relating to how a particular set
should be matched."; will be matched.";
leaf match-set-options { leaf match-set-options {
type match-set-options-type; type match-set-options-type;
description description
"Optional parameter that governs the behavior of the "Optional parameter that governs the behavior of the
match operation."; match operation.";
} }
} }
grouping match-set-options-restricted-group { grouping match-set-options-restricted-group {
skipping to change at page 24, line 27 skipping to change at page 24, line 27
description description
"This grouping provides interface match condition."; "This grouping provides interface match condition.";
container match-interface { container match-interface {
leaf interface { leaf interface {
type leafref { type leafref {
path "/if:interfaces/if:interface/if:name"; path "/if:interfaces/if:interface/if:name";
} }
description description
"Reference to a base interface. If a reference to a "Reference to a base interface. If a reference to a
subinterface is required, this leaf must be specified subinterface is required, this leaf MUST be specified
to indicate the base interface."; to indicate the base interface.";
} }
leaf subinterface { leaf subinterface {
type leafref { type leafref {
path "/if:interfaces/if:interface/if-ext:encapsulation" path "/if:interfaces/if:interface/if-ext:encapsulation"
+ "/if-flex:flexible/if-flex:match" + "/if-flex:flexible/if-flex:match"
+ "/if-flex:dot1q-vlan-tagged" + "/if-flex:dot1q-vlan-tagged"
+ "/if-flex:outer-tag/if-flex:vlan-id"; + "/if-flex:outer-tag/if-flex:vlan-id";
} }
description description
"Reference to a subinterface -- this requires the base "Reference to a subinterface -- this requires the base
interface to be specified using the interface leaf in interface to be specified using the interface leaf in
this container. If only a reference to a base interface this container. If only a reference to a base interface
is required, this leaf should not be set."; is required, this leaf SHOULD not be set.";
} }
description description
"Container for interface match conditions"; "Container for interface match conditions";
} }
} }
grouping match-route-type-condition { grouping match-route-type-condition {
description description
"This grouping provides route-type match condition"; "This grouping provides route-type match condition";
skipping to change at page 29, line 4 skipping to change at page 29, line 4
} }
enum ipv6 { enum ipv6 {
description description
"Prefix set contains IPv6 prefixes only."; "Prefix set contains IPv6 prefixes only.";
} }
} }
description description
"Indicates the mode of the prefix set, in terms of "Indicates the mode of the prefix set, in terms of
which address families (IPv4, IPv6, or both) are which address families (IPv4, IPv6, or both) are
present. The mode provides a hint, but the device present. The mode provides a hint, but the device
must validate that all prefixes are of the indicated MUST validate that all prefixes are of the indicated
type, and is expected to reject the configuration if type, and is expected to reject the configuration if
there is a discrepancy."; there is a discrepancy.";
} }
container prefixes { container prefixes {
description description
"Container for the list of prefixes in a policy "Container for the list of prefixes in a policy
prefix list. Since individual prefixes do not have prefix list. Since individual prefixes do not have
unique actions, the order in which the prefix in unique actions, the order in which the prefix in
prefix-list are matched has no impact on the outcome prefix-list are matched has no impact on the outcome
outcome and is is left to the implementation. A outcome and is left to the implementation. A
given prefix-set condition is statisfied if the given prefix-set condition is statisfied if the
input prefix matches any of the prefixes in the input prefix matches any of the prefixes in the
prefix-set."; prefix-set.";
list prefix-list { list prefix-list {
key "ip-prefix mask-length-lower mask-length-upper"; key "ip-prefix mask-length-lower mask-length-upper";
description description
"List of prefixes in the prefix set."; "List of prefixes in the prefix set.";
uses prefix; uses prefix;
skipping to change at page 31, line 40 skipping to change at page 31, line 40
leaf call-policy { leaf call-policy {
type leafref { type leafref {
path "../../../../../../" + path "../../../../../../" +
"rt-pol:policy-definitions/" + "rt-pol:policy-definitions/" +
"rt-pol:policy-definition/rt-pol:name"; "rt-pol:policy-definition/rt-pol:name";
require-instance true; require-instance true;
} }
description description
"Applies the statements from the specified policy "Applies the statements from the specified policy
definition and then returns control the current definition and then returns control to the current
policy statement. Note that the called policy policy statement. Note that the called policy
may itself call other policies (subject to may itself call other policies (subject to
implementation limitations). This is intended to implementation limitations). This is intended to
provide a policy 'subroutine' capability. The provide a policy 'subroutine' capability. The
called policy should contain an explicit or a called policy SHOULD contain an explicit or a
default route disposition that returns an default route disposition that returns an
effective true (accept-route) or false effective true (accept-route) or false
(reject-route), otherwise the behavior may be (reject-route), otherwise the behavior may be
ambiguous."; ambiguous.";
} }
leaf source-protocol { leaf source-protocol {
type identityref { type identityref {
base rt:control-plane-protocol; base rt:control-plane-protocol;
} }
 End of changes. 19 change blocks. 
28 lines changed or deleted 29 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/