idnits 2.17.1 draft-zheng-intarea-gre-yang-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 21, 2016) is 3017 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) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Zheng, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track C. Pignataro 5 Expires: July 24, 2016 R. Penno 6 Cisco Systems, Inc. 7 Z. Wang 8 Huawei Technologies 9 January 21, 2016 11 Yang Data Model for Generic Routing Encapsulation (GRE) 12 draft-zheng-intarea-gre-yang-01.txt 14 Abstract 16 This document defines a YANG data model that can be used to configure 17 and manage Generic Routing Encapsulation (GRE). 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 July 24, 2016. 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 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 62 4. Data Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 3 63 5. GRE Yang Module . . . . . . . . . . . . . . . . . . . . . . . 3 64 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 10.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 Generic Routing Encapsulation (GRE) [RFC2784] specifies a protocol 76 for encapsulation of an arbitrary network layer protocol over another 77 arbitrary network layer protocol. YANG [RFC6020] is a data 78 definition language that was introduced to define the contents of a 79 conceptual data store that allows networked devices to be managed 80 using NETCONF [RFC6241]. This document defines a YANG data model 81 that can be used to configure and manage GRE. 83 The rest of this document is organized as follows. Section 2 84 presents the scope of this document. Section 3 provides the design 85 of the GRE configuration data model in details. Section 4 presents 86 the complete data hierarchy of GRE YANG model. Section 5 specifies 87 the YANG module and section 6 lists examples which conform to the 88 YANG module specified in this document. Finally, security 89 considerations are discussed in Section 7. 91 2. Scope 93 The fundemantel protocol of GRE is defined in [RFC2784]. [RFC2890] 94 describes extensions by which two fields, Key and Sequence Number, 95 can be optionally carried in the GRE Header. 96 [I-D.ietf-intarea-gre-ipv6] specifies GRE procedures for IPv6, used 97 as either the payload or delivery protocol. 98 [I-D.ietf-intarea-gre-mtu] describes how vendors have solved the GRE 99 fragmentation problem. These RFCs and documents are considered in 100 this Yang Module. 102 3. Design of the Data Model 104 This YANG data model is defined to be used to configure and manage 105 Generic Routing Encapsulation (GRE) . Under the top level container 106 is the list gre-tunnel, the leaf tunnel-name is used as the key for 107 the list. Under the list, nodes are defined to enable the tunnel 108 encapsulation configuration when either IPv4 or IPv6 is used as the 109 delivery protocol. Nodes are also defined to enable the checksum bit 110 set, tunnel fragmentation, Path MTU Discovery, Key and Key value set, 111 and Sequence Number configuration respectively, based on various GRE 112 RFCs and documents which are summarized in Section 2. 114 4. Data Hierarchy 116 The complete data hierarchy of GRE YANG model is presented below. 118 module: ietf-gre 119 +--rw gre-tunnel 120 +--rw gre-tunnel* [tunnel-name] 121 +--rw tunnel-name string 122 +--rw (delivery-protocol)? 123 | +--:(ipv4) 124 | | +--rw source-ipv4-address? inet:ipv4-address 125 | | +--rw dest-ipv4-address? inet:ipv4-address 126 | +--:(ipv6) 127 | +--rw source-ipv6-address? inet:ipv6-address 128 | +--rw dest-ipv6-address? inet:ipv6-address 129 +--rw pmtud-enable? boolean 130 +--rw fragmentation-enable? boolean 131 +--rw checksum-enable? boolean 132 +--rw key-enable? boolean 133 +--rw key? uint32 134 +--rw sequence-number-enable? boolean 136 5. GRE Yang Module 138 file "ietf-gre@2015-07-02.yang" 139 module ietf-gre { 140 namespace "urn:ietf:params:xml:ns:yang:ietf-gre"; 141 //namespace to be assigned by IANA 142 prefix "gre"; 143 import ietf-inet-types { 144 prefix "inet"; 145 } 146 organization "IETF INTAREA Working Group"; 147 contact "draft-zheng-intarea-gre-yang"; 148 description "This module contains the YANG definition for GRE 149 parameters as per RFC2784, RFC2890, 150 draft-ietf-intarea-gre-ipv6 and 151 draft-ietf-intarea-gre-mtu"; 152 revision "2015-07-02" { 153 description "Initial revision."; 154 reference "draft-zheng-intarea-gre-yang"; 155 } 157 container gre-tunnel { 158 description "Top level container"; 159 list gre-tunnel { 160 key "tunnel-name"; 161 description "GRE tunnel"; 162 leaf tunnel-name { 163 type string { 164 length "1..63"; 165 } 166 description "GRE tunnel name"; 167 } 168 choice delivery-protocol { 169 case ipv4 { 170 leaf source-ipv4-address { 171 type inet:ipv4-address; 172 description "Source IP address"; 173 } 174 leaf dest-ipv4-address { 175 type inet:ipv4-address; 176 description "Destination IP address"; 177 } 178 } 179 case ipv6 { 180 leaf source-ipv6-address { 181 type inet:ipv6-address; 182 description "Source IP address"; 183 } 184 leaf dest-ipv6-address { 185 type inet:ipv6-address; 186 description "Destination IP address"; 187 } 188 } 189 description "Delivery protocol"; 190 } 191 leaf pmtud-enable { 192 type boolean; 193 description "Enable tunnel PMTU discovery"; 194 } 195 leaf fragmentation-enable { 196 type boolean; 197 description "Enable delivery packets fragmentation"; 198 } 199 leaf checksum-enable { 200 type boolean; 201 description "Enable GRE tunnel checksum verification"; 202 } 203 leaf key-enable { 204 type boolean; 205 description "Enable optional GRE tunnel Key"; 206 } 207 leaf key { 208 when "/gre-tunnel/gre-tunnel/key-enable == 'true'" { 209 description "When key-enable is true"; 210 } 211 type uint32; 212 description "GRE tunnel key value"; 213 } 214 leaf sequence-number-enable { 215 type boolean; 216 description "Enable optional GRE tunnel Sequence Number"; 217 } 218 } 219 } 220 } 221 223 6. Examples 225 Examples of using Yang module to configure and manage GRE will be 226 given here in the update when the Yang module is stable. 228 7. Security Considerations 230 The configuration and state data defined in this document is designed 231 to be accessed via the NETCONF protocol [RFC6241]. The lowest 232 NETCONF layer is the secure transport layer and the mandatory-to- 233 implement secure transport is SSH [RFC6242]. The authors recommend 234 to implement the NETCONF access control model [RFC6536] to restrict 235 access for particular NETCONF users to a pre-configured subset of all 236 available NETCONF protocol operations and content. 238 There are a number of config true nodes defined in the YANG module 239 which are writable/creatable/deletable. These data nodes may be 240 considered sensitive or vulnerable in some network environments. 241 Write operations to these data nodes without proper protection can 242 have a negative effect on network operations. 244 8. IANA Considerations 246 The IANA is requested to assign a new namespace URI from the IETF XML 247 registry. 249 URI:TBA 251 9. Acknowledgements 253 We would also like to thank XXX. 255 10. References 257 10.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, 261 DOI 10.17487/RFC2119, March 1997, 262 . 264 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 265 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 266 DOI 10.17487/RFC2784, March 2000, 267 . 269 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 270 RFC 2890, DOI 10.17487/RFC2890, September 2000, 271 . 273 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 274 the Network Configuration Protocol (NETCONF)", RFC 6020, 275 DOI 10.17487/RFC6020, October 2010, 276 . 278 10.2. Informative References 280 [I-D.ietf-intarea-gre-ipv6] 281 Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 282 for Generic Routing Encapsulation (GRE)", draft-ietf- 283 intarea-gre-ipv6-14 (work in progress), September 2015. 285 [I-D.ietf-intarea-gre-mtu] 286 Bonica, R., Pignataro, C., and J. Touch, "A Widely- 287 Deployed Solution To The Generic Routing Encapsulation 288 (GRE) Fragmentation Problem", draft-ietf-intarea-gre- 289 mtu-05 (work in progress), May 2015. 291 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 292 and A. Bierman, Ed., "Network Configuration Protocol 293 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 294 . 296 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 297 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 298 . 300 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 301 Protocol (NETCONF) Access Control Model", RFC 6536, 302 DOI 10.17487/RFC6536, March 2012, 303 . 305 Authors' Addresses 307 Lianshu Zheng (editor) 308 Huawei Technologies 309 China 311 Email: vero.zheng@huawei.com 313 Carlos Pignataro 314 Cisco Systems, Inc. 315 USA 317 Email: cpignata@cisco.com 319 Reinaldo Penno 320 Cisco Systems, Inc. 321 USA 323 Email: repenno@cisco.com 325 Zishun Wang 326 Huawei Technologies 327 China 329 Email: wangzishun@huawei.com