YANG Data Model for Point-to-Point Tunnel Policy
draft-li-rtgwg-tunnel-policy-yang-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Zhenbin Li , Shunwan Zhuang , Gang Yan , Donald E. Eastlake 3rd | ||
| Last updated | 2018-11-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-rtgwg-tunnel-policy-yang-01
INTERNET-DRAFT Z. Li
Intended status: Proposed Standard S. Zhuang
G. Yan
D. Eastlake
Huawei
Expires: April 21, 2019 October 22, 2018
YANG Data Model for Point-to-Point Tunnel Policy
draft-li-rtgwg-tunnel-policy-yang-01
Abstract
This document defines a YANG data model that can be used to configure
and manage point-to-point tunnel policy.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the authors or the TRILL working group mailing list:
trill@ietf.org.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
L. Zhenbin, et al [Page 1]
INTERNET-DRAFT YANG Model for Tunnel Policy
Table of Contents
1. Introduction............................................3
2. Definitions and Acronyms................................3
3. Introduction............................................4
3.1 Tunnel Policy..........................................4
3.1.1 Selection Sequence...................................4
3.1.2 Tunnel Binding.......................................4
3.2 Tunnel Selector for Routes.............................5
3.3 Tunnel Selector for VPNs...............................6
4. Design of Data Model....................................7
4.1 Tunnel Policy YANG Model...............................7
4.2 Tunnel Selector YANG Model.............................7
5. Tunnel Policy Yang Module...............................9
6. IANA Considerations....................................24
7. Security Considerations................................24
Acknowledgements..........................................25
Informational References..................................26
Normative References......................................26
Authors' Addresses........................................27
L. Zhenbin, et al [Page 2]
INTERNET-DRAFT YANG Model for Tunnel Policy
1. Introduction
YANG [RFC6020] is a data definition language used to define the
contents of a conceptual data store that allows networked devices to
be managed using NETCONF [RFC6241]. YANG is proving relevant beyond
its initial confines, as bindings to other interfaces (e.g. ReST) and
encoding other than XML (e.g. JSON) are being defined. Furthermore,
YANG data models can be used as the basis of implementation for other
interfaces, such as CLI and programmatic APIs.
This document defines a YANG data model that can be used to configure
and manage point-to-point tunnel policy.
2. Definitions and Acronyms
JSON: JavaScript Object Notation
LSP: Label Switched Path
NETCONF: Network Configuration Protocol
RD: Route Distinguisher
TNLM: Tunnel Management
VPN: Virtual Private Network
YANG: A data definition language specified in [RFC6020] for use with
NETCONF [RFC6241]
L. Zhenbin, et al [Page 3]
INTERNET-DRAFT YANG Model for Tunnel Policy
3. Introduction
3.1 Tunnel Policy
Multiple types of tunnels can be used for VPN services, such as LDP
LSPs, static LSPs, and CRLSP. It is necessary to select different
tunnels for the VPN services to satisfy the required specific tunnel
policy.
A tunnel policy determines which type of tunnels can be selected.
Tunnel policies can be classified into two modes:
o Selection Sequence: The system selects a tunnel for the service
based on the tunnel type priorities defined in the tunnel policy.
o Tunnel binding: The system selects only a specified tunnel for the
service.
3.1.1 Selection Sequence
Selection sequence, as a tunnel policy mode, specifies the tunnel-
selecting sequence and the number of tunnels in the load balancing
mode. Selection Sequence is applicable to the tunnels including the
LSP, CR-LSP, etc. In selection-sequence mode, tunnels are selected
in sequence. If a tunnel listed earlier is Up and not bound, it is
selected regardless of whether other services have selected it; if a
tunnel is listed later, it is not selected except when load balancing
is required or the preceding tunnels are all in the Down state.
3.1.2 Tunnel Binding
Tunnel binding, as a tunnel policy mode, binds a tunnel with a
destination IP address. Tunnel binding is only applicable to TE
tunnels.
In tunnel binding mode, multiple TE tunnels can be specified to
perform load balancing for the same destination IP address.
Moreover, the down-switch attribute can be specified to ensure that
other tunnels can be selected when all the designated tunnels are
unavailable, which keeps the traffic uninterrupted to the maximum
extent.
In terms of tunnel selection among TE tunnels, tunnels are selected
according to the destination IP address and name of these TE tunnels.
L. Zhenbin, et al [Page 4]
INTERNET-DRAFT YANG Model for Tunnel Policy
The principles of tunnel selection are as follows:
1. If the tunnel policy designates no TE tunnel for the destination
IP address, the tunnels selection sequence is LSP, CR-LSP.
2. If the tunnel policy designates a TE tunnel for the destination
IP address, and the designated TE tunnels is available, that TE
tunnel is selected.
3. If the tunnel policy designates a TE tunnel for the destination
IP address, but the designated TE tunnels is unavailable, the
tunnel-selecting result is determined by the down-switch
attribute. If the down-switch attribute is configured, another
available tunnel is selected based on the sequence of LSP, CR-
LSP, and GRE tunnel; if the down-switch attribute is not
configured, no tunnel is selected.
3.2 Tunnel Selector for Routes
A tunnel policy selector defines certain matching rules and
associates the routes whose attributes matching the rules with
specific tunnels. This facilitates flexible tunneling and better
satisfies user requirements.
A tunnel policy selector consists of one more policy nodes and the
relationship between these policy nodes is "OR". The system checks
the policy nodes based on index numbers. If a route matches a policy
node in the tunnel policy, the route does not continue to match the
next policy node. Each policy node comprises a set of if-match and
apply clauses:
1. The if-match clauses define the matching rules that are used to
match certain route attributes such as the next hop and RD. The
relationship between the if-match clauses of a node is "AND". A
route matches a node only when the route meets all the matching
rules specified by the if-match clauses of the node.
2. The apply clause specifies actions. When a route matches a
node, the apply clause selects a tunnel policy for the route.
The matching modes of a node are as follows:
a) Permit: If a route matches all the if-match clauses of a
node, the route matches the node and the actions defined by
the apply clause are performed on the route. If a route does
not match one if-match clause of a node, the route continues
to match the next node.
b) Deny: In this mode, the actions defined by the apply clause
L. Zhenbin, et al [Page 5]
INTERNET-DRAFT YANG Model for Tunnel Policy
are not performed. If a route matches all the if-match
clauses of a node, the route is denied and does not match the
next node.
3.3 Tunnel Selector for VPNs
Selection of the tunnel for the VPN services includes the matching
rules and the applied tunnel policy. The data model is defined in
the drafts of VPN Yang models which are out of the scope of this
document. They can refer to the Yang models defined in the document
for tunnel policy.
L. Zhenbin, et al [Page 6]
INTERNET-DRAFT YANG Model for Tunnel Policy
4. Design of Data Model
4.1 Tunnel Policy YANG Model
A tunnel policy determines which type of tunnels can be selected by
an application module. The configuration of tunnel policy includes
defining the tunnel selection sequence mode and the binding mode for
the tunnel selection. The nonexistentCheckFlag controls whether the
system allows a nonexistent tunnel policy to be specified in a
command.
+--rw tnlmGlobal
| +--rw nonexistentCheckFlag? boolean
+--rw tunnelPolicys
| +--rw tunnelPolicy* [tnlPolicyName]
| +--rw tnlPolicyName string
| +--ro tnlPolicyExist? tnlPolicyExist
| +--ro tpSubCount? uint32
| +--rw description? string
| +--rw tnlPolicyType? tnlmbaseTnlPolicyType
| +--rw tpNexthops
| | +--rw tpNexthop* [nexthopIPaddr]
| | +--rw nexthopIPaddr inet:ipv4-address-no-zone
| | +--rw downSwitch? boolean
| | +--rw ignoreDestCheck? boolean
| | +--rw isIncludeLdp? boolean
| | +--rw tpTunnels
| | +--rw tpTunnel* [tunnelName]
| | +--rw tunnelName string
| +--rw tnlSelSeqs
| +--rw tnlSelSeq!
| +--rw loadBalanceNum? uint32
| +--rw selTnlType1? tnlmbaseSelTnlType
| +--rw selTnlType2? tnlmbaseSelTnlType
| +--rw selTnlType3? tnlmbaseSelTnlType
| +--rw selTnlType4? tnlmbaseSelTnlType
| +--rw selTnlType5? tnlmbaseSelTnlType
| +--rw selTnlType6? tnlmbaseSelTnlType
| +--rw unmix? boolean
4.2 Tunnel Selector YANG Model
A tunnel policy selector defines certain matching rules and
associates the routes whose attributes matching the rules with
specific tunnels. This facilitates flexible tunneling satisfying
user requirements.
L. Zhenbin, et al [Page 7]
INTERNET-DRAFT YANG Model for Tunnel Policy
Configuration of the tunnel selector and applying it to the BGP
VPNv4/VPNv6 address-family can make the VPN service select the
specific tunnel for VPN data transmission.
+--rw tunnelSelectors
+--rw tunnelSelector* [name]
+--rw name string
+--rw tunnelSelectorNodes
+--rw tunnelSelectorNode* [nodeSequence]
+--rw nodeSequence uint32
+--rw matchMode rtpMatchMode
+--rw matchCondition
| +--rw matchDestPrefixFilters
| | +--rw matchDestPrefixFilter!
| | +--rw prefixName? string
| +--rw matchIPv4NextHops
| | +--rw matchIPv4NextHop!
| | +--rw matchType? rtpTnlSelMchType
| | +--rw prefixName? string
| | +--rw aclNameOrNum? string
| +--rw matchIPv6NextHops
| | +--rw matchIPv6NextHop!
| | +--rw ipv6PrefixName? string
| +--rw matchCommunityFilters
| | +--rw matchCommunityFilter* [cmntyNameOrNum]
| | +--rw cmntyNameOrNum string
| | +--rw wholeMatch? boolean
| | +--rw sortMatch? boolean
| +--rw matchRdFilters
| +--rw matchRdFilter!
| +--rw rdIndex? uint32
+--rw applyAction
+--rw applyTnlPolicys
+--rw applyTnlPolicy!
+--rw tnlPolicyName? string
augment /bgp:bgp-router/bgp:vpnv4/bgp:unicast:
+--rw tunnelSelectorName? string
augment /bgp:bgp-router/bgp:vpnv6/bgp:unicast:
+--rw tunnelSelectorName? string
L. Zhenbin, et al [Page 8]
INTERNET-DRAFT YANG Model for Tunnel Policy
5. Tunnel Policy Yang Module
//Tunnel Policy YANG MODEL
<CODE BEGINS> file " tunnel-policy@2018-09-15.yang "
module tunnel-policy {
namespace "urn:huawei:params:xml:ns:yang:tunnel-policy";
// replace with IANA namespace when assigned
prefix tnlp;
import bgp {
prefix bgp;
//draft-ietf-idr-bgp-model
}
import ietf-inet-types {
prefix inet;
//rfc6991-Common YANG Data Types
}
organization
"Huawei Technologies Co., Ltd.";
contact
"Huawei Industrial Base Bantian, Longgang Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com Email: support@huawei.com";
description
"This YANG module defines the tunnel policy configuration
data for tunnel policy service.
VPN data needs to be carried by tunnels. By default, the
system selects LSPs to carry VPN services without performing
load balancing. If this cannot meet the requirements of VPN
services, a tunnel policy needs to be used. The tunnel policy
may be a tunnel type prioritizing policy or a tunnel binding
policy. Determine which type of tunnel policy to use based
on your actual requirements:
* A tunnel type prioritizing policy can change the tunnel
type selected for VPN services and allow load balancing
among tunnels.
* A tunnel binding policy can bind a VPN service to
specified MPLS TE tunnels to provide QoS guarantee for
the VPN service.
Terms and Acronyms
... ";
revision 2018-09-15 {
description
"Initial revision.";
L. Zhenbin, et al [Page 9]
INTERNET-DRAFT YANG Model for Tunnel Policy
}
typedef tnlmbaseTnlPolicyType {
type enumeration {
enum "invalid" {
description
"Tunnel policy with null configurations.";
}
enum "tnlSelectSeq" {
description
"Tunnel select-seq policy. This policy allows you
to specify the sequence in which different types
of tunnels are selected and the number of tunnels
for load balancing.";
}
enum "tnlBinding" {
description
"Tunnel binding policy. This policy allows you to
specify the next hop to be bound to a TE tunnel.
After a TE tunnel is bound to a destination
address, VPN traffic destined for that destination
address will be transmitted over the TE tunnel.";
}
}
description
"tunnel policy type";
}
typedef tnlmbaseSelTnlType {
type enumeration {
enum "invaild" {
description
"Search for invalid tunnels.";
}
enum "lsp" {
description
"Search for LDP LSPs.";
}
enum "cr-lsp" {
description
"Search for CR-LSPs.";
}
enum "gre" {
description
"Search for GREs.";
}
enum "ldp" {
description
"Search for LDP LSPs.";
}
enum "bgp" {
L. Zhenbin, et al [Page 10]
INTERNET-DRAFT YANG Model for Tunnel Policy
description
"Search for BGP LSPs.";
}
enum "srbe-lsp" {
description
"Search for SR-LSPs.";
}
enum "sr-te" {
description
"Search for SR-TE.";
}
enum "te" {
description
"Search for TE.";
}
}
description
"tunnel select type";
}
typedef tnlPolicyExist {
type enumeration {
enum "true" {
description
"The tunnel policy has been configured.";
}
enum "false" {
description
"The tunnel policy has not been configured.";
}
}
description
"tunnel policy state";
}
typedef rtpMatchMode {
type enumeration {
enum "permit" {
description
"Matching mode of filters.";
}
enum "deny" {
description
"Matching mode of filters.";
}
}
description
"match mode";
}
L. Zhenbin, et al [Page 11]
INTERNET-DRAFT YANG Model for Tunnel Policy
typedef rtpTnlSelMchType {
type enumeration {
enum "matchNHopPF" {
description
"Match IPv4 next hops by an IPv4 prefix.";
}
enum "matchNHopAcl" {
description
"Match IPv4 next hops by an ACL.";
}
}
description
"tunnel selector type";
}
/*
A tunnel policy determines which type of tunnels can be
selected by an application module.
Tunnel policies can be classified into two modes:
Select-seq: The system selects a tunnel for an application
program based on the tunnel type priorities defined in the
tunnel policy.
Tunnel binding: The system selects only a specified tunnel
for an application program.
The two modes are mutually exclusive.
Configuration example:
#
tunnel-policy policy1
description policy1
tunnel binding destination 1.1.1.1 te Tunnel0/0/0 down-switch
#
tunnel-policy policy2
tunnel select-seq cr-lsp gre lsp load-balance-number 2
#
tunnel-policy policy3
tunnel binding destination 1.1.1.1 te Tunnel0/0/0 down-switch
tunnel binding destination 3.3.3.3 te Tunnel0/0/0
ignore-destination-check
tunnel binding destination 5.5.5.5 te Tunnel0/0/0
#
*/
container tnlmGlobal {
description
"Global parameters for tunnel policy.";
leaf nonexistentCheckFlag {
type boolean;
L. Zhenbin, et al [Page 12]
INTERNET-DRAFT YANG Model for Tunnel Policy
default "true";
description
"Nonexistent config check flag of tunnel policy.
By default, if you specify a nonexistent tunnel policy
in a command, the command does not take effect. To enable
the system to allow a nonexistent tunnel policy to be
specified in a command, run the tunnel-policy
nonexistent-config-check disable command.";
}
}
container tunnelPolicys {
description
"List of global tunnel policy configurations. A tunnel
policy can be used to specify a rule for selecting
tunnels.";
list tunnelPolicy {
key "tnlPolicyName";
description
"A policy for selecting tunnels to carry services. The
tunnel management module searches for and returns the
required tunnels based on the tunnel policy. By default,
no tunnel policy is configured, the system selects an
available tunnel in the order of conventional LSPs,
CR-LSPs, and Local_IFNET LSPs, and load balancing is
not performed.";
leaf tnlPolicyName {
type string {
length "1..39";
}
description
"Name of a tunnel policy. The value is a string of 1 to
39 case-sensitive characters, spaces not supported.";
}
leaf tnlPolicyExist {
type tnlPolicyExist;
config false;
description
"Whether a tunnel policy has been configured.";
}
leaf tpSubCount {
type uint32;
config false;
description
"Number of times a tunnel policy is referenced.";
}
leaf description {
L. Zhenbin, et al [Page 13]
INTERNET-DRAFT YANG Model for Tunnel Policy
type string {
length "1..80";
}
description
"Description of a tunnel policy.";
}
leaf tnlPolicyType {
type tnlmbaseTnlPolicyType;
default "invalid";
description
"Tunnel policy type. The available options are sel-seq,
binding, and invalid. A tunnel policy can be configured
with only one policy type.";
}
container tpNexthops {
must "not(../tnlPolicyType='tnlBinding') or "
+ "(../tnlPolicyType='tnlBinding' "
+ "and count(tpNexthop)>=1)";
description
"List of tunnel binding configurations.";
list tpNexthop {
when "not(../../tnlPolicyType='tnlSelectSeq') or "
+ "../../tnlPolicyType='tnlBinding'";
key "nexthopIPaddr";
max-elements "65535";
description
"Rule for binding a TE tunnel to a destination address,
so that the VPN traffic destined for that destination
address can be transmitted over the TE tunnel.";
leaf nexthopIPaddr {
type inet:ipv4-address-no-zone;
description
"Destination IP address to be bound to a tunnel.";
}
leaf downSwitch {
type boolean;
default "false";
description
"Enable tunnel switching. After this option is
selected, if the bound TE tunnel is unavailable,
the system will select an available tunnel in
the order of conventional LSPs, CR-LSPs, and
Local_IFNET tunnels.";
}
leaf ignoreDestCheck {
type boolean;
default "false";
description
"Do not check whether the destination address of the
L. Zhenbin, et al [Page 14]
INTERNET-DRAFT YANG Model for Tunnel Policy
TE tunnel matches the destination address specified
in the tunnel policy.";
}
leaf isIncludeLdp {
type boolean;
must "(../isIncludeLdp='true' and not "
+ "(../downSwitch='true')) or "
+ "../isIncludeLdp='false'";
default "false";
description
"Is loadbalance with LDP";
}
container tpTunnels {
description
"List of tunnels available for an application.";
list tpTunnel {
key "tunnelName";
min-elements "1";
max-elements "16";
description
"Tunnel.";
leaf tunnelName {
type string {
length "1..47";
}
description
"Name of the specified tunnel.";
}
}
}
}
}
container tnlSelSeqs {
when "not(../tnlPolicyType='invalid' or "
+ "../tnlPolicyType='tnlBinding')";
must "not(../tnlPolicyType='tnlSelectSeq') or "
+ "(../tnlPolicyType='tnlSelectSeq' and "
+ "count(tnlSelSeq)>=1)";
description
"Sequence in which different types of tunnels are
selected.
If the value is INVALID, no tunnel type has been
configured.";
container tnlSelSeq {
when "not(../../tnlPolicyType='invalid' or "
+ "../../tnlPolicyType='tnlBinding') or "
+ "../../tnlPolicyType='tnlSelectSeq'";
presence "create tnlSelSeq";
description
"Sequence in which different types of tunnels are
L. Zhenbin, et al [Page 15]
INTERNET-DRAFT YANG Model for Tunnel Policy
selected. If the value is INVALID, no tunnel type
has been configured.";
leaf loadBalanceNum {
type uint32 {
range "1..64";
}
default "1";
description
"Sequence in which different types of tunnels are
selected. The available tunnel types are CR-LSP,
and LSP. LSP tunnels refer to LDP LSP tunnels
here.";
}
leaf selTnlType1 {
type tnlmbaseSelTnlType;
default "invaild";
description
"Sequence in which different types of tunnels are
selected. If the value is INVALID, no tunnel type
has been configured.";
}
leaf selTnlType2 {
when "not(../selTnlType1='invaild' and "
+ "../../../tnlPolicyType='tnlSelectSeq' or "
+ "../selTnlType1='invaild')";
type tnlmbaseSelTnlType;
default "invaild";
description
"Sequence in which different types of tunnels are
selected. If the value is INVALID, no tunnel type
has been configured.";
}
leaf selTnlType3 {
when "not(../selTnlType1='invaild' or "
+ "../selTnlType2='invaild')";
type tnlmbaseSelTnlType;
default "invaild";
description
"Sequence in which different types of tunnels are
selected. If the value is INVALID, no tunnel type
has been configured.";
}
leaf selTnlType4 {
when "not(../selTnlType1='invaild' or "
+ "../selTnlType2='invaild' or "
+ "../selTnlType3='invaild')";
type tnlmbaseSelTnlType;
default "invaild";
description
"Sequence in which different types of tunnels are
L. Zhenbin, et al [Page 16]
INTERNET-DRAFT YANG Model for Tunnel Policy
selected. If the value is INVALID, no tunnel type
has been configured.";
}
leaf selTnlType5 {
when "not(../selTnlType1='invaild' or "
+ "../selTnlType2='invaild' or "
+ "../selTnlType3='invaild' or "
+ "../selTnlType4='invaild')";
type tnlmbaseSelTnlType;
default "invaild";
description
"Sequence in which different types of tunnels are
selected. If the value is INVALID, no tunnel type
has been configured.";
}
leaf selTnlType6 {
when "not(../selTnlType1='invaild' or "
+ "../selTnlType2='invaild' or "
+ "../selTnlType3='invaild' or "
+ "../selTnlType4='invaild' or "
+ "../selTnlType5='invaild')";
type tnlmbaseSelTnlType;
default "invaild";
description
"Sequence in which different types of tunnels are
selected. If the value is INVALID, no tunnel type
has been configured.";
}
leaf unmix {
type boolean;
default "false";
description
"unmix flag.";
}
}
}
}
}//End of container tunnelPolicys
/*
The tunnel selector is specific to BGP/MPLS IP VPN services
(a type of VPN service), selecting a tunnel policy for
VPNv4/VPNv6 routes on the backbone network.
A tunnel selector selects tunnel policies for routes after
filtering routes based on some route attributes such as the
route distinguisher (RD) and next hop. This makes tunnel
selection more flexible.
L. Zhenbin, et al [Page 17]
INTERNET-DRAFT YANG Model for Tunnel Policy
A tunnel selector is often used on the autonomous system
boundary router (ASBR) in inter-AS VPN Option B or the
superstratum provider edge (SPE) in hierarchy of VPN (HoVPN).
*/
container tunnelSelectors {
description
"List of tunnel selectors.";
list tunnelSelector {
key "name";
max-elements "65535";
description
"Tunnel selector. Usually used in BGP VPN Option B or
BGP VPN Option C, tunnel selector selects a proper
tunnel policy for routes.";
leaf name {
type string {
length "1..40";
}
description
"Name of a tunnel selector. The name is a string of
1 to 40 case-sensitive characters without spaces.";
}
container tunnelSelectorNodes {
description
"List of tunnel selector nodes.";
list tunnelSelectorNode {
key "nodeSequence";
min-elements "1";
max-elements "65535";
leaf nodeSequence {
type uint32 {
range "0..65535";
}
description
"Sequence number of a node.
Specifies the index of a node of the tunnel
selector.
When a route-policy is used to filter a route,
the route first matches the node with the
smallest node value.";
}
leaf matchMode {
type rtpMatchMode;
mandatory true;
description
"Matching mode of nodes.";
}
L. Zhenbin, et al [Page 18]
INTERNET-DRAFT YANG Model for Tunnel Policy
container matchCondition {
description
"Match Type List";
container matchDestPrefixFilters {
description
"Match IPv4 destination addresses by the prefix
filter. The configurations of matching IPv4
destination addresses by the prefix filter are
mutually exclusive with the configurations of
matching IPv4 destination addresses based on
ACL rules.";
container matchDestPrefixFilter {
presence "create matchDestPrefixFilter";
description
"Match an IPv4 destination address by the prefix
filter.";
leaf prefixName {
type "string";
description
"Name of the specified prefix filter when IPv4
destination addresses are matched.";
}
}
} // End of matchDestPrefixFilters
container matchIPv4NextHops {
description
"Match IPv4 next hops by the prefix filter or ACL
filter. The configurations of matching IPv4 next
hops by the prefix filter are mutually exclusive
with the configurations of matching IPv4 next
hops by the ACL filter.";
container matchIPv4NextHop {
presence "create matchIPv4NextHop";
description
"Match an IPv4 next hop by the prefix or ACL.";
leaf matchType {
type rtpTnlSelMchType;
description
"Match type. IPv4 next hops are matched with
either the prefix or ACL.";
}
leaf prefixName {
when "not(../matchType='matchNHopAcl' or "
+ "not(../matchType)) or "
+ "../matchType='matchNHopPF'";
type "string";
L. Zhenbin, et al [Page 19]
INTERNET-DRAFT YANG Model for Tunnel Policy
description
"Name of the specified prefix when IPv4 next hops
are matched.";
}
leaf aclNameOrNum {
when "not(../matchType='matchNHopPF' or "
+ "not(../matchType)) or "
+ "../matchType='matchNHopAcl'";
type string {
length "1..32";
}
description
"Name of the specified ACL when next hops are
matched, which can be a value ranging from
2000 to 2999 or a string beginning with a-z
or A-Z.";
}
}
} //End of container matchIPv4NextHops
container matchIPv6NextHops {
description
"Match IPv6 next hops by the IPv6 prefix filter.";
container matchIPv6NextHop {
presence "create matchIPv6NextHop";
description
"Match an IPv6 next hop by the IPv6 prefix
filter.";
leaf ipv6PrefixName {
type "string";
description
"Name of the specified prefix filter when IPv6
next hops are matched.";
}
}
} //End of container matchIPv6NextHops
container matchCommunityFilters {
description
"Match community attribute filters.";
list matchCommunityFilter {
key "cmntyNameOrNum";
max-elements "32";
description
"Match a community attribute filter.";
leaf cmntyNameOrNum {
type string {
length "1..51";
pattern '((0*[1-9][0-9]?)|(0*1[0-9][0-9])|'
L. Zhenbin, et al [Page 20]
INTERNET-DRAFT YANG Model for Tunnel Policy
+ '([^?-9][^?0,50})|'
+ '([][^?^?-9][^?)';
}
description
"Name or index of a community attribute filter.
It can be a numeral or a string. The ID of a
basic community attribute filter is an integer
ranging from 1 to 99; the ID of an advanced
community attribute filter is an integer
ranging from 100 to 199. The name of a community
attribute filter is a string of 1 to 51
characters. The string cannot contain only
digits.";
}
leaf wholeMatch {
type boolean;
default "false";
description
"All the communities are matched. It is valid to
only basic community attribute filters.";
}
leaf sortMatch {
type boolean;
default "false";
description
"Match all community attributes in sequence.It
is valid to only Advanced community attribute
filters.";
}
}
} //End of container matchCommunityFilters
container matchRdFilters {
description
"Match RD filters.";
container matchRdFilter {
presence "create matchRdFilter";
description
"Match an RD filter.";
leaf rdIndex {
type uint32 {
range "1..1024";
}
description
"Index of an RD filter.";
}
}
} //End of container matchRdFilters
}//End of container matchCondition
L. Zhenbin, et al [Page 21]
INTERNET-DRAFT YANG Model for Tunnel Policy
container applyAction {
description
"Set Type List";
container applyTnlPolicys {
description
"Set tunnel policies.";
container applyTnlPolicy {
presence "create applyTnlPolicy";
description
"Set a tunnel policy.";
leaf tnlPolicyName {
type string {
length "1..39";
}
description
"Name of a tunnel policy. The name is a
string of 1 to 39 case-sensitive characters,
spaces not supported.";
}
}
}
} //End of container applyAction
}
} //End of container tunnelSelectorNodes
} //End of list tunnelSelector
} //End of container tunnelSelectors
/*
* augment some bgp vpn functions in bgp module.
*/
augment "/bgp:bgp-router/bgp:vpnv4/bgp:unicast" {
leaf tunnelSelectorName {
description
"Specifies the name of a tunnel selector.";
type "string";
}
}
augment "/bgp:bgp-router/bgp:vpnv6/bgp:unicast" {
leaf tunnelSelectorName {
description
"Specifies the name of a tunnel selector.";
type "string";
}
L. Zhenbin, et al [Page 22]
INTERNET-DRAFT YANG Model for Tunnel Policy
}
<CODE ENDS>
L. Zhenbin, et al [Page 23]
INTERNET-DRAFT YANG Model for Tunnel Policy
6. IANA Considerations
This document requires no IANA actions.
7. Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) to
these data nodes without proper protection can have a negative effect
on network operations. These are the subtrees and data nodes and
their sensitivity/vulnerability:
tbd
Unauthorized access to any data node of these subtrees can adversely
affect ... tbd ...
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
tbd
Unauthorized access to any data node of these subtrees can disclose
... tbd ...
L. Zhenbin, et al [Page 24]
INTERNET-DRAFT YANG Model for Tunnel Policy
Acknowledgements
The authors would like to thank the following for their contributions
to this work:
Xianping Zhang, Linghai Kong, Xiangfeng Ding, Haibo Wang, and
Walker Zheng
L. Zhenbin, et al [Page 25]
INTERNET-DRAFT YANG Model for Tunnel Policy
Informational References
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access
Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341,
March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Normative References
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
L. Zhenbin, et al [Page 26]
INTERNET-DRAFT YANG Model for Tunnel Policy
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 China
Email: lizhenbin@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 China
Email: zhuangshunwan@huawei.com
Gang Yan
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 China
Email: yangang@huawei.com
Donald Eastlake, 3rd
Huawei Technologies
1424 Pro Shop Court
Davenport, FL 33896 USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
L. Zhenbin, et al [Page 27]
INTERNET-DRAFT YANG Model for Tunnel Policy
Copyright and IPR Provisions
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
L. Zhenbin, et al [Page 28]