idnits 2.17.1 draft-ietf-softwire-iftunnel-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFCXXXX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 289 has weird spacing: '...dentity aplus...' -- The document date (January 15, 2019) is 1927 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: 'RFCXXXX' is mentioned on line 373, but not defined == Missing Reference: 'RFC4380' is mentioned on line 418, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'TUNNELTYPE-IANA-REGISTRY' == Outdated reference: A later version (-16) exists of draft-ietf-softwire-yang-15 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: July 19, 2019 Deutsche Telekom AG 6 R. Asati 7 Cisco Systems, Inc. 8 January 15, 2019 10 Tunnel Interface Types YANG Module 11 draft-ietf-softwire-iftunnel-02 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 [RFCXXXX] 32 Please update the "revision" date of the YANG module. 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 July 19, 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-01-10.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-01-10 { 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 6. References 429 6.1. Normative References 431 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 432 DOI 10.17487/RFC3688, January 2004, 433 . 435 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 436 and A. Bierman, Ed., "Network Configuration Protocol 437 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 438 . 440 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 441 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 442 . 444 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 445 RFC 6991, DOI 10.17487/RFC6991, July 2013, 446 . 448 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 449 RFC 7224, DOI 10.17487/RFC7224, May 2014, 450 . 452 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 453 RFC 7950, DOI 10.17487/RFC7950, August 2016, 454 . 456 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 457 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 458 . 460 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 461 Access Control Model", STD 91, RFC 8341, 462 DOI 10.17487/RFC8341, March 2018, 463 . 465 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 466 and R. Wilton, "Network Management Datastore Architecture 467 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 468 . 470 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 471 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 472 . 474 [TUNNELTYPE-IANA-REGISTRY] 475 Internet Assigned Numbers Authority, "tunnelType 476 Definitions", . 479 6.2. Informative References 481 [I-D.ietf-softwire-yang] 482 Farrer, I. and M. Boucadair, "YANG Modules for IPv4-in- 483 IPv6 Address plus Port (A+P) Softwires", draft-ietf- 484 softwire-yang-15 (work in progress), January 2019. 486 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 487 Routing Encapsulation (GRE)", RFC 1701, 488 DOI 10.17487/RFC1701, October 1994, 489 . 491 [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 492 Routing Encapsulation over IPv4 networks", RFC 1702, 493 DOI 10.17487/RFC1702, October 1994, 494 . 496 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 497 DOI 10.17487/RFC2003, October 1996, 498 . 500 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 501 DOI 10.17487/RFC2004, October 1996, 502 . 504 [RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", 505 RFC 2107, DOI 10.17487/RFC2107, February 1997, 506 . 508 [RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer 509 Two Forwarding (Protocol) "L2F"", RFC 2341, 510 DOI 10.17487/RFC2341, May 1998, 511 . 513 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 514 Domains without Explicit Tunnels", RFC 2529, 515 DOI 10.17487/RFC2529, March 1999, 516 . 518 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 519 W., and G. Zorn, "Point-to-Point Tunneling Protocol 520 (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, 521 . 523 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 524 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 525 RFC 2661, DOI 10.17487/RFC2661, August 1999, 526 . 528 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 529 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 530 2001, . 532 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 533 Discovery Protocol (MSDP)", RFC 3618, 534 DOI 10.17487/RFC3618, October 2003, 535 . 537 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, 538 DOI 10.17487/RFC4087, June 2005, 539 . 541 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 542 for IPv6 Hosts and Routers", RFC 4213, 543 DOI 10.17487/RFC4213, October 2005, 544 . 546 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 547 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 548 DOI 10.17487/RFC5214, March 2008, 549 . 551 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 552 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 553 . 555 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 556 Stack Lite Broadband Deployments Following IPv4 557 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 558 . 560 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 561 the IPv4 Address Shortage", RFC 6346, 562 DOI 10.17487/RFC6346, August 2011, 563 . 565 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 566 for Generic Routing Encapsulation (GRE)", RFC 7676, 567 DOI 10.17487/RFC7676, October 2015, 568 . 570 [RFC7856] Cui, Y., Dong, J., Wu, P., Xu, M., and A. Yla-Jaaski, 571 "Softwire Mesh Management Information Base (MIB)", 572 RFC 7856, DOI 10.17487/RFC7856, May 2016, 573 . 575 [RFC7870] Fu, Y., Jiang, S., Dong, J., and Y. Chen, "Dual-Stack Lite 576 (DS-Lite) Management Information Base (MIB) for Address 577 Family Transition Routers (AFTRs)", RFC 7870, 578 DOI 10.17487/RFC7870, June 2016, 579 . 581 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 582 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 583 March 2017, . 585 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 586 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 587 . 589 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 590 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 591 . 593 Appendix A. Example Usage 595 The following example illustrates how the Interface YANG module can 596 be augmented with tunnel-specific paramters. In this example, the 597 module is augmented with a 'remote-endpoint' for the tunnel. A tree 598 structure is provided below: 600 module: ietf-extension-example 601 augment /if:interfaces/if:interface: 602 +--rw remote-endpoint? inet:ipv6-address 604 The 'extension-example' module imports the modules defined in 605 [RFC6991] and [RFC8343] in addition to the "iana-tunnel-type" module 606 defined in this document. 608 file "ietf-extension-example@2019-01-10.yang" 610 module ietf-extension-example { 611 yang-version 1.1; 613 namespace "urn:ietf:params:xml:ns:yang:ietf-extension-example"; 614 prefix example; 616 import ietf-inet-types { 617 prefix inet; 618 reference 619 "Section 4 of RFC 6991"; 620 } 622 import ietf-interfaces { 623 prefix if; 624 reference 625 "RFC 8343: A YANG Data Model for Interface Management"; 626 } 628 import iana-tunnel-type { 629 prefix iana-tunnel-type; 630 reference 631 "RFC XXXX: A Tunnel Extension to the Interface Management 632 YANG Module"; 633 } 635 organization "IETF Softwire Working Group"; 637 contact 639 "WG Web: 640 WG List: 642 Author: Mohamed Boucadair 643 "; 645 description 646 "This is an example YANG module to extend the Interface YANG 647 module with tunnel-specific parameters. 649 Copyright (c) 2019 IETF Trust and the persons identified as 650 authors of the code. All rights reserved. 652 Redistribution and use in source and binary forms, with or 653 without modification, is permitted pursuant to, and subject 654 to the license terms contained in, the Simplified BSD License 655 set forth in Section 4.c of the IETF Trust's Legal Provisions 656 Relating to IETF Documents 657 (http://trustee.ietf.org/license-info). 659 This version of this YANG module is part of RFC XXXX; see 660 the RFC itself for full legal notices."; 662 revision 2019-01-10 { 663 description 664 "Initial revision."; 665 reference 666 "RFC XXXX: Tunnel Interface Types YANG Module"; 667 } 669 augment "/if:interfaces/if:interface" { 670 when "derived-from(if:type, 'iana-tunnel-type:gre')"; 671 description 672 "Augments Interface module with specific tunnel parameters."; 674 leaf remote-endpoint { 675 type inet:ipv6-address; 676 description 677 "IPv6 address of the local GRE endpoint."; 678 } 679 } 680 } 681 683 Authors' Addresses 685 Mohamed Boucadair 686 Orange 687 Rennes 35000 688 France 690 Email: mohamed.boucadair@orange.com 692 Ian Farrer 693 Deutsche Telekom AG 694 CTO-ATI,Landgrabenweg 151 695 Bonn, NRW 53227 696 Germany 698 Email: ian.farrer@telekom.de 700 Rajiv Asati 701 Cisco Systems, Inc. 702 7025 Kit Creek Rd. 703 RTP, NC 27709 704 USA 706 Email: Rajiva@cisco.com