idnits 2.17.1 draft-liu-intarea-ipipv4-tunnel-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 8 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2016) is 2854 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: 'RFC1853' is mentioned on line 123, but not defined == Missing Reference: 'RFC2003' is mentioned on line 123, but not defined == Missing Reference: 'RFC3056' is mentioned on line 123, but not defined == Missing Reference: 'RFC7223' is mentioned on line 184, but not defined ** Obsolete undefined reference: RFC 7223 (Obsoleted by RFC 8343) == Missing Reference: 'RFC6241' is mentioned on line 595, but not defined == Missing Reference: 'RFC6242' is mentioned on line 597, but not defined == Missing Reference: 'RFC6536' is mentioned on line 598, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 604, but not defined Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Liu 3 Internet-Draft A. Foldes 4 Intended status: Standards Track Ericsson 5 Expires: January 4, 2017 G. Zheng 6 Z. Wang 7 Y. Zhuang 8 Huawei 9 A. Wang 10 China Telecom 11 July 3, 2016 13 Yang Data Model for IPIPv4 Tunnel 14 draft-liu-intarea-ipipv4-tunnel-yang-02 16 Abstract 18 This document defines a YANG data model for the management of IP 19 based tunnels. The data model includes configuration data and state 20 data. In default format, it describes managed attributes used for 21 managing tunnels of IPv4 or IPv6 over IPv4 tunnels. And it can also 22 serve as a base model which can be augmented with technology-specific 23 details in other Ip based tunnel models. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 4, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Architecture of IP tunnel YANG Model . . . . . . . . . . . . 3 63 3. IP Tunnel Model Design . . . . . . . . . . . . . . . . . . . 4 64 3.1. Model Overview . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. IP Tunnel YANG Tree Diagrams . . . . . . . . . . . . . . 5 66 4. IP Tunnel YANG Data Model . . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 7. Normative References . . . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 An overview of tunnel is presented at [intarea-tunnel]. Over the 75 past several years, there has been a number of "tunneling" protocols 76 specified by the IETF. And this document defines a YANG data model 77 for the management of IP bases tunnels. In default format, it covers 78 the following tunnel types: 80 o IPv4 in IPv4, related concepts are defined in [RFC1853] 82 o IPv6 in IPv4 manual tunnel, related concepts are defined in 83 [RFC2003] 85 o IPv6 to IPv4 tunnel, related concepts are defined in [RFC3056] 87 And notice that this model provides a framework and some reusable 88 common attributes where technology-specific IP tunnel YANG models can 89 inherit constructs from it without needing to redefine them within 90 the sub-technology. Therefore it also can serve as a base model 91 which can be extended to include technology specific details. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 1.2. Tree Diagrams 101 A simplified graphical representation of the data model is used in 102 this document. The meaning of the symbols in these diagrams is as 103 follows: 105 o Brackets "[" and "]" enclose list keys. 107 o Abbreviations before data node names: "rw" means configuration 108 (read-write), and "ro" means state data (read-only). 110 o Symbols after data node names: "?" means an optional node, "!" 111 means a presence container, and "*" denotes a list and leaf-list. 113 o Parentheses enclose choice and case nodes, and case nodes are also 114 marked with a colon (":"). 116 o Ellipsis ("...") stands for contents of subtrees that are not 117 shown. 119 2. Architecture of IP tunnel YANG Model 121 In this document we define an IP based tunnel model, in default it 122 can describe the IPv6/4-in-IPv4 tunnels including IPv4 in IPv4 123 [RFC1853], IPv6 in IPv4 [RFC2003], IPv6 to IPv4 [RFC3056]. 125 Since some reusable common core attributes of ip tunnels are defined, 126 it can also provide an optional solution for extending to the other 127 IP-based tunnel models. The users of IP-based tunnel model can 128 according to following method to define other technologies specific 129 ip tunnel models: 131 o The IP based Tunnel YANG model can acts as the root for other 132 Tunnel YANG models. 134 o Augment the ip based tunnel model by adding the tunnel type is 135 defined as an identity that augments the base " ip-tunnel-type " 136 defined in the IP based model. 138 o Augment the ip based tunnel model by adding new data nodes with 139 technology specific parameters into proper anchor points of the ip 140 tunnel model. 142 Figure 1 depicts the relationship of different Tunnel YANG models to 143 the Ip Tunnel YANG Model. It can default support the IPv4-in-IPv4, 144 IPv6-in-IPv4, and IPv6-to-IPv4, and can also be extended to another 145 IP base tunnels encapsulation protocol. 147 +--------------------------+ 148 | | 149 | IP BASED TUNNEL YANG | 150 | | 151 +-------------+------------+ 152 | 153 | 154 +------------+-------+---------+---------------+ 155 | | | | augment 156 +--------------------------------------------+ | 157 | +-------+ +----+-------+ +---------+ | +--+--------+ 158 | | IPv4 | |IPv6 in IPv4| |IPv6 to IPv4 | | another | 159 | |in IPv4| | yang | | tunnel | | | IP tunnels| 160 | | yang | | | | yang | | | yang | 161 | +-------+ +------------+ +---------+ | +-----------+ 162 | default support | 163 | | 164 +--------------------------------------------+ 166 Relationship of technology specific TUNNEL YANG model to IP based 167 tunnel YANG model 169 3. IP Tunnel Model Design 171 3.1. Model Overview 173 This document defines the YANG model "ietf-ip-tunnel". It includes 174 two modules, one for configuration and one for state. At the top of 175 the Model there is Tunnels container for tunnel configuration data. 176 Multiple Tunnel lists keyed using tunnel name and tunnel type within 177 the Tunnels container. To correctly identify an ip based tunnel the 178 bind-interface, local-address, remote-address are defined under one 179 tunnel list. Notice that tunnels are handled by creating a logical 180 interface for each tunnel. Each logical interface (physical or 181 virtual) need to map to interface yang model [RFC7223]. To do so, in 182 this draft, the bind-interface are defined which with a leafref type 183 and it can be used pointing to the corresponding interface-name node 184 in the interface yang [RFC7223]. 186 The data model also includes read-only counter so that the tunnel 187 state can be read. 189 3.2. IP Tunnel YANG Tree Diagrams 191 The data model has the following tree diagram for the IP tunnels: 193 module: ietf-ip-tunnel 194 +--rw Tunnels 195 | +--rw Tunnel* [name type] 196 | +--rw name string 197 | +--rw type identityref 198 | +--rw local-address? inet:ip-address-no-zone 199 | +--rw remote-address? inet:ip-address-no-zone 200 | +--rw routing-instance? routing-instance-ref 201 | +--rw description? string 202 | +--rw bind-interface? if:interface-ref 203 | +--rw clear-df? empty 204 | +--rw shutdown? empty 205 | +--rw tmtu? uint16 206 | +--rw mirror-destination? string 207 | +--rw hop-limit? uint8 208 | +--rw tos? int8 209 +--ro tunnel-state 210 +--ro tunnels* 211 +--ro name? string 212 +--ro type? identityref 213 +--ro local-ip? inet:ip-address-no-zone 214 +--ro remote-ip? inet:ip-address-no-zone 215 +--ro (state)? 216 | +--:(up) 217 | | +--ro up? empty 218 | +--:(down) 219 | | +--ro down? empty 220 | +--:(shutdown) 221 | +--ro shutdown? empty 222 +--ro bind-interface? if:interface-state-ref 223 +--ro user-configured? boolean 224 +--ro routing-instance? routing-instance-ref 225 +--ro tmtu? uint16 226 +--ro clear-df? empty 227 +--ro down-reason? string 228 +--ro resolved-interface-name? string 229 +--ro hop-limit? uint32 230 +--ro tos? int32 231 augment /if:interfaces-state/if:interface: 232 +--ro tunnel-protocol? identityref 234 4. IP Tunnel YANG Data Model 236 file "ietf-ip-tunnel@2016-06-20.yang" 237 module ietf-ip-tunnel{ 239 namespace "urn:ietf:params:xml:ns:yang:ietf-ip-tunnel"; 240 prefix "iptnl"; 242 import ietf-interfaces { 243 prefix "if"; 244 } 246 import ietf-inet-types { 247 prefix inet; 248 } 250 import ietf-routing { 251 prefix "rt"; 252 } 254 import iana-if-type { 255 prefix ianaift; 256 } 258 organization 259 "IETF NETMOD (NETCONF Data Modeling Language) Working Group."; 261 contact 262 "Mandy.Liu@ericsson.com 263 Adam.Foldes@ericsson.com 264 zhengguangying@huawei.com"; 266 description 267 "This YANG model defines the configuration data 268 and operational state data for generic IPv4/6-in-IPv4 tunnel. 269 It includes the IPv4 in IPv4, 6-to-4, and IPv6 over IPv4 manual 270 tunnels."; 272 revision 2016-04-27 { 273 description 274 "Made model more generic in order to allow augmentation by e.g. 275 GRE tunnels."; 276 reference 277 "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; 278 } 279 revision 2016-03-11 { 280 description 281 "Collapsed all tunnel types into a single subtree based on 282 suggestions to more closely follow the IP Tunnel MIB."; 283 reference 284 "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; 285 } 286 revision 2015-10-14 { 287 description 288 "Update model based on comments."; 289 reference 290 "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; 291 } 293 revision 2015-07-20 { 294 description 295 "This version adds the following new items: 296 - hop-limit 297 - tos 298 - tunnel-type 299 This version changes 'ipv6to4-auto' to 'ipv6to4'"; 300 reference 301 "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; 302 } 304 revision 2015-05-27 { 305 description 306 "Initial revision."; 307 reference 308 "RFC XXXX: A YANG Data Model for IPv4 Tunnel."; 309 } 311 /* Identities */ 312 identity ip-tunnel-type { 313 description 314 "Base identity from which identities describing 315 IP tunnel types are derived."; 316 } 317 identity ip-ip { 318 base ip-tunnel-type; 319 description 320 "This identity represents IPv4-in-IPv4 tunnel type"; 321 } 322 identity ipv6v4-manual { 323 base ip-tunnel-type; 324 description 325 "This identity represents IPv6-to-IPv4 manual tunnel type"; 326 } 327 identity ipv6-to-v4 { 328 base ip-tunnel-type; 329 description 330 "This identity represents the 6-to-4 tunnel type"; 331 } 333 typedef routing-instance-ref { 334 type leafref { 335 path "/rt:routing/rt:routing-protocols/rt:routing-protocol/rt:name"; 336 } 337 description 338 "This type is used for leafs that reference a routing instance 339 configuration."; 340 } 342 /*Configuration Data*/ 343 container Tunnels{ 344 description 345 "Configuration data for tunnels."; 346 list Tunnel{ 347 key "name type"; 348 description 349 "Configuration data for tunnels."; 350 leaf name { 351 type string; 352 description 353 "Name of the tunnel."; 354 } 355 leaf type { 356 type identityref { 357 base ip-tunnel-type; 358 } 359 description "The encapsulation type of the tunnel."; 360 } 362 leaf routing-instance { 363 type routing-instance-ref; 364 description "The routing instance of the local address."; 365 } 366 uses tunnel-config-components; 367 } 368 } 370 /* Configuration data */ 371 grouping tunnel-config-components { 372 description 373 "Configuration data for all tunnels and subtunnels"; 374 leaf description { 375 type string { 376 length "1..255"; 378 } 379 description 380 "Textual description for a tunnel. Can be any "+ 381 "alphanumeric string, including spaces, not to exceed "+ 382 "255 ASCII characters."; 383 } 384 leaf bind-interface { 385 type if:interface-ref; 386 description 387 "Bind to an interface."; 388 } 389 leaf local-address { 390 type inet:ip-address-no-zone; 391 description "IP address of the local end of the tunnel."; 392 } 393 leaf remote-address { 394 when "type != ipv6-to-v4" { 395 description 396 "6-to-4 tunnels do not have a fixed remote endpoint."; 397 } 398 type inet:ip-address-no-zone; 399 description "IP address of the remote end of the tunnel."; 400 } 402 leaf clear-df { 403 type empty; 404 description 405 "If clear-df is absent, it means that fragmentation of 406 tunnel packets are permitted. If clear-df is present, 407 it means that fragmentation of tunnel packets are not 408 permitted."; 409 } 410 leaf shutdown { 411 type empty; 412 description 413 "Disable/enable the tunnel."; 414 } 415 leaf tmtu { 416 type uint16 { 417 range "256..16384"; 418 } 419 description 420 "Sets the Maximum Transmission Unit (MTU) size for 421 packets sent in a tunnel. The default MTU is the MTU 422 for the interface to which the tunnel is bound."; 423 } 424 leaf mirror-destination { 425 type string; 426 description 427 "Designate the name of a tunnel as a circuit 428 mirror destination. "; 429 } 430 leaf hop-limit { 431 type uint8 { 432 range "0|1..255"; 433 } 434 description 435 "The IPv4 TTL or IPv6 Hop Limit which is used in the 436 outer IP header. A value of 0 indicates that the value 437 is copied from the payload's header."; 438 } 439 leaf tos { 440 type int8 { 441 range "-1..63"; 442 } 443 description 444 "The method used to set the high 6 bits (the 445 differentiated services codepoint) of the IPv4 TOS or 446 IPv6 Traffic Class in the outer IP header. A value of -1 447 indicates that the bits are copied from the payload\u2019s 448 header. A value between 0 and 63 inclusive indicates 449 that the bit field is set to the indicated value."; 450 } 452 } 454 /*Operational state data*/ 455 grouping tunnel-oper-states { 456 description "Operational states of tunnels"; 457 choice state { 458 description "Choice of operational states"; 459 case up { 460 leaf up { 461 type empty; 462 description "The tunnel is up."; 463 } 464 } 465 case down { 466 leaf down { 467 type empty; 468 description "The tunnel is down."; 469 } 470 } 471 case shutdown { 472 leaf shutdown { 473 type empty; 474 description "The tunnel is shut down administratively."; 475 } 476 } 477 } 478 } 480 grouping tunnel-state-components { 481 description 482 "The basic tunnel information to be displayed."; 484 leaf name { 485 type string; 486 description 487 "Name of the tunnel."; 488 } 490 leaf type { 491 type identityref; 492 description 493 "The type of the tunnel."; 494 } 495 leaf local-ip { 496 type inet:ip-address-no-zone; 497 description 498 "IP address of the local end of the tunnel."; 499 } 500 leaf remote-ip { 501 type inet:ip-address-no-zone; 502 description 503 "IP address of the remote end of the tunnel."; 504 } 505 uses tunnel-oper-states; 506 leaf bind-interface { 507 type if:interface-state-ref; 508 description 509 "Bind to an interface."; 510 } 511 leaf user-configured { 512 type boolean; 513 description 514 "Indicate the tunnel is user-configured or dynamic. 515 False is for dynamic."; 516 } 517 leaf routing-instance { 518 type routing-instance-ref; 519 description 520 "Name of the reference routing instance. "; 521 } 522 leaf tmtu { 523 type uint16; 524 description 525 "The Maximum Transmission Unit (MTU) size for 526 packets sent in a tunnel."; 527 } 528 leaf clear-df { 529 type empty; 530 description 531 "Indicate that the DF bit is cleared."; 532 } 533 leaf down-reason { 534 type string; 535 description 536 "The reason of the tunnel is down."; 537 } 538 leaf resolved-interface-name{ 539 type string; 540 description 541 "The egress interface name of the tunnel."; 542 } 543 leaf hop-limit { 544 type uint32; 545 description 546 "The IPv4 TTL or IPv6 Hop Limit which is used in the outer IP 547 header. A value of 0 indicates that the calue is copied from 548 the payload's header."; 549 } 550 leaf tos { 551 type int32; 552 description 553 "The high 6 bits (the differentiated 554 services codepoint) of the IPv4 TOS or IPv6 Traffic Class in 555 the outer IP header. A value of -1 indicates that the bits 556 are copied from the payload\u2019s header. A value between 0 and 557 63 inclusive indicates that the bit field is set to the 558 indicated value."; 559 } 560 } 562 container tunnel-state { 563 config "false"; 564 description 565 "Contain the information currently configured tunnels."; 566 list tunnels { 567 description 568 "Operational state data of tunnels."; 569 uses tunnel-state-components; 571 } 572 } 574 //Augment operational state data of IP interfaces 575 augment "/if:interfaces-state/if:interface" { 576 when "if:type = 'ianaift:tunnel'" { 577 description 578 "Augment IP interface."; 579 } 580 description 581 "Augment operational state data of IP interfaces."; 582 leaf tunnel-protocol { 583 type identityref; 584 description 585 "Indicate the state of the IP tunnel interface."; 586 } 587 } 588 } 590 592 5. Security Considerations 594 The YANG module defined in this memo is designed to be accessed via 595 the NETCONF protocol [RFC6241] . The lowest NETCONF layer is the 596 secure transport layer and the mandatory-to-implement secure 597 transport is SSH [RFC6242] . The NETCONF access control model 598 [RFC6536] provides the means to restrict access for particular 599 NETCONF users to a pre-configured subset of all available NETCONF 600 protocol operations and content. 602 6. IANA Considerations 604 This document registers a URI in the IETF XML registry [RFC3688] . 605 Following the format in RFC 3688, the following registration is 606 requested to be made: 608 URI: urn:ietf:params:xml:ns:yang:ietf-ip-tunnel 610 Registrant Contact: The IESG. 612 XML: N/A, the requested URI is an XML namespace. 614 This document registers a YANG module in the YANG Module Names 615 registry [RFC6020]. 617 name: ietf-tunnel 619 namespace:urn:ietf:params:xml:ns:yang:ietf-ip-tunnel 621 prefix: itun reference: RFC XXXX 623 7. Normative References 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, 627 DOI 10.17487/RFC2119, March 1997, 628 . 630 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 631 Network Configuration Protocol (NETCONF)", RFC 6020, 632 October 2010. 634 Authors' Addresses 636 Ying Liu 637 Ericsson 638 No.5 Lize East Street 639 Beijing 100102 640 China 642 Email: Mandy.Liu@ericsson.com 644 Adam Mate Foldes 645 Ericsson 646 300 Holger Way 647 San Jose CA 95134 648 USA 650 Email: Adam.Foldes@ericsson.com 652 Guangying Zheng 653 Huawei Technologies,Co.,Ltd 654 101 Software Avenue, Yuhua District 655 Nanjing 210012 656 China 658 Email: zhengguangying@huawei.com 659 Zitao Wang 660 Huawei Technologies,Co.,Ltd 661 101 Software Avenue, Yuhua District 662 Nanjing 210012 663 China 665 Email: wangzitao@huawei.com 667 Yan Zhuang 668 Huawei 669 101 Software Avenue, Yuhua District 670 Nanjing, Jiangsu 210012 671 China 673 Email: zhuangyan.zhuang@huawei.com 675 Aijun Wang 676 China Telecom 677 No.118,Xizhimenneidajie,Xicheng District 678 Beijing 100035 679 China 681 Email: wangaj@ctbri.com.cn