< draft-ietf-rtgwg-policy-model-16.txt   draft-ietf-rtgwg-policy-model-17.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: December 20, 2020 Apstra Expires: January 6, 2021 Apstra
A. Lindem A. Lindem
Cisco Cisco
X. Liu X. Liu
Volta Networks Volta Networks
June 18, 2020 July 5, 2020
A YANG Data Model for Routing Policy Management A YANG Data Model for Routing Policy Management
draft-ietf-rtgwg-policy-model-16 draft-ietf-rtgwg-policy-model-17
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 December 20, 2020. This Internet-Draft will expire on January 6, 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 2, line 27 skipping to change at page 2, line 27
4. Route policy expression . . . . . . . . . . . . . . . . . . . 5 4. Route policy expression . . . . . . . . . . . . . . . . . . . 5
4.1. Defined sets for policy matching . . . . . . . . . . . . 6 4.1. Defined sets for policy matching . . . . . . . . . . . . 6
4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7 4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7
4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8 4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8
4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9 4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9
5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 10 5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 10
6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10 6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10
7. Routing protocol-specific policies . . . . . . . . . . . . . 11 7. Routing protocol-specific policies . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Routing policy model . . . . . . . . . . . . . . . . . . 15 10.1. Routing policy model . . . . . . . . . . . . . . . . . . 15
11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 36 11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 36
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
12.1. Normative references . . . . . . . . . . . . . . . . . . 38 12.1. Normative references . . . . . . . . . . . . . . . . . . 38
12.2. Informative references . . . . . . . . . . . . . . . . . 40 12.2. Informative references . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document describes a YANG [RFC7950] data model for routing This document describes a YANG [RFC7950] data model for routing
policy configuration based on operational usage and best practices in policy configuration based on operational usage and best practices in
a variety of service provider networks. The model is intended to be a variety of service provider networks. The model is intended to be
vendor-neutral, in order to allow operators to manage policy vendor-neutral, in order to allow operators to manage policy
configuration in a consistent, intuitive way in heterogeneous configuration in a consistent, intuitive way in heterogeneous
environments with routers supplied by multiple vendors. environments with routers supplied by multiple vendors.
skipping to change at page 3, line 43 skipping to change at page 3, line 43
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Routing Policy: A routing policy defines how routes are imported, Routing Policy: A routing policy defines how routes are imported,
exported, modified, and advertised between routing protocols exported, modified, and advertised between routing protocol instances
instances or within a single routing protocol instance. or within a single routing protocol instance.
The following terms are defined in [RFC8342]: The following terms are defined in [RFC8342]:
o client o client
o server o server
o configuration o configuration
o system state o system state
skipping to change at page 6, line 21 skipping to change at page 6, line 21
+--rw statements +--rw statements
+--rw statement* [name] +--rw statement* [name]
+--rw name string +--rw name string
+--rw conditions +--rw conditions
| ... | ...
+--rw actions +--rw actions
... ...
4.1. Defined sets for policy matching 4.1. Defined sets for policy matching
The models provides a set of generic sets that can be used for The models provide a set of generic sets that can be used for
matching in policy conditions. These sets are applicable for route matching in policy conditions. These sets are applicable for route
selection across multiple routing protocols. They may be further selection across multiple routing protocols. They may be further
augmented by protocol-specific models which have their own defined augmented by protocol-specific models which have their own defined
sets. The supported defined sets include: sets. The supported defined sets include:
o prefix sets - define a set of IP prefixes, each with an associated o prefix sets - define a set of IP prefixes, each with an associated
IP prefix and netmask range (or exact length) IP prefix and netmask range (or exact length)
o neighbor sets - define a set of neighboring nodes by their IP o neighbor sets - define a set of neighboring nodes by their IP
addresses. These sets are used for selecting routes based on the addresses. These sets are used for selecting routes based on the
skipping to change at page 7, line 34 skipping to change at page 7, line 34
| +--rw tag-value* tag-type | +--rw tag-value* tag-type
4.2. Policy conditions 4.2. Policy conditions
Policy statements consist of a set of conditions and actions (either Policy statements consist of a set of conditions and actions (either
of which may be empty). Conditions are used to match route of which may be empty). Conditions are used to match route
attributes against a defined set (e.g., a prefix set), or to compare attributes against a defined set (e.g., a prefix set), or to compare
attributes against a specific value. attributes against a specific value.
Match conditions may be further modified using the match-set-options Match conditions may be further modified using the match-set-options
configuration which allows operators to change the behavior of a configuration which allows network operators to change the behavior
match. Three options are supported: of a match. Three options are supported:
o ALL - match is true only if the given value matches all members of o ALL - match is true only if the given value matches all members of
the set. the set.
o ANY - match is true if the given value matches any member of the o ANY - match is true if the given value matches any member of the
set. set.
o INVERT - match is true if the given value does not match any o INVERT - match is true if the given value does not match any
member of the given set. member of the given set.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
+--rw statements +--rw statements
+--rw statement* [name] +--rw statement* [name]
+--rw actions +--rw actions
+--rw policy-result? policy-result-type +--rw policy-result? policy-result-type
+--rw set-metric +--rw set-metric
| +--rw metric-modification? | +--rw metric-modification?
| | metric-modification-type | | metric-modification-type
| +--rw metric? uint32 | +--rw metric? uint32
+--rw set-metric-type +--rw set-metric-type
| +--rw metric-type? identityref | +--rw metric-type? identityref
+--rw set-import-level +--rw set-route-level
| +--rw import-level? identityref | +--rw route-level? identityref
+--rw set-preference? uint16 +--rw set-preference? uint16
+--rw set-tag? tag-type +--rw set-tag? tag-type
+--rw set-application-tag? tag-type +--rw set-application-tag? tag-type
4.4. Policy subroutines 4.4. Policy subroutines
Policy 'subroutines' (or nested policies) are supported by allowing Policy 'subroutines' (or nested policies) are supported by allowing
policy statement conditions to reference other policy definitions policy statement conditions to reference other policy definitions
using the call-policy configuration. Called policies apply their using the call-policy configuration. Called policies apply their
conditions and actions before returning to the calling policy conditions and actions before returning to the calling policy
skipping to change at page 10, line 7 skipping to change at page 10, line 7
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) should be policies nested beyond a small number of levels (e.g., 2-3) are
discouraged. Also, implementations should have validation to assure 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 definitions in
skipping to change at page 10, line 38 skipping to change at page 10, line 38
Note that the route's pre-policy attributes are always used for Note that the route's pre-policy attributes are always used for
testing policy statement conditions. In other words, if actions testing policy statement conditions. In other words, if actions
modify the policy application specific attributes, those modify the policy application specific attributes, those
modifications are not used for policy statement conditions. modifications are not used for policy statement conditions.
6. Applying routing policy 6. Applying routing policy
Routing policy is applied by defining and attaching policy chains in Routing policy is applied by defining and attaching policy chains in
various routing contexts. Policy chains are sequences of policy various routing contexts. Policy chains are sequences of policy
definitions (described in Section 4) that have an associated definitions (described in Section 4). They can be referenced from
direction (import or export) with respect to the routing context in different contexts. For example, a policy chain could be associated
which they are defined. The routing policy model defines an apply- with a routing protocol and used to control its interaction with its
policy grouping that can be imported and used by other models. As protocol peers. Or, it could be used to control the interaction
shown below, it allows definition of import and export policy chains, between a routing protocol and the local routing information base. A
as well as specifying the default route disposition to be used when policy chain has an associated direction (import or export), with
no policy definition in the chain results in a final decision. respect to the context in which it is referenced.
The routing policy model defines an apply-policy grouping that can be
imported and used by other models. As shown below, it allows
definition of import and export policy chains, as well as specifying
the default route disposition to be used when no policy definition in
the chain results in a final decision.
+--rw apply-policy +--rw apply-policy
| +--rw import-policy* | +--rw import-policy*
| +--rw default-import-policy? default-policy-type | +--rw default-import-policy? default-policy-type
| +--rw export-policy* | +--rw export-policy*
| +--rw default-export-policy? default-policy-type | +--rw default-export-policy? default-policy-type
The default policy defined by the model is to reject the route for The default policy defined by the model is to reject the route for
both import and export policies. both import and export policies.
skipping to change at page 13, line 5 skipping to change at page 13, line 11
| +--rw bp:match-as-path-set | +--rw bp:match-as-path-set
| +--rw bp:as-path-set? | +--rw bp:as-path-set?
| +--rw bp:match-set-options? | +--rw bp:match-set-options?
+--rw actions +--rw actions
+--rw policy-result? policy-result-type +--rw policy-result? policy-result-type
+--rw set-metric +--rw set-metric
| +--rw metric-modification? | +--rw metric-modification?
| +--rw metric? uint32 | +--rw metric? uint32
+--rw set-metric-type +--rw set-metric-type
| +--rw metric-type? identityref | +--rw metric-type? identityref
+--rw set-import-level +--rw set-route-level
| +--rw import-level? identityref | +--rw route-level? identityref
+--rw set-preference? uint16 +--rw set-preference? uint16
+--rw set-tag? tag-type +--rw set-tag? tag-type
+--rw set-application-tag? tag-type +--rw set-application-tag? tag-type
+--rw bp:bgp-actions +--rw bp:bgp-actions
+--rw bp:set-route-origin?bt:bgp-origin-attr-type +--rw bp:set-route-origin?bt:bgp-origin-attr-type
+--rw bp:set-local-pref? uint32 +--rw bp:set-local-pref? uint32
+--rw bp:set-next-hop? bgp-next-hop-type +--rw bp:set-next-hop? bgp-next-hop-type
+--rw bp:set-med? bgp-set-med-type +--rw bp:set-med? bgp-set-med-type
+--rw bp:set-as-path-prepend +--rw bp:set-as-path-prepend
| +--rw bp:repeat-n? uint8 | +--rw bp:repeat-n? uint8
skipping to change at page 14, line 48 skipping to change at page 15, line 10
name: ietf-routing-policy name: ietf-routing-policy
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
reference: RFC XXXX reference: RFC XXXX
10. YANG module 10. 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 the draft. elsewhere in this document.
10.1. Routing policy model 10.1. Routing policy model
<CODE BEGINS> file "ietf-routing-policy@2020-06-02.yang" <CODE BEGINS> file "ietf-routing-policy@2020-07-05.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 16, line 35 skipping to change at page 16, line 42
within a single routing protocol instance. This module is within a single routing protocol instance. This module is
intended to be used in conjunction with routing protocol intended to be used in conjunction with routing protocol
configuration modules (e.g., BGP) defined in other models. configuration modules (e.g., BGP) defined in other models.
Route policy expression: Route policy expression:
Policies are expressed as a set of top-level policy Policies are expressed as a set of top-level policy
definitions, each of which consists of a sequence of policy definitions, each of which consists of a sequence of policy
statements. Policy statements consist of simple statements. Policy statements consist of simple
condition-action tuples. Conditions may include multiple match condition-action tuples. Conditions may include multiple match
or comparison operations, and similarly actions may be or comparison operations, and similarly actions may be a
multitude of changes to route attributes or a final multitude of changes to route attributes or a final
disposition of accepting or rejecting the route. disposition of accepting or rejecting the route.
Route policy evaluation: Route policy evaluation:
Policy definitions are referenced in routing protocol Policy definitions are referenced in routing protocol
configurations using import and export configuration configurations using import and export configuration
statements. The arguments are members of an ordered list of statements. The arguments are members of an ordered list of
named policy definitions which comprise a policy chain, and named policy definitions which comprise a policy chain, and
optionally, an explicit default policy action (i.e., reject optionally, an explicit default policy action (i.e., reject
skipping to change at page 17, line 21 skipping to change at page 17, line 28
policy definition stops, and the next policy definition in the policy definition stops, and the next policy definition in the
chain is evaluated. When the end of the policy chain is chain is evaluated. When the end of the policy chain is
reached, the default route disposition action is performed reached, the default route disposition action is performed
(i.e., reject-route unless an alternate default action is (i.e., reject-route unless an alternate default action is
specified for the chain). specified for the chain).
Policy 'subroutines' (or nested policies) are supported by Policy 'subroutines' (or nested policies) are supported by
allowing policy statement conditions to reference another allowing policy statement conditions to reference another
policy definition which applies conditions and actions from policy definition which applies conditions and actions from
the referenced policy before returning to the calling policy the referenced policy before returning to the calling policy
statement and resuming evaluation. If the called policy statement and resuming evaluation. If the called policy
results in an accept-route (either explicit or by default), results in an accept-route (either explicit or by default),
then the subroutine returns an effective true value to the then the subroutine returns an effective true value to the
calling policy. Similarly, a reject-route action returns calling policy. Similarly, a reject-route action returns
false. If the subroutine returns true, the calling policy false. If the subroutine returns true, the calling policy
continues to evaluate the remaining conditions (using a continues to evaluate the remaining conditions with the initial
modified route if the subroutine performed any changes to the data if route attribute values are modified.
route).
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
skipping to change at page 18, line 5 skipping to change at page 18, line 12
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-06-02" { revision "2020-07-05" {
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 18, line 44 skipping to change at page 19, line 4
reference reference
"RFC 2328 - OSPF Version 2"; "RFC 2328 - OSPF Version 2";
} }
identity isis-internal-metric { identity isis-internal-metric {
base metric-type; base metric-type;
description description
"Identity for the IS-IS internal metric types. It is only "Identity for the IS-IS internal metric types. It is only
applicable to IS-IS routes."; applicable to IS-IS routes.";
reference reference
"RFC 5302 - Domain-Wide Prefix Distributino with "RFC 5302 - Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity isis-external-metric { identity isis-external-metric {
base metric-type; base metric-type;
description description
"Identity for the IS-IS external metric types. It is only "Identity for the IS-IS external metric types. It is only
applicable to IS-IS routes."; applicable to IS-IS routes.";
reference reference
"RFC 5302 - Domain-Wide Prefix Distributino with "RFC 5302 - Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity import-level { identity route-level {
description description
"Base identity for route import level."; "Base identity for route import or export level.";
} }
identity ospf-normal { identity ospf-normal {
base import-level; base route-level;
description description
"Identity for OSPF importation into normal areas "Identity for OSPF importation into normal areas
It is only applicable to routes imported It is only applicable to routes imported
into the OSPF protocol."; into the OSPF protocol.";
reference reference
"RFC 2328 - OSPF Version 2"; "RFC 2328 - OSPF Version 2";
} }
identity ospf-nssa-only { identity ospf-nssa-only {
base import-level; base route-level;
description description
"Identity for the OSPF Not-So-Stubby Area (NSSA) area "Identity for the OSPF Not-So-Stubby Area (NSSA) area
importation. It is only applicable to routes imported importation. It is only applicable to routes imported
into the OSPF protocol."; into the OSPF protocol.";
reference reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
} }
identity ospf-normal-nssa { identity ospf-normal-nssa {
base import-level; base route-level;
description description
"Identity for OSPF importation into both normal and NSSA "Identity for OSPF importation into both normal and NSSA
areas, it is only applicable to routes imported into areas, it is only applicable to routes imported into
the OSPF protocol."; the OSPF protocol.";
reference reference
"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
} }
identity isis-level-1 { identity isis-level-1 {
base import-level; base route-level;
description description
"Identity for IS-IS Level 1 area importation. It is only "Identity for IS-IS Level 1 area importation. It is only
applicable to routes imported into the IS-IS protocol."; applicable to routes imported into the IS-IS protocol.";
reference reference
"RFC 5302 - Domain-Wide Prefix Distributino with "RFC 5302 - Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity isis-level-2 { identity isis-level-2 {
base import-level; base route-level;
description description
"Identity for IS-IS Level 2 area importation. It is only "Identity for IS-IS Level 2 area importation. It is only
applicable to routes imported into the IS-IS protocol."; applicable to routes imported into the IS-IS protocol.";
reference reference
"RFC 5302 - Domain-Wide Prefix Distributino with "RFC 5302 - Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity isis-level-1-2 { identity isis-level-1-2 {
base import-level; base route-level;
description description
"Identity for IS-IS Level 1 and Level 2 area importation. It "Identity for IS-IS Level 1 and Level 2 area importation. It
is only applicable to routes imported into the IS-IS is only applicable to routes imported into the IS-IS
protocol."; protocol.";
reference reference
"RFC 5302 - Domain-Wide Prefix Distributino with "RFC 5302 - Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity proto-route-type { identity proto-route-type {
description description
"Base identity for route type within a protocol."; "Base identity for route type within a protocol.";
} }
identity isis-level-1-type { identity isis-level-1-type {
base proto-route-type; base proto-route-type;
description description
"Identity for IS-IS Level 1 route type. It is only "Identity for IS-IS Level 1 route type. It is only
applicable to IS-IS routes."; applicable to IS-IS routes.";
reference reference
"RFC 5302 - Domain-Wide Prefix Distributino with "RFC 5302 - Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity isis-level-2-type { identity isis-level-2-type {
base proto-route-type; base proto-route-type;
description description
"Identity for IS-IS Level 2 route type. It is only "Identity for IS-IS Level 2 route type. It is only
applicable to IS-IS routes."; applicable to IS-IS routes.";
reference reference
"RFC 5302 - Domain-Wide Prefix Distributino with "RFC 5302 - Domain-Wide Prefix Distribution with
Two-Level IS-IS"; Two-Level IS-IS";
} }
identity ospf-internal-type { identity ospf-internal-type {
base proto-route-type; base proto-route-type;
description description
"Identity for OSPF intra-area or inter-area route type. "Identity for OSPF intra-area or inter-area route type.
It is only applicable to OSPF routes."; It is only applicable to OSPF routes.";
reference reference
"RFC 2328 - OSPF Version 2"; "RFC 2328 - OSPF Version 2";
} }
identity ospf-external-type { identity ospf-external-type {
base proto-route-type; base proto-route-type;
description description
"Identity for OSPF external type 1/2 route type. "Identity for OSPF external type 1/2 route type.
It is only applicable to OSPF routes."; It is only applicable to OSPF routes.";
reference reference
"RFC 2328 - OSPF Version 2"; "RFC 2328 - OSPF Version 2";
} }
identity ospf-external-t1 { identity ospf-external-t1-type {
base ospf-external-type; base ospf-external-type;
description description
"Identity for OSPF external type 1 route type. "Identity for OSPF external type 1 route type.
It is only applicable to OSPF routes."; It is only applicable to OSPF routes.";
reference reference
"RFC 2328 - OSPF Version 2"; "RFC 2328 - OSPF Version 2";
} }
identity ospf-external-t2-type { identity ospf-external-t2-type {
base ospf-external-type; base ospf-external-type;
skipping to change at page 21, line 44 skipping to change at page 22, line 4
"Identity for OSPF external type 2 route type. "Identity for OSPF external type 2 route type.
It is only applicable to OSPF routes."; It is only applicable to OSPF routes.";
reference reference
"RFC 2328 - OSPF Version 2"; "RFC 2328 - OSPF Version 2";
} }
identity ospf-nssa-type { identity ospf-nssa-type {
base proto-route-type; base proto-route-type;
description description
"Identity for OSPF NSSA type 1/2 route type. "Identity for OSPF NSSA type 1/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 ospf-nssa-t1 { identity ospf-nssa-t1-type {
base ospf-nssa-type; base ospf-nssa-type;
description description
"Identity for OSPF NSSA type 1 route type. "Identity for OSPF NSSA type 1 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 ospf-nssa-t2 { identity ospf-nssa-t2-type {
base ospf-nssa-type; base ospf-nssa-type;
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-local { identity bgp-internal {
base proto-route-type; base proto-route-type;
description description
"Identity for BGP local route type. "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 BGP external route type. "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 24, line 51 skipping to change at page 25, line 11
grouping prefix { grouping prefix {
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 prefix length with an intervening slash number followed by a prefix length with an intervening
character a delimiter. All members of the prefix set slash character as a delimiter. All members of the prefix
should be of the same address family as the prefix-set set should 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."; "Mask length range lower bound. It should not be less than
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 should not be less"
+ "than lower bound."; + "than lower bound.";
} }
description description
skipping to change at page 27, line 27 skipping to change at page 27, line 35
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";
leaf-list match-route-type { leaf-list match-route-type {
type identityref { type identityref {
base proto-route-type; base proto-route-type;
} }
description description
"Condition to check the protocol specific type "Condition to check the protocol-specific type
of route. This is normally used during route of route. This is normally used during route
importation to select routes or to set protocol importation to select routes or to set protocol
specific attributes based on the route type."; specific attributes based on the route type.";
} }
} }
grouping prefix-set-condition { grouping prefix-set-condition {
description description
"This grouping provides prefix-set conditions."; "This grouping provides prefix-set conditions.";
skipping to change at page 28, line 43 skipping to change at page 29, line 4
leaf tag-set { leaf tag-set {
type leafref { type leafref {
path "../../../../../../../defined-sets/tag-sets" + path "../../../../../../../defined-sets/tag-sets" +
"/tag-set/name"; "/tag-set/name";
require-instance true; require-instance true;
} }
description description
"References a defined tag set."; "References a defined tag set.";
} }
uses match-set-options-restricted-group; uses match-set-options-restricted-group;
description description
"Match a referenced tag set according to the logic defined "Match a referenced tag set according to the logic defined
in the match-options-set leaf."; in the match-options-set leaf.";
} }
} }
grouping apply-policy-import { grouping apply-policy-import {
description description
"Grouping for applying import policies."; "Grouping for applying import policies.";
leaf-list import-policy { leaf-list import-policy {
type leafref { type leafref {
path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +
"rt-pol:policy-definition/rt-pol:name"; "rt-pol:policy-definition/rt-pol:name";
require-instance true; require-instance true;
} }
ordered-by user; ordered-by user;
description description
"List of policy names in sequence to be applied on "List of policy names in sequence to be applied on
receiving a routing update in the current context, e.g., receiving redistributed routes from another routing protocol
or receiving a routing update in the current context, e.g.,
for the current peer group, neighbor, address family, for the current peer group, neighbor, address family,
etc."; etc.";
} }
leaf default-import-policy { leaf default-import-policy {
type default-policy-type; type default-policy-type;
default reject-route; default reject-route;
description description
"Explicitly set a default policy if no policy definition "Explicitly set a default policy if no policy definition
in the import policy chain is satisfied."; in the import policy chain is satisfied.";
skipping to change at page 29, line 42 skipping to change at page 30, line 4
leaf-list export-policy { leaf-list export-policy {
type leafref { type leafref {
path "/rt-pol:routing-policy/rt-pol:policy-definitions/" + path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +
"rt-pol:policy-definition/rt-pol:name"; "rt-pol:policy-definition/rt-pol:name";
require-instance true; require-instance true;
} }
ordered-by user; ordered-by user;
description description
"List of policy names in sequence to be applied on "List of policy names in sequence to be applied on
sending a routing update in the current context, e.g., redistributing routes from one routing protocol to another
or sending a routing update in the current context, e.g.,
for the current peer group, neighbor, address family, for the current peer group, neighbor, address family,
etc."; etc.";
} }
leaf default-export-policy { leaf default-export-policy {
type default-policy-type; type default-policy-type;
default reject-route; default reject-route;
description description
"Explicitly set a default policy if no policy definition "Explicitly set a default policy if no policy definition
in the export policy chain is satisfied."; in the export policy chain is satisfied.";
skipping to change at page 34, line 8 skipping to change at page 34, line 20
"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 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 and implementation dependent."; ambiguous.";
} }
leaf source-protocol { leaf source-protocol {
type identityref { type identityref {
base rt:control-plane-protocol; base rt:control-plane-protocol;
} }
description description
"Condition to check the protocol / method used to "Condition to check the protocol / method used to
install the route into the local routing table."; install the route into the local routing table.";
} }
skipping to change at page 35, line 14 skipping to change at page 35, line 26
leaf metric-type { leaf metric-type {
type identityref { type identityref {
base metric-type; base metric-type;
} }
description description
"Route metric type."; "Route metric type.";
} }
description description
"Set the metric type for the route."; "Set the metric type for the route.";
} }
container set-import-level { container set-route-level {
leaf import-level { leaf route-level {
type identityref { type identityref {
base import-level; base route-level;
} }
description description
"Route importation level."; "Route import or export level.";
} }
description description
"Set the import level for importation of "Set the level for importation or
routes."; exportation of routes.";
} }
leaf set-preference { leaf set-preference {
type uint16; type uint16;
description description
"Set the preference for the route."; "Set the preference for the route.";
} }
leaf set-tag { leaf set-tag {
type tag-type; type tag-type;
description description
"Set the tag for the route."; "Set the tag for the route.";
skipping to change at page 36, line 28 skipping to change at page 36, line 38
<prefix-set> <prefix-set>
<name>prefix-set-A</name> <name>prefix-set-A</name>
<mode>ipv4</mode> <mode>ipv4</mode>
<prefixes> <prefixes>
<prefix-list> <prefix-list>
<ip-prefix>192.0.2.0/24</ip-prefix> <ip-prefix>192.0.2.0/24</ip-prefix>
<mask-length-lower>24</mask-length-lower> <mask-length-lower>24</mask-length-lower>
<mask-length-upper>32</mask-length-upper> <mask-length-upper>32</mask-length-upper>
</prefix-list> </prefix-list>
<prefix-list> <prefix-list>
<ip-prefix>10.0.0.0/16</ip-prefix> <ip-prefix>198.51.100.0/24</ip-prefix>
<mask-length-lower>16</mask-length-lower> <mask-length-lower>24</mask-length-lower>
<mask-length-upper>32</mask-length-upper> <mask-length-upper>32</mask-length-upper>
</prefix-list> </prefix-list>
</prefixes> </prefixes>
</prefix-set> </prefix-set>
</prefix-sets> </prefix-sets>
<tag-sets> <tag-sets>
<tag-set> <tag-set>
<name>cust-tag1</name> <name>cust-tag1</name>
<tag-value>10</tag-value> <tag-value>10</tag-value>
</tag-set> </tag-set>
skipping to change at page 37, line 35 skipping to change at page 38, line 18
<policy-definitions> <policy-definitions>
<policy-definition> <policy-definition>
<name>export-all-OSPF-prefixes-into-ISIS-level-2</name> <name>export-all-OSPF-prefixes-into-ISIS-level-2</name>
<statements> <statements>
<statement> <statement>
<name>term-0</name> <name>term-0</name>
<conditions> <conditions>
<match-route-type>ospf-internal-type</match-route-type> <match-route-type>ospf-internal-type</match-route-type>
</conditions> </conditions>
<actions> <actions>
<set-import-level> <set-route-level>
<import-level>isis-level-2</import-level> <route-level>isis-level-2</route-level>
</set-import-level> </set-route-level>
<policy-result>accept-route</policy-result> <policy-result>accept-route</policy-result>
</actions> </actions>
</statement> </statement>
</statements> </statements>
</policy-definition> </policy-definition>
</policy-definitions> </policy-definitions>
</routing-policy> </routing-policy>
</config> </config>
12. References 12. References
skipping to change at page 40, line 20 skipping to change at page 40, line 43
Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
Sivaraj, "Sub-interface VLAN YANG Data Model", 2019, Sivaraj, "Sub-interface VLAN YANG Data Model", 2019,
<https://datatracker.ietf.org/doc/draft-ietf-netmod-sub- <https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-
intf-vlan-model/>. intf-vlan-model/>.
12.2. Informative references 12.2. Informative references
[I-D.ietf-idr-bgp-model] [I-D.ietf-idr-bgp-model]
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
YANG Model for Service Provider Networks", draft-ietf-idr- YANG Model for Service Provider Networks", draft-ietf-idr-
bgp-model-08 (work in progress), February 2020. bgp-model-09 (work in progress), June 2020.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The routing policy module defined in this draft is based on the The routing policy module defined in this document is based on the
OpenConfig route policy model. The authors would like to thank to OpenConfig route policy model. The authors would like to thank to
OpenConfig for their contributions, especially Anees Shaikh, Rob OpenConfig for their contributions, especially Anees Shaikh, Rob
Shakir, Kevin D'Souza, and Chris Chase. Shakir, Kevin D'Souza, and Chris Chase.
The authors are grateful for valuable contributions to this document The authors are grateful for valuable contributions to this document
and the associated models from: Ebben Aires, Luyuan Fang, Josh and the associated models from: Ebben Aires, Luyuan Fang, Josh
George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne,
Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and
John Heasley. John Heasley.
Thanks to Mahesh Jethanandani and Tom Petch for their review and Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom
comments. Petch for their reviews and comments.
Authors' Addresses Authors' Addresses
Yingzhen Qu Yingzhen Qu
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara CA 95050 Santa Clara CA 95050
USA USA
Email: yingzhen.qu@futurewei.com Email: yingzhen.qu@futurewei.com
 End of changes. 61 change blocks. 
81 lines changed or deleted 87 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/