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 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"; } } } 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]