idnits 2.17.1 draft-li-rtgwg-tunnel-policy-yang-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 231 has weird spacing: '...nelName str...' == Line 275 has weird spacing: '...meOrNum str...' == Line 365 has weird spacing: '...address will ...' == Line 507 has weird spacing: '...icy can be us...' -- The document date (November 8, 2018) is 1995 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Z. Li 2 Intended status: Proposed Standard S. Zhuang 3 G. Yan 4 D. Eastlake 5 Huawei 6 Expires: May 7, 2019 November 8, 2018 8 YANG Data Model for Point-to-Point Tunnel Policy 9 draft-li-rtgwg-tunnel-policy-yang-02 11 Abstract 13 This document defines a YANG data model that can be used to configure 14 and manage point-to-point tunnel policy. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Distribution of this document is unlimited. Comments should be sent 22 to the authors or the TRILL working group mailing list: 23 trill@ietf.org. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 37 Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction............................................3 43 2. Definitions and Acronyms................................3 45 3. Introduction............................................4 46 3.1 Tunnel Policy..........................................4 47 3.1.1 Selection Sequence...................................4 48 3.1.2 Tunnel Binding.......................................4 49 3.2 Tunnel Selector for Routes.............................5 50 3.3 Tunnel Selector for VPNs...............................6 52 4. Design of Data Model....................................7 53 4.1 Tunnel Policy YANG Model...............................7 54 4.2 Tunnel Selector YANG Model.............................7 56 5. Tunnel Policy Yang Module...............................9 58 6. IANA Considerations....................................24 59 7. Security Considerations................................24 61 Acknowledgements..........................................25 63 Informational References..................................26 64 Normative References......................................26 66 Authors' Addresses........................................27 68 1. Introduction 70 YANG [RFC6020] is a data definition language used to define the 71 contents of a conceptual data store that allows networked devices to 72 be managed using NETCONF [RFC6241]. YANG is proving relevant beyond 73 its initial confines, as bindings to other interfaces (e.g. ReST) and 74 encoding other than XML (e.g. JSON) are being defined. Furthermore, 75 YANG data models can be used as the basis of implementation for other 76 interfaces, such as CLI and programmatic APIs. 78 This document defines a YANG data model that can be used to configure 79 and manage point-to-point tunnel policy. 81 2. Definitions and Acronyms 83 JSON: JavaScript Object Notation 85 LSP: Label Switched Path 87 NETCONF: Network Configuration Protocol 89 RD: Route Distinguisher 91 TNLM: Tunnel Management 93 VPN: Virtual Private Network 95 YANG: A data definition language specified in [RFC6020] for use with 96 NETCONF [RFC6241] 98 3. Introduction 100 3.1 Tunnel Policy 102 Multiple types of tunnels can be used for VPN services, such as LDP 103 LSPs, static LSPs, and CRLSP. It is necessary to select different 104 tunnels for the VPN services to satisfy the required specific tunnel 105 policy. 107 A tunnel policy determines which type of tunnels can be selected. 108 Tunnel policies can be classified into two modes: 110 o Selection Sequence: The system selects a tunnel for the service 111 based on the tunnel type priorities defined in the tunnel policy. 113 o Tunnel binding: The system selects only a specified tunnel for the 114 service. 116 3.1.1 Selection Sequence 118 Selection sequence, as a tunnel policy mode, specifies the tunnel- 119 selecting sequence and the number of tunnels in the load balancing 120 mode. Selection Sequence is applicable to the tunnels including the 121 LSP, CR-LSP, etc. In selection-sequence mode, tunnels are selected 122 in sequence. If a tunnel listed earlier is Up and not bound, it is 123 selected regardless of whether other services have selected it; if a 124 tunnel is listed later, it is not selected except when load balancing 125 is required or the preceding tunnels are all in the Down state. 127 3.1.2 Tunnel Binding 129 Tunnel binding, as a tunnel policy mode, binds a tunnel with a 130 destination IP address. Tunnel binding is only applicable to TE 131 tunnels. 133 In tunnel binding mode, multiple TE tunnels can be specified to 134 perform load balancing for the same destination IP address. 135 Moreover, the down-switch attribute can be specified to ensure that 136 other tunnels can be selected when all the designated tunnels are 137 unavailable, which keeps the traffic uninterrupted to the maximum 138 extent. 140 In terms of tunnel selection among TE tunnels, tunnels are selected 141 according to the destination IP address and name of these TE tunnels. 143 The principles of tunnel selection are as follows: 145 1. If the tunnel policy designates no TE tunnel for the destination 146 IP address, the tunnels selection sequence is LSP, CR-LSP. 148 2. If the tunnel policy designates a TE tunnel for the destination 149 IP address, and the designated TE tunnels is available, that TE 150 tunnel is selected. 152 3. If the tunnel policy designates a TE tunnel for the destination 153 IP address, but the designated TE tunnels is unavailable, the 154 tunnel-selecting result is determined by the down-switch 155 attribute. If the down-switch attribute is configured, another 156 available tunnel is selected based on the sequence of LSP, CR- 157 LSP, and GRE tunnel; if the down-switch attribute is not 158 configured, no tunnel is selected. 160 3.2 Tunnel Selector for Routes 162 A tunnel policy selector defines certain matching rules and 163 associates the routes whose attributes matching the rules with 164 specific tunnels. This facilitates flexible tunneling and better 165 satisfies user requirements. 167 A tunnel policy selector consists of one more policy nodes and the 168 relationship between these policy nodes is "OR". The system checks 169 the policy nodes based on index numbers. If a route matches a policy 170 node in the tunnel policy, the route does not continue to match the 171 next policy node. Each policy node comprises a set of if-match and 172 apply clauses: 174 1. The if-match clauses define the matching rules that are used to 175 match certain route attributes such as the next hop and RD. The 176 relationship between the if-match clauses of a node is "AND". A 177 route matches a node only when the route meets all the matching 178 rules specified by the if-match clauses of the node. 180 2. The apply clause specifies actions. When a route matches a 181 node, the apply clause selects a tunnel policy for the route. 182 The matching modes of a node are as follows: 184 a) Permit: If a route matches all the if-match clauses of a 185 node, the route matches the node and the actions defined by 186 the apply clause are performed on the route. If a route does 187 not match one if-match clause of a node, the route continues 188 to match the next node. 190 b) Deny: In this mode, the actions defined by the apply clause 191 are not performed. If a route matches all the if-match 192 clauses of a node, the route is denied and does not match the 193 next node. 195 3.3 Tunnel Selector for VPNs 197 Selection of the tunnel for the VPN services includes the matching 198 rules and the applied tunnel policy. The data model is defined in 199 the drafts of VPN Yang models which are out of the scope of this 200 document. They can refer to the Yang models defined in the document 201 for tunnel policy. 203 4. Design of Data Model 205 4.1 Tunnel Policy YANG Model 207 A tunnel policy determines which type of tunnels can be selected by 208 an application module. The configuration of tunnel policy includes 209 defining the tunnel selection sequence mode and the binding mode for 210 the tunnel selection. The nonexistentCheckFlag controls whether the 211 system allows a nonexistent tunnel policy to be specified in a 212 command. 214 +--rw tnlmGlobal 215 | +--rw nonexistentCheckFlag? boolean 216 +--rw tunnelPolicys 217 | +--rw tunnelPolicy* [tnlPolicyName] 218 | +--rw tnlPolicyName string 219 | +--ro tnlPolicyExist? tnlPolicyExist 220 | +--ro tpSubCount? uint32 221 | +--rw description? string 222 | +--rw tnlPolicyType? tnlmbaseTnlPolicyType 223 | +--rw tpNexthops 224 | | +--rw tpNexthop* [nexthopIPaddr] 225 | | +--rw nexthopIPaddr inet:ipv4-address-no-zone 226 | | +--rw downSwitch? boolean 227 | | +--rw ignoreDestCheck? boolean 228 | | +--rw isIncludeLdp? boolean 229 | | +--rw tpTunnels 230 | | +--rw tpTunnel* [tunnelName] 231 | | +--rw tunnelName string 232 | +--rw tnlSelSeqs 233 | +--rw tnlSelSeq! 234 | +--rw loadBalanceNum? uint32 235 | +--rw selTnlType1? tnlmbaseSelTnlType 236 | +--rw selTnlType2? tnlmbaseSelTnlType 237 | +--rw selTnlType3? tnlmbaseSelTnlType 238 | +--rw selTnlType4? tnlmbaseSelTnlType 239 | +--rw selTnlType5? tnlmbaseSelTnlType 240 | +--rw selTnlType6? tnlmbaseSelTnlType 241 | +--rw unmix? boolean 243 4.2 Tunnel Selector YANG Model 245 A tunnel policy selector defines certain matching rules and 246 associates the routes whose attributes matching the rules with 247 specific tunnels. This facilitates flexible tunneling satisfying 248 user requirements. 250 Configuration of the tunnel selector and applying it to the BGP 251 VPNv4/VPNv6 address-family can make the VPN service select the 252 specific tunnel for VPN data transmission. 254 +--rw tunnelSelectors 255 +--rw tunnelSelector* [name] 256 +--rw name string 257 +--rw tunnelSelectorNodes 258 +--rw tunnelSelectorNode* [nodeSequence] 259 +--rw nodeSequence uint32 260 +--rw matchMode rtpMatchMode 261 +--rw matchCondition 262 | +--rw matchDestPrefixFilters 263 | | +--rw matchDestPrefixFilter! 264 | | +--rw prefixName? string 265 | +--rw matchIPv4NextHops 266 | | +--rw matchIPv4NextHop! 267 | | +--rw matchType? rtpTnlSelMchType 268 | | +--rw prefixName? string 269 | | +--rw aclNameOrNum? string 270 | +--rw matchIPv6NextHops 271 | | +--rw matchIPv6NextHop! 272 | | +--rw ipv6PrefixName? string 273 | +--rw matchCommunityFilters 274 | | +--rw matchCommunityFilter* [cmntyNameOrNum] 275 | | +--rw cmntyNameOrNum string 276 | | +--rw wholeMatch? boolean 277 | | +--rw sortMatch? boolean 278 | +--rw matchRdFilters 279 | +--rw matchRdFilter! 280 | +--rw rdIndex? uint32 281 +--rw applyAction 282 +--rw applyTnlPolicys 283 +--rw applyTnlPolicy! 284 +--rw tnlPolicyName? string 286 augment /bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/ 287 bgp:l3vpn-ipv4-unicast: 288 +--rw tunnelSelectorName? string 289 augment /bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/ 290 bgp:l3vpn-ipv6-unicast: 291 +--rw tunnelSelectorName? string 293 5. Tunnel Policy Yang Module 295 //Tunnel Policy YANG MODEL 296 file " tunnel-policy@2018-09-15.yang " 297 module tunnel-policy { 298 namespace "urn:huawei:params:xml:ns:yang:tunnel-policy"; 299 // replace with IANA namespace when assigned 300 prefix tnlp; 302 import ietf-bgp { 303 prefix bgp; 305 } 307 import ietf-inet-types { 308 prefix inet; 309 //rfc6991-Common YANG Data Types 310 } 312 organization 313 "Huawei Technologies Co., Ltd."; 314 contact 315 "Huawei Industrial Base Bantian, Longgang Shenzhen 518129 316 People's Republic of China 317 Website: http://www.huawei.com Email: support@huawei.com"; 318 description 319 "This YANG module defines the tunnel policy configuration 320 data for tunnel policy service. 322 VPN data needs to be carried by tunnels. By default, the 323 system selects LSPs to carry VPN services without performing 324 load balancing. If this cannot meet the requirements of VPN 325 services, a tunnel policy needs to be used. The tunnel policy 326 may be a tunnel type prioritizing policy or a tunnel binding 327 policy. Determine which type of tunnel policy to use based 328 on your actual requirements: 329 * A tunnel type prioritizing policy can change the tunnel 330 type selected for VPN services and allow load balancing 331 among tunnels. 332 * A tunnel binding policy can bind a VPN service to 333 specified MPLS TE tunnels to provide QoS guarantee for 334 the VPN service. 336 Terms and Acronyms 338 ... "; 340 revision 2018-09-15 { 341 description 342 "Initial revision."; 344 } 346 typedef tnlmbaseTnlPolicyType { 347 type enumeration { 348 enum "invalid" { 349 description 350 "Tunnel policy with null configurations."; 351 } 352 enum "tnlSelectSeq" { 353 description 354 "Tunnel select-seq policy. This policy allows you 355 to specify the sequence in which different types 356 of tunnels are selected and the number of tunnels 357 for load balancing."; 358 } 359 enum "tnlBinding" { 360 description 361 "Tunnel binding policy. This policy allows you to 362 specify the next hop to be bound to a TE tunnel. 363 After a TE tunnel is bound to a destination 364 address, VPN traffic destined for that destination 365 address will be transmitted over the TE tunnel."; 366 } 367 } 368 description 369 "tunnel policy type"; 370 } 371 typedef tnlmbaseSelTnlType { 372 type enumeration { 373 enum "invaild" { 374 description 375 "Search for invalid tunnels."; 376 } 377 enum "lsp" { 378 description 379 "Search for LDP LSPs."; 380 } 381 enum "cr-lsp" { 382 description 383 "Search for CR-LSPs."; 384 } 385 enum "gre" { 386 description 387 "Search for GREs."; 388 } 389 enum "ldp" { 390 description 391 "Search for LDP LSPs."; 392 } 393 enum "bgp" { 394 description 395 "Search for BGP LSPs."; 396 } 397 enum "srbe-lsp" { 398 description 399 "Search for SR-LSPs."; 400 } 401 enum "sr-te" { 402 description 403 "Search for SR-TE."; 404 } 405 enum "te" { 406 description 407 "Search for TE."; 408 } 409 } 410 description 411 "tunnel select type"; 412 } 414 typedef tnlPolicyExist { 415 type enumeration { 416 enum "true" { 417 description 418 "The tunnel policy has been configured."; 419 } 420 enum "false" { 421 description 422 "The tunnel policy has not been configured."; 423 } 424 } 425 description 426 "tunnel policy state"; 427 } 429 typedef rtpMatchMode { 430 type enumeration { 431 enum "permit" { 432 description 433 "Matching mode of filters."; 434 } 435 enum "deny" { 436 description 437 "Matching mode of filters."; 438 } 439 } 440 description 441 "match mode"; 442 } 443 typedef rtpTnlSelMchType { 444 type enumeration { 445 enum "matchNHopPF" { 446 description 447 "Match IPv4 next hops by an IPv4 prefix."; 448 } 449 enum "matchNHopAcl" { 450 description 451 "Match IPv4 next hops by an ACL."; 452 } 453 } 454 description 455 "tunnel selector type"; 456 } 458 /* 459 A tunnel policy determines which type of tunnels can be 460 selected by an application module. 462 Tunnel policies can be classified into two modes: 463 Select-seq: The system selects a tunnel for an application 464 program based on the tunnel type priorities defined in the 465 tunnel policy. 466 Tunnel binding: The system selects only a specified tunnel 467 for an application program. 469 The two modes are mutually exclusive. 471 Configuration example: 472 # 473 tunnel-policy policy1 474 description policy1 475 tunnel binding destination 1.1.1.1 te Tunnel0/0/0 down-switch 476 # 477 tunnel-policy policy2 478 tunnel select-seq cr-lsp gre lsp load-balance-number 2 479 # 480 tunnel-policy policy3 481 tunnel binding destination 1.1.1.1 te Tunnel0/0/0 down-switch 482 tunnel binding destination 3.3.3.3 te Tunnel0/0/0 483 ignore-destination-check 484 tunnel binding destination 5.5.5.5 te Tunnel0/0/0 485 # 486 */ 488 container tnlmGlobal { 489 description 490 "Global parameters for tunnel policy."; 491 leaf nonexistentCheckFlag { 492 type boolean; 493 default "true"; 494 description 495 "Nonexistent config check flag of tunnel policy. 496 By default, if you specify a nonexistent tunnel policy 497 in a command, the command does not take effect. To enable 498 the system to allow a nonexistent tunnel policy to be 499 specified in a command, run the tunnel-policy 500 nonexistent-config-check disable command."; 501 } 502 } 504 container tunnelPolicys { 505 description 506 "List of global tunnel policy configurations. A tunnel 507 policy can be used to specify a rule for selecting 508 tunnels."; 510 list tunnelPolicy { 511 key "tnlPolicyName"; 513 description 514 "A policy for selecting tunnels to carry services. The 515 tunnel management module searches for and returns the 516 required tunnels based on the tunnel policy. By default, 517 no tunnel policy is configured, the system selects an 518 available tunnel in the order of conventional LSPs, 519 CR-LSPs, and Local_IFNET LSPs, and load balancing is 520 not performed."; 522 leaf tnlPolicyName { 523 type string { 524 length "1..39"; 525 } 526 description 527 "Name of a tunnel policy. The value is a string of 1 to 528 39 case-sensitive characters, spaces not supported."; 529 } 530 leaf tnlPolicyExist { 531 type tnlPolicyExist; 532 config false; 533 description 534 "Whether a tunnel policy has been configured."; 535 } 536 leaf tpSubCount { 537 type uint32; 538 config false; 539 description 540 "Number of times a tunnel policy is referenced."; 541 } 542 leaf description { 543 type string { 544 length "1..80"; 545 } 546 description 547 "Description of a tunnel policy."; 548 } 550 leaf tnlPolicyType { 551 type tnlmbaseTnlPolicyType; 552 default "invalid"; 553 description 554 "Tunnel policy type. The available options are sel-seq, 555 binding, and invalid. A tunnel policy can be configured 556 with only one policy type."; 557 } 558 container tpNexthops { 559 must "not(../tnlPolicyType='tnlBinding') or " 560 + "(../tnlPolicyType='tnlBinding' " 561 + "and count(tpNexthop)>=1)"; 562 description 563 "List of tunnel binding configurations."; 564 list tpNexthop { 565 when "not(../../tnlPolicyType='tnlSelectSeq') or " 566 + "../../tnlPolicyType='tnlBinding'"; 567 key "nexthopIPaddr"; 568 max-elements "65535"; 569 description 570 "Rule for binding a TE tunnel to a destination address, 571 so that the VPN traffic destined for that destination 572 address can be transmitted over the TE tunnel."; 573 leaf nexthopIPaddr { 574 type inet:ipv4-address-no-zone; 575 description 576 "Destination IP address to be bound to a tunnel."; 577 } 578 leaf downSwitch { 579 type boolean; 580 default "false"; 581 description 582 "Enable tunnel switching. After this option is 583 selected, if the bound TE tunnel is unavailable, 584 the system will select an available tunnel in 585 the order of conventional LSPs, CR-LSPs, and 586 Local_IFNET tunnels."; 587 } 588 leaf ignoreDestCheck { 589 type boolean; 590 default "false"; 591 description 592 "Do not check whether the destination address of the 593 TE tunnel matches the destination address specified 594 in the tunnel policy."; 595 } 596 leaf isIncludeLdp { 597 type boolean; 598 must "(../isIncludeLdp='true' and not " 599 + "(../downSwitch='true')) or " 600 + "../isIncludeLdp='false'"; 601 default "false"; 602 description 603 "Is loadbalance with LDP"; 604 } 605 container tpTunnels { 606 description 607 "List of tunnels available for an application."; 608 list tpTunnel { 609 key "tunnelName"; 610 min-elements "1"; 611 max-elements "16"; 612 description 613 "Tunnel."; 614 leaf tunnelName { 615 type string { 616 length "1..47"; 617 } 618 description 619 "Name of the specified tunnel."; 620 } 621 } 622 } 623 } 624 } 625 container tnlSelSeqs { 626 when "not(../tnlPolicyType='invalid' or " 627 + "../tnlPolicyType='tnlBinding')"; 628 must "not(../tnlPolicyType='tnlSelectSeq') or " 629 + "(../tnlPolicyType='tnlSelectSeq' and " 630 + "count(tnlSelSeq)>=1)"; 631 description 632 "Sequence in which different types of tunnels are 633 selected. 634 If the value is INVALID, no tunnel type has been 635 configured."; 636 container tnlSelSeq { 637 when "not(../../tnlPolicyType='invalid' or " 638 + "../../tnlPolicyType='tnlBinding') or " 639 + "../../tnlPolicyType='tnlSelectSeq'"; 640 presence "create tnlSelSeq"; 641 description 642 "Sequence in which different types of tunnels are 643 selected. If the value is INVALID, no tunnel type 644 has been configured."; 645 leaf loadBalanceNum { 646 type uint32 { 647 range "1..64"; 648 } 649 default "1"; 650 description 651 "Sequence in which different types of tunnels are 652 selected. The available tunnel types are CR-LSP, 653 and LSP. LSP tunnels refer to LDP LSP tunnels 654 here."; 655 } 656 leaf selTnlType1 { 657 type tnlmbaseSelTnlType; 658 default "invaild"; 659 description 660 "Sequence in which different types of tunnels are 661 selected. If the value is INVALID, no tunnel type 662 has been configured."; 663 } 664 leaf selTnlType2 { 665 when "not(../selTnlType1='invaild' and " 666 + "../../../tnlPolicyType='tnlSelectSeq' or " 667 + "../selTnlType1='invaild')"; 668 type tnlmbaseSelTnlType; 669 default "invaild"; 670 description 671 "Sequence in which different types of tunnels are 672 selected. If the value is INVALID, no tunnel type 673 has been configured."; 674 } 675 leaf selTnlType3 { 676 when "not(../selTnlType1='invaild' or " 677 + "../selTnlType2='invaild')"; 678 type tnlmbaseSelTnlType; 679 default "invaild"; 680 description 681 "Sequence in which different types of tunnels are 682 selected. If the value is INVALID, no tunnel type 683 has been configured."; 684 } 685 leaf selTnlType4 { 686 when "not(../selTnlType1='invaild' or " 687 + "../selTnlType2='invaild' or " 688 + "../selTnlType3='invaild')"; 689 type tnlmbaseSelTnlType; 690 default "invaild"; 691 description 692 "Sequence in which different types of tunnels are 693 selected. If the value is INVALID, no tunnel type 694 has been configured."; 695 } 696 leaf selTnlType5 { 697 when "not(../selTnlType1='invaild' or " 698 + "../selTnlType2='invaild' or " 699 + "../selTnlType3='invaild' or " 700 + "../selTnlType4='invaild')"; 701 type tnlmbaseSelTnlType; 702 default "invaild"; 703 description 704 "Sequence in which different types of tunnels are 705 selected. If the value is INVALID, no tunnel type 706 has been configured."; 707 } 708 leaf selTnlType6 { 709 when "not(../selTnlType1='invaild' or " 710 + "../selTnlType2='invaild' or " 711 + "../selTnlType3='invaild' or " 712 + "../selTnlType4='invaild' or " 713 + "../selTnlType5='invaild')"; 714 type tnlmbaseSelTnlType; 715 default "invaild"; 716 description 717 "Sequence in which different types of tunnels are 718 selected. If the value is INVALID, no tunnel type 719 has been configured."; 720 } 721 leaf unmix { 722 type boolean; 723 default "false"; 724 description 725 "unmix flag."; 726 } 727 } 728 } 729 } 731 }//End of container tunnelPolicys 733 /* 734 The tunnel selector is specific to BGP/MPLS IP VPN services 735 (a type of VPN service), selecting a tunnel policy for 736 VPNv4/VPNv6 routes on the backbone network. 738 A tunnel selector selects tunnel policies for routes after 739 filtering routes based on some route attributes such as the 740 route distinguisher (RD) and next hop. This makes tunnel 741 selection more flexible. 743 A tunnel selector is often used on the autonomous system 744 boundary router (ASBR) in inter-AS VPN Option B or the 745 superstratum provider edge (SPE) in hierarchy of VPN (HoVPN). 746 */ 747 container tunnelSelectors { 748 description 749 "List of tunnel selectors."; 750 list tunnelSelector { 751 key "name"; 752 max-elements "65535"; 753 description 754 "Tunnel selector. Usually used in BGP VPN Option B or 755 BGP VPN Option C, tunnel selector selects a proper 756 tunnel policy for routes."; 758 leaf name { 759 type string { 760 length "1..40"; 761 } 762 description 763 "Name of a tunnel selector. The name is a string of 764 1 to 40 case-sensitive characters without spaces."; 765 } 767 container tunnelSelectorNodes { 768 description 769 "List of tunnel selector nodes."; 770 list tunnelSelectorNode { 771 key "nodeSequence"; 772 min-elements "1"; 773 max-elements "65535"; 775 leaf nodeSequence { 776 type uint32 { 777 range "0..65535"; 778 } 779 description 780 "Sequence number of a node. 781 Specifies the index of a node of the tunnel 782 selector. 783 When a route-policy is used to filter a route, 784 the route first matches the node with the 785 smallest node value."; 786 } 787 leaf matchMode { 788 type rtpMatchMode; 789 mandatory true; 790 description 791 "Matching mode of nodes."; 792 } 793 container matchCondition { 794 description 795 "Match Type List"; 797 container matchDestPrefixFilters { 798 description 799 "Match IPv4 destination addresses by the prefix 800 filter. The configurations of matching IPv4 801 destination addresses by the prefix filter are 802 mutually exclusive with the configurations of 803 matching IPv4 destination addresses based on 804 ACL rules."; 806 container matchDestPrefixFilter { 807 presence "create matchDestPrefixFilter"; 808 description 809 "Match an IPv4 destination address by the prefix 810 filter."; 811 leaf prefixName { 812 type "string"; 813 description 814 "Name of the specified prefix filter when IPv4 815 destination addresses are matched."; 816 } 817 } 818 } // End of matchDestPrefixFilters 820 container matchIPv4NextHops { 821 description 822 "Match IPv4 next hops by the prefix filter or ACL 823 filter. The configurations of matching IPv4 next 824 hops by the prefix filter are mutually exclusive 825 with the configurations of matching IPv4 next 826 hops by the ACL filter."; 828 container matchIPv4NextHop { 829 presence "create matchIPv4NextHop"; 830 description 831 "Match an IPv4 next hop by the prefix or ACL."; 832 leaf matchType { 833 type rtpTnlSelMchType; 834 description 835 "Match type. IPv4 next hops are matched with 836 either the prefix or ACL."; 837 } 838 leaf prefixName { 839 when "not(../matchType='matchNHopAcl' or " 840 + "not(../matchType)) or " 841 + "../matchType='matchNHopPF'"; 842 type "string"; 843 description 844 "Name of the specified prefix when IPv4 next hops 845 are matched."; 846 } 847 leaf aclNameOrNum { 848 when "not(../matchType='matchNHopPF' or " 849 + "not(../matchType)) or " 850 + "../matchType='matchNHopAcl'"; 851 type string { 852 length "1..32"; 853 } 854 description 855 "Name of the specified ACL when next hops are 856 matched, which can be a value ranging from 857 2000 to 2999 or a string beginning with a-z 858 or A-Z."; 859 } 860 } 861 } //End of container matchIPv4NextHops 863 container matchIPv6NextHops { 864 description 865 "Match IPv6 next hops by the IPv6 prefix filter."; 866 container matchIPv6NextHop { 867 presence "create matchIPv6NextHop"; 868 description 869 "Match an IPv6 next hop by the IPv6 prefix 870 filter."; 872 leaf ipv6PrefixName { 873 type "string"; 874 description 875 "Name of the specified prefix filter when IPv6 876 next hops are matched."; 877 } 878 } 879 } //End of container matchIPv6NextHops 881 container matchCommunityFilters { 882 description 883 "Match community attribute filters."; 884 list matchCommunityFilter { 885 key "cmntyNameOrNum"; 886 max-elements "32"; 887 description 888 "Match a community attribute filter."; 889 leaf cmntyNameOrNum { 890 type string { 891 length "1..51"; 892 pattern '((0*[1-9][0-9]?)|(0*1[0-9][0-9])|' 893 + '([^?-9][^?0,50})|' 894 + '([][^?^?-9][^?)'; 895 } 896 description 897 "Name or index of a community attribute filter. 898 It can be a numeral or a string. The ID of a 899 basic community attribute filter is an integer 900 ranging from 1 to 99; the ID of an advanced 901 community attribute filter is an integer 902 ranging from 100 to 199. The name of a community 903 attribute filter is a string of 1 to 51 904 characters. The string cannot contain only 905 digits."; 906 } 907 leaf wholeMatch { 908 type boolean; 909 default "false"; 910 description 911 "All the communities are matched. It is valid to 912 only basic community attribute filters."; 913 } 914 leaf sortMatch { 915 type boolean; 916 default "false"; 917 description 918 "Match all community attributes in sequence.It 919 is valid to only Advanced community attribute 920 filters."; 921 } 922 } 923 } //End of container matchCommunityFilters 925 container matchRdFilters { 926 description 927 "Match RD filters."; 928 container matchRdFilter { 929 presence "create matchRdFilter"; 930 description 931 "Match an RD filter."; 932 leaf rdIndex { 933 type uint32 { 934 range "1..1024"; 935 } 936 description 937 "Index of an RD filter."; 938 } 939 } 940 } //End of container matchRdFilters 942 }//End of container matchCondition 943 container applyAction { 944 description 945 "Set Type List"; 946 container applyTnlPolicys { 947 description 948 "Set tunnel policies."; 949 container applyTnlPolicy { 950 presence "create applyTnlPolicy"; 951 description 952 "Set a tunnel policy."; 953 leaf tnlPolicyName { 954 type string { 955 length "1..39"; 956 } 957 description 958 "Name of a tunnel policy. The name is a 959 string of 1 to 39 case-sensitive characters, 960 spaces not supported."; 961 } 962 } 963 } 964 } //End of container applyAction 966 } 968 } //End of container tunnelSelectorNodes 970 } //End of list tunnelSelector 972 } //End of container tunnelSelectors 974 /* 975 * augment some bgp vpn functions in bgp module. 976 */ 977 augment "/bgp:bgp/bgp:global/bgp:afi-safis/" +............ 978 "bgp:afi-safi/bgp:l3vpn-ipv4-unicast" { 979 leaf tunnelSelectorName { 980 description 981 "Specifies the name of a tunnel selector."; 983 type "string"; 984 } 985 } 987 augment "/bgp:bgp/bgp:global/bgp:afi-safis/" +............ 988 "bgp:afi-safi/bgp:l3vpn-ipv6-unicast" { 989 leaf tunnelSelectorName { 990 description 991 "Specifies the name of a tunnel selector."; 993 type "string"; 994 } 995 } 996 998 6. IANA Considerations 1000 This document requires no IANA actions. 1002 7. Security Considerations 1004 The YANG module specified in this document defines a schema for data 1005 that is designed to be accessed via network management protocols such 1006 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1007 is the secure transport layer, and the mandatory-to-implement secure 1008 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1009 is HTTPS, and the mandatory-to-implement secure transport is TLS 1010 [RFC8446]. 1012 The NETCONF access control model [RFC8341] provides the means to 1013 restrict access for particular NETCONF or RESTCONF users to a 1014 preconfigured subset of all available NETCONF or RESTCONF protocol 1015 operations and content. 1017 There are a number of data nodes defined in this YANG module that are 1018 writable/creatable/deletable (i.e., config true, which is the 1019 default). These data nodes may be considered sensitive or vulnerable 1020 in some network environments. Write operations (e.g., edit-config) to 1021 these data nodes without proper protection can have a negative effect 1022 on network operations. These are the subtrees and data nodes and 1023 their sensitivity/vulnerability: 1025 tbd 1027 Unauthorized access to any data node of these subtrees can adversely 1028 affect ... tbd ... 1030 Some of the readable data nodes in this YANG module may be considered 1031 sensitive or vulnerable in some network environments. It is thus 1032 important to control read access (e.g., via get, get-config, or 1033 notification) to these data nodes. These are the subtrees and data 1034 nodes and their sensitivity/vulnerability: 1036 tbd 1038 Unauthorized access to any data node of these subtrees can disclose 1039 ... tbd ... 1041 Acknowledgements 1043 The authors would like to thank the following for their contributions 1044 to this work: 1046 Xianping Zhang, Linghai Kong, Xiangfeng Ding, Haibo Wang, and 1047 Walker Zheng 1049 Informational References 1051 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1052 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1053 6241, June 2011. 1055 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1056 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1057 . 1059 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access 1060 Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, 1061 March 2018, . 1063 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1064 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1065 . 1067 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1068 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1069 . 1071 Normative References 1073 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1074 Network Configuration Protocol (NETCONF)", RFC 6020, 1075 October 2010. 1077 Authors' Addresses 1079 Zhenbin Li 1080 Huawei Technologies 1081 Huawei Bld., No.156 Beiqing Rd. 1082 Beijing 100095 China 1084 Email: lizhenbin@huawei.com 1086 Shunwan Zhuang 1087 Huawei Technologies 1088 Huawei Bld., No.156 Beiqing Rd. 1089 Beijing 100095 China 1091 Email: zhuangshunwan@huawei.com 1093 Gang Yan 1094 Huawei Technologies 1095 Huawei Bld., No.156 Beiqing Rd. 1096 Beijing 100095 China 1098 Email: yangang@huawei.com 1100 Donald Eastlake, 3rd 1101 Huawei Technologies 1102 1424 Pro Shop Court 1103 Davenport, FL 33896 USA 1105 Phone: +1-508-333-2270 1106 Email: d3e3e3@gmail.com 1108 Copyright and IPR Provisions 1110 Copyright (c) 2018 IETF Trust and the persons identified as the 1111 document authors. All rights reserved. 1113 This document is subject to BCP 78 and the IETF Trust's Legal 1114 Provisions Relating to IETF Documents 1115 (http://trustee.ietf.org/license-info) in effect on the date of 1116 publication of this document. Please review these documents 1117 carefully, as they describe your rights and restrictions with respect 1118 to this document. Code Components extracted from this document must 1119 include Simplified BSD License text as described in Section 4.e of 1120 the Trust Legal Provisions and are provided without warranty as 1121 described in the Simplified BSD License. The definitive version of 1122 an IETF Document is that published by, or under the auspices of, the 1123 IETF. Versions of IETF Documents that are published by third parties, 1124 including those that are translated into other languages, should not 1125 be considered to be definitive versions of IETF Documents. The 1126 definitive version of these Legal Provisions is that published by, or 1127 under the auspices of, the IETF. Versions of these Legal Provisions 1128 that are published by third parties, including those that are 1129 translated into other languages, should not be considered to be 1130 definitive versions of these Legal Provisions. For the avoidance of 1131 doubt, each Contributor to the IETF Standards Process licenses each 1132 Contribution that he or she makes as part of the IETF Standards 1133 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1134 language to the contrary, or terms, conditions or rights that differ 1135 from or are inconsistent with the rights and licenses granted under 1136 RFC 5378, shall have any effect and shall be null and void, whether 1137 published or posted by such Contributor, or included with or in such 1138 Contribution.