idnits 2.17.1 draft-wwz-netmod-yang-tunnel-cfg-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 839 has weird spacing: '...mber of packe...' == Line 852 has weird spacing: '...mber of packe...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2015) is 3220 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) == Missing Reference: 'RFC2784' is mentioned on line 77, but not defined == Missing Reference: 'RFC2890' is mentioned on line 77, but not defined == Missing Reference: 'RFC2003' is mentioned on line 74, but not defined == Missing Reference: 'RFC2473' is mentioned on line 74, but not defined == Missing Reference: 'RFC2401' is mentioned on line 74, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC2402' is mentioned on line 75, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'RFC3031' is mentioned on line 75, but not defined == Missing Reference: 'RFC3035' is mentioned on line 75, but not defined == Missing Reference: 'RFC7348' is mentioned on line 75, but not defined == Missing Reference: 'VXLAN-GPE' is mentioned on line 76, but not defined == Missing Reference: 'NVGRE' is mentioned on line 76, but not defined == Missing Reference: 'GTP-U' is mentioned on line 76, but not defined == Missing Reference: 'RFC4023' is mentioned on line 77, but not defined == Missing Reference: 'RFC4110' is mentioned on line 79, but not defined == Missing Reference: 'RFC7223' is mentioned on line 293, but not defined ** Obsolete undefined reference: RFC 7223 (Obsoleted by RFC 8343) == Missing Reference: 'RFC2764' is mentioned on line 246, but not defined == Missing Reference: 'RFC2983' is mentioned on line 246, but not defined == Missing Reference: 'RFC6241' is mentioned on line 890, but not defined == Missing Reference: 'RFC6242' is mentioned on line 892, but not defined == Missing Reference: 'RFC6536' is mentioned on line 893, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 899, but not defined Summary: 4 errors (**), 0 flaws (~~), 25 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track Z. Wang 5 Expires: January 4, 2016 Y. Zhuang 6 Huawei 7 July 3, 2015 9 YANG Data Model for Tunnel Management 10 draft-wwz-netmod-yang-tunnel-cfg-00 12 Abstract 14 This document defines a YANG data model for the configuration and 15 management of generic tunnels. The data model includes configuration 16 data and state data. And it can serve as a base model which is 17 augmented with technology-specific details in other, more specific 18 tunnel models. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 4, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 56 3. Architecture of Generic YANG Model for tunnel . . . . . . . . 3 57 3.1. Relationship to interface yang data model . . . . . . . . 3 58 4. Design of GENERIC TUNNEL Modules . . . . . . . . . . . . . . 4 59 4.1. tunnel configuration model . . . . . . . . . . . . . . . 4 60 4.1.1. Resource container . . . . . . . . . . . . . . . . . 7 61 4.2. tunnel state model . . . . . . . . . . . . . . . . . . . 7 62 5. Gen-tunnel yang data hierarchy . . . . . . . . . . . . . . . 8 63 6. Tunnel YANG Module . . . . . . . . . . . . . . . . . . . . . 10 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 66 9. Normative References . . . . . . . . . . . . . . . . . . . . 21 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 69 1. Introduction 71 Tunneling mechanisms provide isolated communication from one VPN edge 72 device to another in the VPN solutions. Available tunneling 73 mechanisms include (but are not limited to): GRE [RFC2784] [RFC2890], 74 IP-in-IP encapsulation [RFC2003] [RFC2473], IPsec [RFC2401] 75 [RFC2402], and MPLS [RFC3031] [RFC3035], VXLAN ([RFC7348]), VXLAN-GPE 76 ([VXLAN-GPE]), NVGRE ([NVGRE]), GTP [GTP-U], and MPLS-in-GRE 77 ([RFC2784], [RFC2890], [RFC4023]). 79 [RFC4110] discusses some common characteristics shared by all forms 80 of tunneling, and some common problems to which tunnels provide a 81 solution from the following perspectives: 83 o Multiplexing 85 o QoS/SLA 87 o Tunnel setup and maintenance 89 o Security 91 This document defines a yang data model[RFC6020] to represent common 92 building block for tunnels configuration data and state data. This 93 model can be augmented with technology specifics of particular types 94 of tunnel. 96 2. Conventions and Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Architecture of Generic YANG Model for tunnel 104 In this document we define a common core tunnel model. The YANG 105 model defined here is generic such that other technologies can extend 106 it for technology specific needs. The Generic Tunnel YANG model acts 107 as the root for other Tunnel YANG models. This allows users to span 108 across Tunnel of different technologies through a uniform API set. 109 Figure 1 depicts the relationship of different Tunnel YANG models to 110 the Generic Tunnel YANG Model. Some technologies may have different 111 sub-technologies. As an example, consider Network IP-in-IP Tunnel. 112 These could employ IPv4-in-IPv4, IPv6-in-IPv4, and other methods as 113 encapsulation protocol. Figure 1 depicts relationship of different 114 YANG modules. 116 +--------------------------+ 117 | | 118 | GEN TUNNEL YANG MODEL | 119 | | 120 +-------------+------------+ 121 | 122 | 123 +------------+-------+---------+----------+ 124 | | | | 125 | | | | 126 +-------+ +----+------+ +---------+ ... 127 | GRE | | IP in IP | | IPsec | 128 | tunnel| | yang | | tunnel | 129 | yang | | | | yang | 130 +-------+ +-----------+ +---------+ 132 Relationship of technology specific TUNNEL YANG model to generic 133 (base) YANG model 135 3.1. Relationship to interface yang data model 137 This section clarifies the relationship of this yang module to the 138 interfaces yang [RFC7223]. Tunnels are handled by creating a logical 139 interface for each tunnel. Each logical interface (physical or 140 virtual) need to map to interface yang model [RFC7223]. To do so, in 141 this draft, we augment interface yang model with tunnel interface 142 specifics, which is binding tunnel interface with a physical 143 interface [RFC7223]. 145 | | | | | | 146 +--+ +---+ +--+ +---+ | | 147 | IP | | VXLAN | | | 148 | tunnel | | tunnel | | | 149 +--+ +---+ +--+ +---+ | | 150 | | | | | | 151 +--+ +---------+ +----------+ +--+ 152 | Physical interface | 153 +--------------------------------+ 155 4. Design of GENERIC TUNNEL Modules 157 This document defines the YANG module "gen-tunnel", which augments 158 the "interface" and "interface-state" lists defined in the "ietf- 159 interfaces" module [RFC7223] with tunnel specific data nodes, and 160 also adds tunnel specific state data. 162 4.1. tunnel configuration model 164 The data model has the following structure for tunnel configuration 165 per interface: 167 module: gen-tunnel 168 augment /if:interfaces/if:interface: 169 +--rw tunnel-configuration 170 +--rw base-interface? if:interface-ref 171 +--rw tunnel-name? string 172 +--rw ip-address? yang:phys-address 173 +--rw technology? identityref 174 +--rw encapsulation-method? identityref 175 +--rw (signaling-protocol-type)? 176 | +--:(signaling-protocol-null) 177 | +--rw signaling-null? empty 178 +--rw tunnel-source 179 | +--rw (tunnel-source)? 180 | +--:(interface) 181 | | +--rw interface-type? leafref 182 | | +--rw interface? if:interface-ref 183 | +--:(ipv4-address) 184 | | +--rw ipv4-address? inet:ipv4-address 185 | +--:(ipv6-address) 186 | +--rw ipv6-address? inet:ipv6-address 187 +--rw tunnel-destination 188 | +--rw (tunnel-destination)? 189 | +--:(interface) 190 | | +--rw interface-type? leafref 191 | | +--rw interface? if:interface-ref 192 | +--:(ipv4-address) 193 | | +--rw ipv4-address? inet:ipv4-address 194 | +--:(ipv6-address) 195 | +--rw ipv6-address? inet:ipv6-address 196 +--rw MTU? uint32 197 +--rw ttl? uint8 198 +--rw priority? uint8 199 +--rw (Multiplexing)? 200 | +--:(multiplexing-null) 201 | +--rw multiplexing-null? empty 202 +--rw (QoS)? 203 | +--:(Qos-null) 204 | +--rw QoS-null? empty 205 +--rw (Security)? 206 | +--:(Security-null) 207 | +--rw Security-null? empty 208 +--rw resource 209 ...... 211 o The base-interface which with type leafref is used pointing to the 212 corresponding interface-name node in the interface yang [RFC7223]. 213 As describe in section 3.1, each tunnel need to binding to a 214 physical interface[RFC7223]. In the gen-tunnel model, the base- 215 interface leaf is playing this role. 217 o The tunnel-name is the identification of the tunnel. Different 218 tunnel is distinguished via the leaf tunnel-name. 220 o The technology leaf indicate the technology of the tunnel such as 221 IP, MPLS, VXLAN, etc. The default value is IP. And this allows 222 easy extension of the YANG model by other technologies. 224 o The encapsulation-method leaf indicate the encapsulation method of 225 the tunnel such as Minimal encapsulation, L2TP encapsulation, PPTP 226 encapsulation, L2F encapsulation, UDP encapsulation, ATMP 227 encapsulation, MSDP encapsulation, 6to4 encapsulation, 6over4 228 encapsulation, ISATAP encapsulation, etc. The default value is 229 direct (no intermediate header). And this allows easy extension 230 of the YANG model by other technologies. 232 o The signaling-protocol-type indicate the signaling protocol type 233 of the tunnel such as rsvp, crldp, etc. And the default value is 234 empty, which allows easy extension of the YANG model by other 235 technologies. 237 o The multiplexing might be one which was explicitly designed for 238 multiplexing, or one that wasn't originally designed for this but 239 can be pushed into service as a multiplexing field. For example: 240 the Key field for GRE, the SPI field for IPsec, etc. In gen- 241 tunnel model, the default value of multiplexing is empty, which 242 allows easy extension of the yang model by other technologies. 244 o A tunnel may not have intrinsic QoS/SLA capabilities, but it 245 inherits whatever mechanisms exist for IP. Other mechanisms such 246 as RSVP extensions [RFC2764] or DiffServ extensions [RFC2983], may 247 be used with it. In gen-tunnel model, the default value of QoS/ 248 SLA capability is empty, which allows easy extension of the yang 249 model by other technologies. 251 o A tunnel may provide significant security services. For example: 252 When IPsec tunneling is used in conjunction with IPsec's 253 cryptographic capabilities, excellent authentication and integrity 254 functions can be provided. In gen-tunnel model, the default value 255 of security is empty, which allows easy extension of the yang 256 model by other technologies. 258 4.1.1. Resource container 260 The resource container is used to indicate the resources required for 261 a tunnel. Which contains a MaxRate leaf, a MaxBurstSize leaf, an 262 ExBurstSize leaf, a Frequency leaf and a weight leaf. 264 module: gen-tunnel 265 augment /if:interfaces/if:interface: 266 +--rw base-interface? if:interface-ref 267 ...... 268 +--rw resource 269 +--rw bandwidth? uint32 270 +--rw MaxRate? uint32 271 +--rw MaxBurstSize? uint32 272 +--rw ExBurstSize? uint32 273 +--rw Frequency? uint32 274 +--rw weight? uint32 276 o The bandwidth indicate the bandwidth required of this tunnel. 278 o The MaxRate indicate the maximum rate of this tunnel. 280 o The MaxBurstSize indicate the maximum burst size of this tunnel. 282 o The ExBurstSize indicate the excess burst size of this tunnel. 284 o The Frequency indicate the granularity of the availability of 285 committed rate. 287 o The weight indicate the relative weight for using excess bandwidth 288 above its committed rate. 290 4.2. tunnel state model 292 The tunnel state model augments the "interface-state" lists defined 293 in the "ietf-interfaces" module [RFC7223] with tunnel specific state 294 data. On the top of the tunnel state model, we defines a tunnel 295 list, each tunnel within it corresponding to a tunnel instance. 296 Within each tunnel, we present an admin-status, an oper-status , MTU, 297 packets input/output, input/output error, input/output utility rate 298 and the number of bytes. 300 module: gen-tunnel 301 augment /if:interfaces-state: 302 +--ro tunnel-state 303 +--ro tunnel* [tunnel-name] 304 +--ro tunnel-name leafref 305 +--ro admin-status? enumeration 306 +--ro oper-status? enumeration 307 +--ro MTU? uint32 308 +--ro packets-input? yang:counter64 309 +--ro input-errors? yang:counter64 310 +--ro packets-output? yang:counter64 311 +--ro output-errors? yang:counter64 312 +--ro input-utility-rate? yang:counter64 313 +--ro output-utility-rate? yang:counter64 314 +--ro transmitted-bytes? yang:counter64 316 5. Gen-tunnel yang data hierarchy 318 The complete data hierarchy related to the Tunnel YANG model is 319 presented below. The following notations are used within the data 320 tree and carry the meaning as below. 322 Each node is printed as: 324 326 is one of: 327 + for current 328 x for deprecated 329 o for obsolete 331 is one of: 333 rw for configuration data 334 ro for non-configuration data 335 -x for rpcs 336 -n for notifications 338 is the name of the node 340 If the node is augmented into the tree from another module, its name 341 is printed as :. 343 is one of: 345 ? for an optional leaf or choice 346 ! for a presence container 347 * for a leaf-list or list 348 [] for a list's keys 350 is the name of the type for leafs and leaf-lists 352 module: gen-tunnel 353 augment /if:interfaces/if:interface: 354 +--rw tunnel-configuration 355 +--rw base-interface? if:interface-ref 356 +--rw tunnel-name? string 357 +--rw ip-address? yang:phys-address 358 +--rw technology? identityref 359 +--rw encapsulation-method? identityref 360 +--rw (signaling-protocol-type)? 361 | +--:(signaling-protocol-null) 362 | +--rw signaling-null? empty 363 +--rw tunnel-source 364 | +--rw (tunnel-source)? 365 | +--:(interface) 366 | | +--rw interface-type? leafref 367 | | +--rw interface? if:interface-ref 368 | +--:(ipv4-address) 369 | | +--rw ipv4-address? inet:ipv4-address 370 | +--:(ipv6-address) 371 | +--rw ipv6-address? inet:ipv6-address 372 +--rw tunnel-destination 373 | +--rw (tunnel-destination)? 374 | +--:(interface) 375 | | +--rw interface-type? leafref 376 | | +--rw interface? if:interface-ref 377 | +--:(ipv4-address) 378 | | +--rw ipv4-address? inet:ipv4-address 379 | +--:(ipv6-address) 380 | +--rw ipv6-address? inet:ipv6-address 381 +--rw MTU? uint32 382 +--rw ttl? uint8 383 +--rw priority? uint8 384 +--rw (Multiplexing)? 385 | +--:(multiplexing-null) 386 | +--rw multiplexing-null? empty 387 +--rw (QoS)? 388 | +--:(Qos-null) 389 | +--rw QoS-null? empty 390 +--rw (Security)? 391 | +--:(Security-null) 392 | +--rw Security-null? empty 393 +--rw resource 394 +--rw bandwidth? uint32 395 +--rw MaxRate? uint32 396 +--rw MaxBurstSize? uint32 397 +--rw ExBurstSize? uint32 398 +--rw Frequency? uint32 399 +--rw weight? uint32 400 augment /if:interfaces-state: 401 +--ro tunnel-state 402 +--ro tunnel* [tunnel-name] 403 +--ro tunnel-name leafref 404 +--ro admin-status? enumeration 405 +--ro oper-status? enumeration 406 +--ro MTU? uint32 407 +--ro packets-input? yang:counter64 408 +--ro input-errors? yang:counter64 409 +--ro packets-output? yang:counter64 410 +--ro output-errors? yang:counter64 411 +--ro input-utility-rate? yang:counter64 412 +--ro output-utility-rate? yang:counter64 413 +--ro transmitted-bytes? yang:counter64 415 data hierarchy of TUNNEL 417 6. Tunnel YANG Module 419 file "ietf-tunnel.yang" 420 module gen-tunnel { 421 namespace "http://example.com/gen-tunnel"; 422 prefix "tunnel"; 423 import ietf-yang-types { prefix yang;} 424 import ietf-inet-types { prefix inet;} 425 import ietf-interfaces { 426 prefix if; 427 } 428 import iana-if-type { 429 prefix ianaift; 430 } 431 organization "IETF Netmod Working Group"; 432 contact 433 "wangzitao@huawei.com"; 434 description 435 "This module defines ietf tunnel yang data model"; 437 revision 2015-06-09 { 438 description 439 "Initial revision. - 01 version"; 440 reference "draft-wwz-netmod-yang-tunnel-model-00"; 441 } 442 identity technology-types { 443 description 444 "this is the base identity of technology types which are 445 IP, GRE, MPLS, etc"; 446 } 448 identity ipv4 { 449 base technology-types; 450 description 451 "technology of ipv4"; 452 } 454 identity ipv6 { 455 base technology-types; 456 description 457 "technology of ipv6"; 458 } 460 identity encapsulation-type{ 461 description 462 "The encapsulation method used by a tunnel 463 which are direct, GRE, 6to4, 6over4, IPsec, etc."; 464 } 466 identity direct{ 467 base encapsulation-type; 468 description 469 "no intermediate header."; 470 } 472 identity endpoint-type{ 473 description 474 "this is the base identity of tunnel type which are CE, PE, etc."; 475 } 476 augment "/if:interfaces/if:interface" { 477 when "if:type = 'ianaift:tunnel'"; 478 description 479 "Parameters for configuring tunnel on interfaces."; 480 container tunnel-configuration{ 481 description 482 "tunnel configuration model."; 483 leaf base-interface { 484 type if:interface-ref; 485 must "/if:interfaces/if:interface[if:name = current()]" { 486 description 487 "The base interface."; 488 } 489 description 490 "The base interface."; 491 } 493 leaf tunnel-name{ 494 type string; 495 description 496 "this name can be used to distinguish different tunnel"; 497 } 499 leaf ip-address{ 500 type yang:phys-address; 501 description 502 "ip-address of this tunnel interface"; 503 } 504 leaf technology{ 505 type identityref{ 506 base technology-types; 507 } 508 description 509 "this leaf can be used to indicate different technologies 510 such as IP, GRE, MPLS, etc"; 511 } 513 leaf encapsulation-method{ 514 type identityref{ 515 base encapsulation-type; 516 } 517 description 518 "The encapsulation method used by a tunnel."; 519 } 521 leaf endpoint-type{ 522 type identityref{ 523 base endpoint-type; 524 } 525 description 526 "The endpoint type."; 527 } 529 choice signaling-protocol-type { 530 case signaling-protocol-null { 531 description 532 "this is a placeholder when no signaling protocol 534 is needed"; 535 leaf signaling-null { 536 type empty; 537 description 538 "there is no signaling protocol define, 539 it will be defined in 540 technology specific model."; 541 } 542 } 543 description 544 "signaling protocol type"; 545 } 547 container tunnel-source{ 548 description 549 "parameters of source tunnel"; 550 choice tunnel-source { 551 case interface{ 552 leaf interface-type{ 553 type leafref{ 554 path "/if:interfaces/if:interface" 555 +"/if:type"; 556 } 557 description 558 "interface type"; 559 } 560 leaf interface{ 561 type if:interface-ref; 562 description 563 "Interface"; 564 } 565 } 566 case ipv4-address { 567 leaf ipv4-address { 568 type inet:ipv4-address; 569 description 570 "Ipv4 Address"; 571 } 572 description 573 "Ip Address based node Addressing."; 574 } 575 case ipv6-address { 576 leaf ipv6-address { 577 type inet:ipv6-address; 578 description 579 "Ipv6 Address"; 581 } 582 description 583 "ipv6 Address based node Addressing."; 584 } 585 description 586 "node Addressing."; 587 } 588 } 590 container tunnel-destination{ 591 description 592 "Data nodes for the operational state of tunnel on interfaces"; 593 choice tunnel-destination { 594 case interface{ 595 leaf interface-type{ 596 type leafref{ 597 path "/if:interfaces/if:interface" 598 +"/if:type"; 599 } 600 description 601 "interface type"; 602 } 603 leaf interface{ 604 type if:interface-ref; 605 description 606 "Interface"; 607 } 608 } 609 case ipv4-address { 610 leaf ipv4-address { 611 type inet:ipv4-address; 612 description 613 "Ipv4 Address"; 614 } 615 description 616 "Ip Address based node Addressing."; 617 } 618 case ipv6-address { 619 leaf ipv6-address { 620 type inet:ipv6-address; 621 description 622 "Ipv6 Address"; 623 } 624 description 625 "ipv6 Address based node Addressing."; 626 } 627 description 628 "node Addressing."; 630 } 631 } 633 leaf MTU{ 634 type uint32; 635 description 636 "Maximum Transmission Unit"; 637 } 639 leaf ttl { 640 type uint8; 641 default "255"; 642 description 643 "Time to Live"; 644 } 646 leaf priority { 647 type uint8; 648 description 649 "priority"; 650 } 652 choice Multiplexing{ 653 description 654 "multiplexing parameters"; 655 case multiplexing-null{ 656 description 657 "this is a placeholder when no multiplexing is needed"; 658 leaf multiplexing-null{ 659 type empty; 660 description 661 "there is no multiplexing define, it will be defined 662 in technology specific model."; 663 } 664 } 665 } 667 choice QoS{ 668 description 669 "QoS Parameters"; 670 case Qos-null{ 671 description 672 "this is a placeholder when no QoS is needed"; 673 leaf QoS-null{ 674 type empty; 675 description 676 "there is no QoS define, it will be defined 677 in technology specific model."; 679 } 680 } 681 } 683 choice Security{ 684 description 685 "security parameters"; 686 case Security-null{ 687 description 688 "this is a placeholder when no Security is needed"; 689 leaf Security-null{ 690 type empty; 691 description 692 "there is no Security define, it will be defined 693 in technology specific model."; 694 } 695 } 696 } 697 container resource{ 698 // if-feature resource-support; 699 description 700 "this container is used to indicate the resources required 701 for a tunnel."; 703 leaf bandwidth{ 704 type uint32; 705 description 706 "the bandwidth of tunnel"; 707 } 709 leaf MaxRate{ 710 type uint32; 711 description 712 "The maximum rate in bits/second."; 713 } 715 leaf MaxBurstSize{ 716 type uint32; 717 description 718 "The maximum burst size in bytes."; 719 } 721 leaf ExBurstSize{ 722 type uint32; 723 description 724 "The Excess burst size in bytes."; 725 } 726 leaf Frequency{ 727 type uint32; 728 description 729 "The granularity of the availability of committed 730 rate."; 731 } 733 leaf weight{ 734 type uint32; 735 description 736 "The relative weight for using excess bandwidth above 737 its committed rate."; 738 } 739 } 740 } 741 } 742 augment "/if:interfaces-state" { 743 when "if:type = 'ianaift:tunnel'"; 744 description 745 "Data nodes for the operational state of tunnel on interfaces"; 746 container tunnel-state{ 747 config false; 748 description 749 "define the state of this tunnel"; 750 list tunnel{ 751 key "tunnel-name"; 752 description 753 "The list of tunnel on the interface"; 754 leaf tunnel-name{ 755 type leafref{ 756 path "/if:interfaces/if:interface" 757 +"/tunnel:tunnel-configuration/tunnel:tunnel-name"; 758 } 759 description 760 "this leaf can be used to distinguish different tunnels"; 761 } 763 leaf admin-status{ 764 type enumeration { 765 enum up { 766 value 1; 767 description 768 "Ready to pass packets."; 769 } 770 enum down { 771 value 2; 772 description 773 "Not ready to pass packets and not in some test mode."; 775 } 776 enum testing { 777 value 3; 778 description 779 "In some test mode."; 780 } 781 } 782 description 783 "The desired state of the tunnel."; 784 } 786 leaf oper-status { 787 type enumeration { 788 enum up { 789 value 1; 790 description 791 "Ready to pass packets."; 792 } 793 enum down { 794 value 2; 795 description 796 "The tunnel does not pass any packets."; 797 } 798 enum testing { 799 value 3; 800 description 801 "In some test mode. No operational packets can 802 be passed."; 803 } 804 enum unknown { 805 value 4; 806 description 807 "Status cannot be determined for some reason."; 808 } 809 enum dormant { 810 value 5; 811 description 812 "Waiting for some external event."; 813 } 814 enum not-present { 815 value 6; 816 description 817 "Some component (typically hardware) is missing."; 818 } 819 enum lower-layer-down { 820 value 7; 821 description 822 "Down due to state of lower-layer tunnel(s)."; 824 } 825 } 826 description 827 "The current operational state of the tunnel."; 828 } 830 leaf MTU{ 831 type uint32; 832 description 833 "Maximum Transmit Uint"; 834 } 836 leaf packets-input{ 837 type yang:counter64; 838 description 839 "Number of packets input."; 840 } 842 leaf input-errors{ 843 type yang:counter64; 844 description 845 "Number of input packets dropped because of errors or for 846 other reasons."; 847 } 849 leaf packets-output{ 850 type yang:counter64; 851 description 852 "Number of packets output."; 853 } 855 leaf output-errors{ 856 type yang:counter64; 857 description 858 "Number of output packets dropped because of errors or for 859 other reasons."; 860 } 862 leaf input-utility-rate{ 863 type yang:counter64; 864 description 865 "input utility rate."; 866 } 868 leaf output-utility-rate{ 869 type yang:counter64; 870 description 871 "output utility rate."; 873 } 875 leaf bytes{ 876 type yang:counter64; 877 description 878 "Number of bytes forwarded by the tunnel."; 879 } 880 } 881 } 882 } 883 } 885 887 7. Security Considerations 889 The YANG module defined in this memo is designed to be accessed via 890 the NETCONF protocol [RFC6241] . The lowest NETCONF layer is the 891 secure transport layer and the mandatory-to-implement secure 892 transport is SSH [RFC6242] . The NETCONF access control model 893 [RFC6536] provides the means to restrict access for particular 894 NETCONF users to a pre-configured subset of all available NETCONF 895 protocol operations and content. 897 8. IANA Considerations 899 This document registers a URI in the IETF XML registry [RFC3688] . 900 Following the format in RFC 3688, the following registration is 901 requested to be made: 903 URI: urn:ietf:params:xml:ns:yang:ietf-tunnel 905 Registrant Contact: The IESG. 907 XML: N/A, the requested URI is an XML namespace. 909 This document registers a YANG module in the YANG Module Names 910 registry [RFC6020]. 912 name: ietf-tunnel 914 namespace:urn:ietf:params:xml:ns:yang:ietf-tunnel 916 prefix: itun reference: RFC XXXX 918 9. Normative References 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, March 1997. 923 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 924 Network Configuration Protocol (NETCONF)", RFC 6020, 925 October 2010. 927 Authors' Addresses 929 Aijun Wang 930 China Telecom 931 No.118,Xizhimenneidajie,Xicheng District 932 Beijing 100035 933 China 935 Email: wangaj@ctbri.com.cn 937 Zitao Wang 938 Huawei Technologies,Co.,Ltd 939 101 Software Avenue, Yuhua District 940 Nanjing 210012 941 China 943 Email: wangzitao@huawei.com 945 Yan Zhuang 946 Huawei 947 101 Software Avenue, Yuhua District 948 Nanjing, Jiangsu 210012 949 China 951 Email: zhuangyan.zhuang@huawei.com