< draft-ietf-rtgwg-policy-model-18.txt   draft-ietf-rtgwg-policy-model-19.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: January 14, 2021 Apstra Expires: February 18, 2021 Apstra
A. Lindem A. Lindem
Cisco Cisco
X. Liu X. Liu
Volta Networks Volta Networks
July 13, 2020 August 17, 2020
A YANG Data Model for Routing Policy Management A YANG Data Model for Routing Policy Management
draft-ietf-rtgwg-policy-model-18 draft-ietf-rtgwg-policy-model-19
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 January 14, 2021. This Internet-Draft will expire on February 18, 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 15, line 14 skipping to change at page 15, line 14
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 this document. elsewhere in this document.
10.1. Routing policy model 10.1. Routing policy model
<CODE BEGINS> file "ietf-routing-policy@2020-07-13.yang" <CODE BEGINS> file "ietf-routing-policy@2020-08-17.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 52 skipping to change at page 15, line 52
} }
import ietf-if-extensions { import ietf-if-extensions {
prefix "if-ext"; prefix "if-ext";
reference "RFC YYYY: Common Interface Extension YANG reference "RFC YYYY: Common Interface Extension YANG
Data Models. Please replace YYYY with Data Models. Please replace YYYY with
published RFC number for published RFC number for
draft-ietf-netmod-intf-ext-yang."; draft-ietf-netmod-intf-ext-yang.";
} }
import ietf-if-l3-vlan { import ietf-if-flexible-encapsulation {
prefix "if-l3-vlan"; prefix "if-flex";
reference "RFC ZZZZ: Sub-interface VLAN YANG Data Models. reference "RFC ZZZZ: Sub-interface VLAN YANG Data Models.
Please replace ZZZZ with published RFC number Please replace ZZZZ with published RFC number
for draft-ietf-netmod-sub-intf-vlan-model."; for draft-ietf-netmod-sub-intf-vlan-model.";
} }
organization organization
"IETF RTGWG - Routing Area Working Group"; "IETF RTGWG - Routing Area Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/rtgwg/> "WG Web: <http://tools.ietf.org/wg/rtgwg/>
WG List: <Email: rtgwg@ietf.org> WG List: <Email: rtgwg@ietf.org>
skipping to change at page 18, line 12 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-07-13" { revision "2020-08-17" {
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 27, line 11 skipping to change at page 27, line 11
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-l3-vlan:dot1q-vlan" + "/if-flex:flexible/if-flex:match"
+ "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id"; + "/if-flex:dot1q-vlan-tagged"
+ "/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";
skipping to change at page 36, line 18 skipping to change at page 36, line 18
description description
"Set the application tag for the route."; "Set the application tag for the route.";
} }
} }
} }
} }
} }
} }
} }
} }
<CODE ENDS>
CODE ENDS>
11. Policy examples 11. Policy examples
Below we show an example of XML-encoded configuration data using the Below we show an example of XML-encoded configuration data using the
routing policy and BGP models to illustrate both how policies are routing policy and BGP models to illustrate both how policies are
defined, and also how they can be applied. Note that the XML has defined, and also how they can be applied. Note that the XML has
been simplified for readability. been simplified for readability.
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<routing-policy <routing-policy
 End of changes. 9 change blocks. 
12 lines changed or deleted 12 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/