idnits 2.17.1 draft-ietf-softwire-iftunnel-04.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 -- The document date (April 3, 2019) is 1822 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 (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire Working Group M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track I. Farrer 5 Expires: October 5, 2019 Deutsche Telekom AG 6 R. Asati 7 Cisco Systems, Inc. 8 April 3, 2019 10 Tunnel Interface Types YANG Module 11 draft-ietf-softwire-iftunnel-04 13 Abstract 15 This document specifies a YANG module containing a collection of IANA 16 maintained YANG identities, used as interface types for tunnel 17 interfaces. 19 Editorial Note (To be removed by RFC Editor) 21 Please update these statements in the document with the RFC number to 22 be assigned to this document: 24 o "This version of this YANG module is part of RFC XXXX;" 26 o "RFC XXXX: Tunnel Interface Types YANG Module"; 28 o "reference: RFC XXXX" 30 o "...must be updated as defined in RFCXXXX." 32 Please update the "revision" date of the YANG modules. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 5, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. IANA Tunnel Type YANG Module . . . . . . . . . . . . . . . . 3 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.2. Updates to the IANA tunnelType Table . . . . . . . . . . 8 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 6.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Appendix A. Example Usage . . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 This document specifies the initial version of the iana-tunnel-type 83 YANG module identifying tunnel interface types. The module reflects 84 IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY]. The latest 85 revision of this module can be obtained from the IANA web site. 87 Tunnel-specific extensions may be added to the Interface module 88 [RFC8343] as a function of the tunnel type. An example of this is 89 provided in Appendix A. It is not the intention of this document to 90 define tunnel-specific extensions for every tunnel encapsulation 91 technology; those are discussed in dedicated documents such as 92 [I-D.ietf-softwire-yang]. 94 This document uses the common YANG types defined in [RFC6991] and 95 adopts the Network Management Datastore Architecture (NMDA 96 [RFC8342]). 98 The terminology for describing YANG modules is defined in [RFC7950]. 99 The meanings of the symbols used in tree diagrams are defined in 100 [RFC8340]. 102 2. IANA Tunnel Type YANG Module 104 The iana-tunnel-type module imports the 'iana-if-type' module defined 105 in [RFC7224]. 107 The initial version of the module includes tunnels types defined in 108 [RFC4087], [RFC7856], [RFC7870], and [RFC6346]. 110 file "iana-tunnel-type@2019-04-04.yang" 112 module iana-tunnel-type { 113 yang-version 1.1; 114 namespace "urn:ietf:params:xml:ns:yang:iana-tunnel-type"; 115 prefix iana-tunnel-type; 117 import iana-if-type { 118 prefix ift; 119 reference 120 "RFC 7224: IANA Interface Type YANG Module"; 121 } 123 organization 124 "IANA"; 125 contact 126 "Internet Assigned Numbers Authority 128 Postal: ICANN 129 12025 Waterfront Drive, Suite 300 130 Los Angeles, CA 90094-2536 131 United States of America 132 Tel: +1 310 301 5800 133 "; 135 description 136 "This module contains a collection of YANG identities defined 137 by IANA and used as interface types for tunnel interfaces. 139 Copyright (c) 2019 IETF Trust and the persons identified as 140 authors of the code. All rights reserved. 142 Redistribution and use in source and binary forms, with or 143 without modification, is permitted pursuant to, and subject 144 to the license terms contained in, the Simplified BSD License 145 set forth in Section 4.c of the IETF Trust's Legal Provisions 146 Relating to IETF Documents 147 (http://trustee.ietf.org/license-info). 149 This version of this YANG module is part of RFC XXXX; see 150 the RFC itself for full legal notices."; 152 revision 2019-04-04 { 153 description 154 "Initial revision."; 155 reference 156 "RFC XXXX: Tunnel Interface Types YANG Module"; 157 } 158 identity other { 159 base ift:tunnel; 160 description 161 "None of the following values."; 162 reference 163 "RFC 4087: IP Tunnel MIB"; 164 } 165 identity direct { 166 base ift:tunnel; 167 description 168 "No intermediate header."; 169 reference 170 "RFC 2003: IP Encapsulation within IP 171 RFC 4213: Basic Transition Mechanisms for IPv6 Hosts 172 and Routers"; 173 } 174 identity gre { 175 base ift:tunnel; 176 description 177 "GRE encapsulation."; 178 reference 179 "RFC 1701: Generic Routing Encapsulation (GRE) 180 RFC 1702: Generic Routing Encapsulation over IPv4 networks 181 RFC 7676: IPv6 Support for Generic Routing Encapsulation 182 (GRE)"; 183 } 184 identity minimal { 185 base ift:tunnel; 186 description 187 "Minimal encapsulation."; 188 reference 189 "RFC 2004: Minimal Encapsulation within IP"; 191 } 192 identity l2tp { 193 base ift:tunnel; 194 description 195 "L2TP encapsulation."; 196 reference 197 "RFC 2661: Layer Two Tunneling Protocol (L2TP)"; 198 } 199 identity pptp { 200 base ift:tunnel; 201 description 202 "PPTP encapsulation."; 203 reference 204 "RFC 2637: Point-to-Point Tunneling Protocol (PPTP)"; 205 } 206 identity l2f { 207 base ift:tunnel; 208 description 209 "L2F encapsulation."; 210 reference 211 "RFC 2341: Cisco Layer Two Forwarding (Protocol) (L2F)"; 212 } 213 identity udp { 214 base ift:tunnel; 215 description 216 "UDP encapsulation."; 217 reference 218 "Section 3.1.11 of RFC 8085"; 219 } 220 identity atmp { 221 base ift:tunnel; 222 description 223 "ATMP encapsulation."; 224 reference 225 "RFC 2107: Ascend Tunnel Management Protocol - ATMP"; 226 } 227 identity msdp { 228 base ift:tunnel; 229 description 230 "MSDP encapsulation."; 231 reference 232 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 233 } 234 identity sixtofour { 235 base ift:tunnel; 236 description 237 "6to4 encapsulation."; 238 reference 239 "RFC 3056: Connection of IPv6 Domains via IPv4 Clouds"; 240 } 241 identity sixoverfour { 242 base ift:tunnel; 243 description 244 "6over4 encapsulation."; 245 reference 246 "RFC 2529: Transmission of IPv6 over IPv4 Domains without 247 Explicit Tunnels"; 248 } 249 identity isatap { 250 base ift:tunnel; 251 description 252 "ISATAP encapsulation."; 253 reference 254 "RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol 255 (ISATAP)"; 256 } 257 identity teredo { 258 base ift:tunnel; 259 description 260 "Teredo encapsulation."; 261 reference 262 "RFC 4380: Teredo- Tunneling IPv6 over UDP through 263 Network Address Translations (NATs)"; 264 } 265 identity iphttps { 266 base ift:tunnel; 267 description 268 "IP over HTTPS (IP-HTTPS) Tunneling Protocol."; 269 reference 270 "Microsoft Corporation, IP over HTTPS (IP-HTTPS) Tunneling 271 Protocol Specification, 272 https://msdn.microsoft.com/en-us/library/dd358571.aspx"; 273 } 274 identity softwiremesh { 275 base ift:tunnel; 276 description 277 "softwire mesh tunnel."; 278 reference 279 "RFC 5565: Softwire Mesh Framework"; 280 } 281 identity dslite { 282 base ift:tunnel; 283 description 284 "DS-Lite tunnel."; 285 reference 286 "RFC 6333: Dual-Stack Lite Broadband Deployments Following 287 IPv4 Exhaustion"; 288 } 289 identity aplusp { 290 base ift:tunnel; 291 description 292 "A+P encapsulation."; 293 reference 294 "RFC 6346: The Address plus Port (A+P) Approach to the IPv4 295 Address Shortage"; 296 } 297 } 298 300 3. Security Considerations 302 The YANG module specified in this document defines a schema for data 303 that is designed to be accessed via network management protocols such 304 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 305 is the secure transport layer, and the mandatory-to-implement secure 306 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 307 is HTTPS, and the mandatory-to-implement secure transport is TLS 308 [RFC8446]. 310 The Network Configuration Access Control Model (NACM) [RFC8341] 311 provides the means to restrict access for particular NETCONF or 312 RESTCONF users to a preconfigured subset of all available NETCONF or 313 RESTCONF protocol operations and content. 315 The module defined in this document defines YANG identities for the 316 iana-tunnel-types registry. These identies are intended to be 317 referenced by other YANG modules, and by themselves do not expose any 318 nodes which are writable, contain read-only state, or RPCs. As such, 319 there are no additional security issues to be considered relating to 320 the module defined in this document. 322 4. IANA Considerations 324 4.1. YANG Module 326 This document requests IANA to register the following URI in the "ns" 327 subregistry within the "IETF XML Registry" [RFC3688]: 329 URI: urn:ietf:params:xml:ns:yang:iana-tunnel-type 330 Registrant Contact: IANA. 331 XML: N/A; the requested URI is an XML namespace. 333 This document requests IANA to register the following following YANG 334 module in the "YANG Module Names" subregistry [RFC7950] within the 335 "YANG Parameters" registry. 337 Name: iana-tunnel-type 338 Namespace: urn:ietf:params:xml:ns:yang:iana-tunnel-type 339 Prefix: iana-tunnel-type 340 Reference: RFC XXXX 342 This document defines the initial version of the IANA-maintained 343 iana-tunnel-type YANG module. IANA is requested to add this note: 345 Tunnel type values must not be directly added to the iana-tunnel- 346 type YANG module. They must instead be respectively added to the 347 "tunnelType" sub-registry (under the "ifType definitions" 348 registry). 350 When a tunnel type is added to the "tunnelType" sub-registry, a new 351 "identity" statement must be added to the iana-tunnel-type YANG 352 module. The name of the "identity" is the same as the corresponding 353 enumeration in the IANAifType-MIB (i.e., IANAtunnelType). The 354 "identity" statement should have the following sub-statements 355 defined: 357 "base": Contains the name assigned to the tunnel type, in 358 lowercase. 360 "description": Replicates the description from the registry. 362 "reference": Replicates the reference from the registry and add the 363 title of the document. 365 Unassigned or reserved values are not present in the module. 367 When the iana-tunnel-type YANG module is updated, a new "revision" 368 statement must be added in front of the existing revision statements. 370 IANA is requested to add this note to "tunnelType" sub-registry: 372 When this registry is modified, the YANG module iana-tunnel-type 373 must be updated as defined in RFCXXXX. 375 4.2. Updates to the IANA tunnelType Table 377 This document requests IANA to update the following entries available 378 at https://www.iana.org/assignments/smi-numbers/smi- 379 numbers.xhtml#smi-numbers-6: 381 OLD: 383 Decimal Name Description References 384 2 direct no intermediate header [RFC4087] 385 3 gre GRE encapsulation [RFC4087] 386 4 minimal Minimal encapsulation [RFC4087] 387 5 l2tp L2TP encapsulation [RFC4087] 388 6 pptp PPTP encapsulation [RFC4087] 389 7 l2f L2F encapsulation [RFC4087] 390 8 udp UDP encapsulation [RFC4087] 391 9 atmp ATMP encapsulation [RFC4087] 392 10 msdp MSDP encapsulation [RFC4087] 393 11 sixToFour 6to4 encapsulation [RFC4087] 394 12 sixOverFour 6over4 encapsulation [RFC4087] 395 13 isatap ISATAP encapsulation [RFC4087] 396 14 teredo Teredo encapsulation [RFC4087] 397 16 softwireMesh softwire mesh tunnel [RFC7856] 398 17 dsLite DS-Lite tunnel [RFC7870] 400 NEW: 402 Decimal Name Description References 403 2 direct no intermediate header [RFC2003] 404 [RFC4213] 405 3 gre GRE encapsulation [RFC1701] 406 [RFC1702] 407 [RFC7676] 408 4 minimal Minimal encapsulation [RFC2004] 409 5 l2tp L2TP encapsulation [RFC2661] 410 6 pptp PPTP encapsulation [RFC2637] 411 7 l2f L2F encapsulation [RFC2341] 412 8 udp UDP encapsulation [RFC8085] 413 9 atmp ATMP encapsulation [RFC2107] 414 10 msdp MSDP encapsulation [RFC3618] 415 11 sixToFour 6to4 encapsulation [RFC3056] 416 12 sixOverFour 6over4 encapsulation [RFC2529] 417 13 isatap ISATAP encapsulation [RFC5214] 418 14 teredo Teredo encapsulation [RFC4380] 419 16 softwireMesh softwire mesh tunnel [RFC5565] 420 17 dsLite DS-Lite tunnel [RFC6333] 422 5. Acknowledgements 424 Special thanks to Tom Petch and Martin Bjorklund for the detailed 425 review and suggestions. 427 Thanks to Andy Bierman for the Yangdoctors review. 429 6. References 431 6.1. Normative References 433 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 434 DOI 10.17487/RFC3688, January 2004, 435 . 437 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 438 and A. Bierman, Ed., "Network Configuration Protocol 439 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 440 . 442 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 443 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 444 . 446 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 447 RFC 6991, DOI 10.17487/RFC6991, July 2013, 448 . 450 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 451 RFC 7224, DOI 10.17487/RFC7224, May 2014, 452 . 454 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 455 RFC 7950, DOI 10.17487/RFC7950, August 2016, 456 . 458 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 459 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 460 . 462 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 463 Access Control Model", STD 91, RFC 8341, 464 DOI 10.17487/RFC8341, March 2018, 465 . 467 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 468 and R. Wilton, "Network Management Datastore Architecture 469 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 470 . 472 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 473 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 474 . 476 6.2. Informative References 478 [I-D.ietf-softwire-yang] 479 Farrer, I. and M. Boucadair, "YANG Modules for IPv4-in- 480 IPv6 Address plus Port (A+P) Softwires", draft-ietf- 481 softwire-yang-16 (work in progress), January 2019. 483 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 484 Routing Encapsulation (GRE)", RFC 1701, 485 DOI 10.17487/RFC1701, October 1994, 486 . 488 [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 489 Routing Encapsulation over IPv4 networks", RFC 1702, 490 DOI 10.17487/RFC1702, October 1994, 491 . 493 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 494 DOI 10.17487/RFC2003, October 1996, 495 . 497 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 498 DOI 10.17487/RFC2004, October 1996, 499 . 501 [RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", 502 RFC 2107, DOI 10.17487/RFC2107, February 1997, 503 . 505 [RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer 506 Two Forwarding (Protocol) "L2F"", RFC 2341, 507 DOI 10.17487/RFC2341, May 1998, 508 . 510 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 511 Domains without Explicit Tunnels", RFC 2529, 512 DOI 10.17487/RFC2529, March 1999, 513 . 515 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 516 W., and G. Zorn, "Point-to-Point Tunneling Protocol 517 (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, 518 . 520 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 521 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 522 RFC 2661, DOI 10.17487/RFC2661, August 1999, 523 . 525 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 526 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 527 2001, . 529 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 530 Discovery Protocol (MSDP)", RFC 3618, 531 DOI 10.17487/RFC3618, October 2003, 532 . 534 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, 535 DOI 10.17487/RFC4087, June 2005, 536 . 538 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 539 for IPv6 Hosts and Routers", RFC 4213, 540 DOI 10.17487/RFC4213, October 2005, 541 . 543 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 544 Network Address Translations (NATs)", RFC 4380, 545 DOI 10.17487/RFC4380, February 2006, 546 . 548 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 549 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 550 DOI 10.17487/RFC5214, March 2008, 551 . 553 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 554 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 555 . 557 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 558 Stack Lite Broadband Deployments Following IPv4 559 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 560 . 562 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 563 the IPv4 Address Shortage", RFC 6346, 564 DOI 10.17487/RFC6346, August 2011, 565 . 567 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 568 for Generic Routing Encapsulation (GRE)", RFC 7676, 569 DOI 10.17487/RFC7676, October 2015, 570 . 572 [RFC7856] Cui, Y., Dong, J., Wu, P., Xu, M., and A. Yla-Jaaski, 573 "Softwire Mesh Management Information Base (MIB)", 574 RFC 7856, DOI 10.17487/RFC7856, May 2016, 575 . 577 [RFC7870] Fu, Y., Jiang, S., Dong, J., and Y. Chen, "Dual-Stack Lite 578 (DS-Lite) Management Information Base (MIB) for Address 579 Family Transition Routers (AFTRs)", RFC 7870, 580 DOI 10.17487/RFC7870, June 2016, 581 . 583 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 584 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 585 March 2017, . 587 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 588 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 589 . 591 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 592 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 593 . 595 [TUNNELTYPE-IANA-REGISTRY] 596 Internet Assigned Numbers Authority, "tunnelType 597 Definitions", . 600 Appendix A. Example Usage 602 The following example illustrates how the Interface YANG module can 603 be augmented with tunnel-specific paramters. In this example, the 604 module is augmented with a 'remote-endpoint' for the tunnel. A tree 605 structure is provided below: 607 module: example-iftunnel-extension 608 augment /if:interfaces/if:interface: 609 +--rw remote-endpoint? inet:ipv6-address 611 The 'extension-example' module imports the modules defined in 612 [RFC6991] and [RFC8343] in addition to the "iana-tunnel-type" module 613 defined in this document. 615 module example-iftunnel-extension { 616 yang-version 1.1; 618 namespace "urn:ietf:params:xml:ns:yang:ietf-extension-example"; 619 prefix example; 620 import ietf-inet-types { 621 prefix inet; 622 reference 623 "Section 4 of RFC 6991"; 624 } 626 import ietf-interfaces { 627 prefix if; 628 reference 629 "RFC 8343: A YANG Data Model for Interface Management"; 630 } 632 import iana-tunnel-type { 633 prefix iana-tunnel-type; 634 reference 635 "RFC XXXX: A Tunnel Extension to the Interface Management 636 YANG Module"; 637 } 639 organization "IETF Softwire Working Group"; 641 contact 643 "WG Web: 644 WG List: 646 Author: Mohamed Boucadair 647 "; 649 description 650 "This is an example YANG module to extend the Interface YANG 651 module with tunnel-specific parameters. 653 Copyright (c) 2019 IETF Trust and the persons identified as 654 authors of the code. All rights reserved. 656 Redistribution and use in source and binary forms, with or 657 without modification, is permitted pursuant to, and subject 658 to the license terms contained in, the Simplified BSD License 659 set forth in Section 4.c of the IETF Trust's Legal Provisions 660 Relating to IETF Documents 661 (http://trustee.ietf.org/license-info). 663 This version of this YANG module is part of RFC XXXX; see 664 the RFC itself for full legal notices."; 666 revision 2019-04-04 { 667 description 668 "Initial revision."; 669 reference 670 "RFC XXXX: Tunnel Interface Types YANG Module"; 671 } 673 augment "/if:interfaces/if:interface" { 674 when "derived-from(if:type, 'iana-tunnel-type:gre')"; 675 description 676 "Augments Interface module with specific tunnel parameters."; 678 leaf remote-endpoint { 679 type inet:ipv6-address; 680 description 681 "IPv6 address of the local GRE endpoint."; 682 } 683 } 684 } 686 Authors' Addresses 688 Mohamed Boucadair 689 Orange 690 Rennes 35000 691 France 693 Email: mohamed.boucadair@orange.com 695 Ian Farrer 696 Deutsche Telekom AG 697 CTO-ATI,Landgrabenweg 151 698 Bonn, NRW 53227 699 Germany 701 Email: ian.farrer@telekom.de 703 Rajiv Asati 704 Cisco Systems, Inc. 705 7025 Kit Creek Rd. 706 RTP, NC 27709 707 USA 709 Email: Rajiva@cisco.com