One document matched: draft-li-rtgwg-tunnel-policy-yang-00.txt
Network Working Group Z. Li
Internet-Draft S. Zhuang
Intended status: Informational G. Yan
Expires: September 9, 2015 Huawei Technologies
March 8, 2015
Yang Data Model for Tunnel Policy
draft-li-rtgwg-tunnel-policy-yang-00
Abstract
This document defines a YANG data model that can be used to configure
and manage tunnel policy.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 9, 2015.
Copyright Notice
Copyright (c) 2015 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
Li, et al. Expires September 9, 2015 [Page 1]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 2
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Tunnel Policy . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Selection Sequence . . . . . . . . . . . . . . . . . 3
3.1.2. Tunnel Binding . . . . . . . . . . . . . . . . . . . 3
3.2. Tunnel Selector for Routes . . . . . . . . . . . . . . . 4
3.3. Tunnel Selector for VPNs . . . . . . . . . . . . . . . . 5
4. Design of Data Model . . . . . . . . . . . . . . . . . . . . 5
4.1. Tunnel Policy YANG Model . . . . . . . . . . . . . . . . 5
4.2. Tunnel Selector YANG Model . . . . . . . . . . . . . . . 5
5. Tunnel Policy Yang Module . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
YANG [RFC6020] is a data definition language that was introduced 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 interface, such as CLI and
programmatic APIs.
This document defines a YANG data model that can be used to configure
and manage tunnel policy.
2. Definitions and Acronyms
JSON: JavaScript Object Notation
LSP: Label Switched Path
NETCONF: Network Configuration Protocol
RD: Route Distinguisher
Li, et al. Expires September 9, 2015 [Page 2]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
TNLM: Tunnel Management
VPN: Virtual Private Network
YANG: A data definition language for NETCONF
3. Introduction
3.1. Tunnel Policy
At present, multiple types of tunnels can be provided, such as LDP
LSPs, static LSPs and CRLSP. It is necessary to select different
tunnels for the VPN services according to the 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 that 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.
Li, et al. Expires September 9, 2015 [Page 3]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
In terms of tunnel selection among TE tunnels, tunnels are selected
according to the destination IP address and name of these TE tunnels.
The principles of tunnel selection are as follows:
1. If the tunnel policy designates no TE tunnel for the destination
IP address, the tunnels electing 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, the 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.
Li, et al. Expires September 9, 2015 [Page 4]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
b) Deny: In this mode, the actions defined by the apply clause 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 is out of the scope of the
document. They can refer to the Yang models defined in the document
for the 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.
+--rw tunnelPolicys
| +--rw tunnelPolicy* [tunnelPolicyName]
| +--rw tunnelPolicyName string
| +--rw description? string
| +--rw (tunnelPolicyMode)?
| +--:(SpecifyTunnelSelectionSequence)
| | +--rw tunnelTypeSequences
| | +--rw tunnelType* enumeration
| | +--rw loadBalanceNumber uint32
| +--:(BindApplicationToTunnel)
| +--rw bindingPolicies
| +--rw bindingPolicy* [nextHopAddress]
| +--rw nextHopAddress inet:ip-address
| +--rw tunnelInterface* leafref
| +--rw ignoreDestinationCheck? boolean
| +--rw downSwitch? 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 and satisfies
user requirements better.
Configuration of the tunnel selector and applying it to BGP VPNv4/
VPNv6 address-family can make the VPN service to select the specific
tunnel for VPN data transmission.
Li, et al. Expires September 9, 2015 [Page 5]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
+--rw tunnelSelector* [name]
+--rw name string
+--rw description? string
+--rw tunnelSelectorNodes
+--rw tunnelSelectorNode* [nodeSequence]
+--rw nodeSequence uint32
+--rw matchMode? enumeration
+--rw matchCondition
| +--rw matchIPv4NextHop
| | +--rw matchType enumeration
| | +--rw prefixName string
| | +--rw aclNameOrNum string
| +--rw matchIPv6NextHop
| | +--rw ipv6PrefixName string
| +--rw matchRdFilter
| +--rw rdIndex uint32
+--rw applyAction
+--rw tunnelPolicyName string
augment /bgp:bgp-router/bgp:vpnv4/bgp:unicast:
+--rw tunnelSelectorName? string
augment /bgp:bgp-router/bgp:vpnv6/bgp:unicast:
+--rw tunnelSelectorName? string
5. Tunnel Policy Yang Module
//Tunnel Management YANG MODEL
<CODE BEGINS> file "tunnel-management@2015-01-12.yang"
module tunnel-management {
namespace "urn:huawei:params:xml:ns:yang:tunnel-management";
// replace with IANA namespace when assigned
prefix "tlnm";
import bgp {
prefix bgp;
//draft-zhdankin-netmod-bgp-cfg
}
import ietf-interfaces {
prefix if;
//rfc7223-YANG Interface Management
}
import ietf-inet-types {
prefix inet;
//rfc6991-Common YANG Data Types
}
Li, et al. Expires September 9, 2015 [Page 6]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
description
"This YANG module defines the tunnel management configuration
data for tunnel management service.
";
revision 2015-01-12 {
description
"Initial revision.";
}
grouping matchMode {
leaf matchMode {
config "true";
type enumeration {
enum "permit" {
value "0";
description "permit:
Specifies the matching mode of the route-policy as permit.
In permit mode, a route matches all the if-match clauses,
the route matches the route-policy and the actions defined
by the apply clause are performed on the route. Otherwise,
the route continues to match the next entry.";
}
enum "deny" {
value "1";
description "deny:
Specifies the matching mode of the route-policy as deny. In
deny mode, if a route matches all the if-match clauses, the
route fails to match the route-policy and cannot match the
next node.";
}
}
}
}//End of grouping matchMode
/*
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.
*/
container tunnelPolicys {
Li, et al. Expires September 9, 2015 [Page 7]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
list tunnelPolicy {
min-elements "0";
max-elements "unbounded";
key "tunnelPolicyName";
leaf tunnelPolicyName {
description
"Specify tunnel policy name.";
config "true";
mandatory "true";
type "string";
}
leaf description {
description
"Tunnel policy description(no more than 80 characters).";
config "true";
mandatory "false";
type "string";
}
choice tunnelPolicyMode {
case SpecifyTunnelSelectionSequence { //Tunnel selection sequence
container tunnelTypeSequences {
description
"Specify Tunnel Selection Sequence.";
leaf-list tunnelType {
type enumeration {
enum "gre" {
value "0";
description "gre:
Specifies the GRE tunnel.";
}
enum "lsp" {
value "1";
description "lsp:
Specifies the LDP LSP, BGP LSP or static LSP.";
}
enum "cr-lsp" {
value "2";
description "cr-lsp:
Specifies the CR-LSP tunnel.";
}
//TBD
}
}
Li, et al. Expires September 9, 2015 [Page 8]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
leaf loadBalanceNumber {
description
"Specify tunnel load balance number.";
config "true";
mandatory "true";
type uint32 {
range "1..32";
}
}
}
}
case BindApplicationToTunnel { //Bind application to tunnel
container bindingPolicies {
list bindingPolicy {
key "nextHopAddress";
min-elements "0";
max-elements "unbounded";
leaf nextHopAddress {
description
"Specifies the destination address of the tunnel.";
type inet:ip-address;
}
leaf-list tunnelInterface {
description
"Specifies the interface number of the bound
tunnel interface.";
config "true";
type leafref {
path "/if:interfaces/if:interface/if:name";
}
}
leaf ignoreDestinationCheck {
description
"Specifies whether to ignore destination consistency
check. If this parameter is enabled, a tunnel
policy selects a TE tunnel for route iteration even
if the destination address of that TE tunnel is
different from the destination address specified in
the tunnel policy.";
config "true";
default "false";
type "boolean";
}
Li, et al. Expires September 9, 2015 [Page 9]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
leaf downSwitch {
description
"Indicates that the tunnel switchover is enabled.
After this parameter is configured, an available
tunnel, with the priority as LSP, CR-LSP, and then
GRE, is adopted when the bound TE tunnel fails.";
config "true";
default "false";
type "boolean";
}
}
}
}
}
}
}//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.
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 {
list tunnelSelector {
key "name";
min-elements "0";
max-elements "unbounded";
leaf name {
description
"Specifies the name of a tunnel selector.";
config "true";
Li, et al. Expires September 9, 2015 [Page 10]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
type "string";
}
leaf description {
config "true";
type "string";
}
container tunnelSelectorNodes {
list tunnelSelectorNode {
key "nodeSequence";
min-elements "0";
max-elements "unbounded";
leaf nodeSequence {
description
"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.";
config "true";
type uint32 {
range "0..65535";
}
}
uses matchMode;
container matchCondition {
container matchIPv4NextHop {
leaf matchType {
config "true";
mandatory "true";
type enumeration {
enum "matchNHopPF" {
value "0";
description "matchNHopPF:";
}
enum "matchNHopAcl" {
value "1";
description "matchNHopAcl:";
}
}
}
leaf prefixName {
description
Li, et al. Expires September 9, 2015 [Page 11]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
"Specifies the name of an IP address prefix list
that is used for route filtering.";
config "true";
mandatory "true";
type "string";
}
leaf aclNameOrNum {
description
"";
config "true";
mandatory "true";
type "string";
}
}//End of container matchIPv4NextHop
container matchIPv6NextHop {
leaf ipv6PrefixName {
description
"Specifies the name of an IPv6 address prefix
list.";
config "true";
mandatory "true";
type "string";
}
}//End of container matchIPv6NextHops
container matchRdFilter {
leaf rdIndex {
config "true";
mandatory "true";
type uint32 {
range "1..199";
}
}
}//End of container matchRdFilters
}//End of container matchCondition
container applyAction {
leaf tunnelPolicyName {
config "true";
mandatory "true";
type "string";
}
}//End of container applyAction
Li, et al. Expires September 9, 2015 [Page 12]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
}
}//End of container tunnelSelectorNodes
}
}//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.";
config "true";
type "string";
}
}
augment "/bgp:bgp-router/bgp:vpnv6/bgp:unicast" {
leaf tunnelSelectorName {
description
"Specifies the name of a tunnel selector.";
config "true";
type "string";
}
}
}
<CODE ENDS>
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
This document does not introduce any new security risk.
8. Acknowledgements
The authors would like to thank Xianping Zhang, Linghai Kong for
their contributions to this work.
Li, et al. Expires September 9, 2015 [Page 13]
Internet-Draft Yang Data Model for Tunnel Policy March 2015
9. References
[I-D.zhdankin-idr-bgp-cfg]
Alex, A., Patel, K., Clemm, A., Hares, S., Jethanandani,
M., and X. Liu, "Yang Data Model for BGP Protocol", draft-
zhdankin-idr-bgp-cfg-00 (work in progress), January 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
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
Li, et al. Expires September 9, 2015 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 09:57:22 |