< draft-ietf-rtgwg-policy-model-24.txt   draft-ietf-rtgwg-policy-model-25.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 20, 2021 Apstra Expires: March 22, 2021 Apstra
A. Lindem A. Lindem
Cisco Cisco
X. Liu X. Liu
Volta Networks Volta Networks
September 16, 2020 September 18, 2020
A YANG Data Model for Routing Policy Management A YANG Data Model for Routing Policy Management
draft-ietf-rtgwg-policy-model-24 draft-ietf-rtgwg-policy-model-25
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 20, 2021. This Internet-Draft will expire on March 22, 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, i.e., a list of etc. This also enables creation of policy chains and expressing
policies applied in order, and expressing default policy behavior. default policy behavior. In this document, policy chains are
sequences of policy definitions that are applied in order
(described in Section 4).
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 10, line 20 skipping to change at page 10, line 20
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 statement are current policy definition stops, and no further policy statement are
evaluated. If there are multiple policies in the policy chain, evaluated. If there are multiple policies in the policy chain,
subsequent policies are not evaluated. Policy chains are sequences subsequent policies are not evaluated. Policy chains are sequences
of policy definitions (described in Section 4). 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-09-16.yang" <CODE BEGINS> file "ietf-routing-policy@2020-09-18.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-09-16" { revision "2020-09-18" {
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 20, line 4 skipping to change at page 20, line 4
description description
"Identity for OSPF NSSA type 2 route type. "Identity for OSPF NSSA type 2 route type.
It is only applicable to OSPF routes."; It is only applicable to OSPF routes.";
reference reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
} }
identity bgp-internal { identity bgp-internal {
base proto-route-type; base proto-route-type;
description description
"Identity for routes learned from internal BGP (iBGP). "Identity for routes learned from internal BGP (IBGP).
It is only applicable to BGP routes."; It is only applicable to BGP routes.";
reference reference
"RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
} }
identity bgp-external { identity bgp-external {
base proto-route-type; base proto-route-type;
description description
"Identity for routes learned from external BGP (eBGP). "Identity for routes learned from external BGP (EBGP).
It is only applicable to BGP routes."; It is only applicable to BGP routes.";
reference reference
"RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
} }
/* Type Definitions */ /* Type Definitions */
typedef default-policy-type { typedef default-policy-type {
type enumeration { type enumeration {
enum accept-route { enum accept-route {
skipping to change at page 29, line 15 skipping to change at page 29, line 15
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 left to the implementation. A and is left to the implementation. A given prefix-set
given prefix-set condition is statisfied if the condition is satisfied if the input prefix matches
input prefix matches any of the prefixes in the 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;
} }
} }
} }
 End of changes. 11 change blocks. 
15 lines changed or deleted 16 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/