INTERNET-DRAFT Z. Li Intended status: Proposed Standard S. Zhuang G. Yan D. Eastlake Huawei Expires: May 7, 2019 November 8, 2018 YANG Data Model for Point-to-Point Tunnel Policy draft-li-rtgwg-tunnel-policy-yang-02 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/bgp:global/bgp:afi-safis/bgp:afi-safi/ bgp:l3vpn-ipv4-unicast: +--rw tunnelSelectorName? string augment /bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/ bgp:l3vpn-ipv6-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 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 ietf-bgp { prefix bgp; } 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/bgp:global/bgp:afi-safis/" +............ "bgp:afi-safi/bgp:l3vpn-ipv4-unicast" { leaf tunnelSelectorName { description "Specifies the name of a tunnel selector."; type "string"; } } augment "/bgp:bgp/bgp:global/bgp:afi-safis/" +............ "bgp:afi-safi/bgp:l3vpn-ipv6-unicast" { leaf tunnelSelectorName { description "Specifies the name of a tunnel selector."; L. Zhenbin, et al [Page 22] INTERNET-DRAFT YANG Model for Tunnel Policy type "string"; } } 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, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 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]