idnits 2.17.1 draft-ietf-ospf-encapsulation-cap-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 : ---------------------------------------------------------------------------- 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 21, 2017) is 2560 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) == Unused Reference: 'RFC1700' is defined on line 351, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-05 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-06 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-03 == Outdated reference: A later version (-04) exists of draft-xu-mpls-unified-source-routing-instruction-00 -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) -- Obsolete informational reference (is this intentional?): RFC 5566 (Obsoleted by RFC 9012) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group X. Xu, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track B. Decraene, Ed. 5 Expires: October 23, 2017 Orange 6 R. Raszuk 7 Bloomberg LP 8 U. Chunduri 9 Huawei 10 L. Contreras 11 Telefonica I+D 12 L. Jalil 13 Verizon 14 April 21, 2017 16 Advertising Tunnelling Capability in OSPF 17 draft-ietf-ospf-encapsulation-cap-02 19 Abstract 21 Some networks use tunnels for a variety of reasons. A large variety 22 of tunnel types are defined and the ingress needs to select a type of 23 tunnel which is supported by the egress. This document defines how 24 to advertise egress tunnel capabilities in OSPF Router Information. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 23, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Advertising Encapsulation Capability . . . . . . . . . . . . 3 69 4. Tunnel Encapsulation Type . . . . . . . . . . . . . . . . . . 3 70 5. Tunnel Encapsulation Attribute . . . . . . . . . . . . . . . 5 71 5.1. Tunnel Parameters sub-TLV . . . . . . . . . . . . . . . . 5 72 5.2. Encapsulated Protocol sub-TLV . . . . . . . . . . . . . . 6 73 5.3. End Point sub-TLV . . . . . . . . . . . . . . . . . . . . 6 74 5.4. Color sub-TLV . . . . . . . . . . . . . . . . . . . . . . 6 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 6.1. OSPF Router Information . . . . . . . . . . . . . . . . . 6 77 6.2. IGP Tunnel Encapsulation Types Registry . . . . . . . . . 6 78 6.3. IGP Tunnel Encapsulation Attribute Types Registry . . . . 7 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 83 9.2. Informative References . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 Some networks use tunnels for a variety of reasons, such as: 90 o Partial deployment of MPLS-SPRING as described in 91 [I-D.xu-mpls-unified-source-routing-instruction], where IP tunnels 92 are used between MPLS-SPRING-enabled routers so as to traverse 93 non- MPLS routers. 95 o Partial deployment of MPLS-BIER as described in Section 6.9 of 96 [I-D.ietf-bier-architecture], where IP tunnels are used between 97 MPLS-BIER-capable routers so as to traverse non MPLS-BIER 98 [I-D.ietf-bier-mpls-encapsulation] routers. 100 o Partial deployment of IPv6 (resp. IPv4) in IPv4 (resp. IPv6) 101 networks as described in [RFC5565], where IPvx tunnels are used 102 between IPvx-enabled routers so as to traverse non-IPvx routers. 104 o Remote Loop Free Alternate repair tunnels as described in 105 [RFC7490], where tunnels are used between the Point of Local 106 Repair and the selected PQ node. 108 The ingress needs to select a type of tunnel which is supported by 109 the egress. This document describes how to use OSPF Router 110 Information to advertise the egress tunnelling capabilities of nodes. 111 In this document, OSPF means both OSPFv2 and OSPFv3. 113 2. Terminology 115 This memo makes use of the terms defined in [RFC7770]. 117 3. Advertising Encapsulation Capability 119 Routers advertises their supported encapsulation type(s) by 120 advertising a new TLV of the OSPF Router Information (RI) Opaque LSA 121 [RFC7770], referred to as Encapsulation Capability TLV. This TLV is 122 applicable to both OSPFv2 and OSPFv3. The Encapsulation Capability 123 TLV SHOULD NOT appear more than once within a given OSPF Router 124 Information (RI) Opaque LSA. The scope of the advertisement depends 125 on the application but it is recommended that it SHOULD be domain- 126 wide. The Type code of the Encapsulation Capability TLV is TBD1, the 127 Length value is variable, and the Value field contains one or more 128 Tunnel Encapsulation Type sub-TLVs. Each Encapsulation Type sub-TLVs 129 indicates a particular encapsulation format that the advertising 130 router supports. 132 4. Tunnel Encapsulation Type 134 The Tunnel Encapsulation Type sub-TLV is structured as follows: 136 0 1 2 3 137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Tunnel Type (2 Octets) | Length (2 Octets) | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 | Value | 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Tunnel Type (2 octets): identifies the type of tunneling 147 technology being signaled. This document defines the following 148 types: 150 1. L2TPv3 over IP [RFC3931] : Type code=1; 152 2. GRE [RFC2784] : Type code=2; 154 3. Transmit tunnel endpoint [RFC5566] : Type code=3; 156 4. IPsec in Tunnel-mode [RFC5566] : Type code=4; 158 5. IP in IP tunnel with IPsec Transport Mode [RFC5566] : Type 159 code=5; 161 6. MPLS-in-IP tunnel with IPsec Transport Mode [RFC5566] : Type 162 code=6; 164 7. IP in IP [RFC2003] [RFC4213]: Type code=7; 166 8. VXLAN [RFC7348] : Type code=8; 168 9. NVGRE [RFC7637] : Type code=9; 170 10. MPLS [RFC3032] : Type code=10; 172 11. MPLS-in-GRE [RFC4023] : Type code=11; 174 12. VXLAN GPE [I-D.ietf-nvo3-vxlan-gpe] : Type code=12; 176 13. MPLS-in-UDP [RFC7510] : Type code=13; 178 14. MPLS-in-UDP-with-DTLS [RFC7510] : Type code=14; 180 15. MPLS-in-L2TPv3 [RFC4817] : Type code=15; 182 16. GTP: Type code=16; 184 Unknown types are to be ignored and skipped upon receipt. 186 Length (2 octets): unsigned integer indicating the total number of 187 octets of the value field. 189 Value (variable): zero or more Tunnel Encapsulation Attribute sub- 190 TLVs as defined in Section 5. 192 5. Tunnel Encapsulation Attribute 194 The Tunnel Encapsulation Attribute sub-TLV is structured as as 195 follows: 197 +-----------------------------------+ 198 | Sub-TLV Type (1 Octet) | 199 +-----------------------------------+ 200 | Sub-TLV Length (1 Octet) | 201 +-----------------------------------+ 202 | Sub-TLV Value (Variable) | 203 | | 204 +-----------------------------------+ 206 Sub-TLV Type (1 octet): each sub-TLV type defines a certain 207 property about the tunnel TLV that contains this sub-TLV. The 208 following are the types defined in this document: 210 1. Encapsulation Parameters: sub-TLV type = 1; (See Section 5.1) 212 2. Encapsulated Protocol: sub-TLV type = 2; (See Section 5.2) 214 3. End Point: sub-TLV type = 3; (See Section 5.3) 216 4. Color: sub-TLV type = 4; (See Section 5.4) 218 Sub-TLV Length (1 octet): unsigned integer indicating the total 219 number of octets of the sub-TLV value field. 221 Sub-TLV Value (variable): encodings of the value field depend on 222 the sub-TLV type as enumerated above. The following sub-sections 223 define the encoding in detail. 225 Any unknown sub-TLVs MUST be ignored and skipped. However, if the 226 TLV is understood, the entire TLV MUST NOT be ignored just because it 227 contains an unknown sub-TLV. 229 If a sub-TLV is erroneous, this specific Tunnel Encapsulation MUST be 230 ignored and skipped. However, others Tunnel Encapsulations MUST be 231 considered. 233 5.1. Tunnel Parameters sub-TLV 235 This sub-TLV has its format defined in [RFC5512] under the name 236 Encapsulation sub-TLV. 238 5.2. Encapsulated Protocol sub-TLV 240 This sub-TLV has its format defined in [RFC5512] under the name 241 Protocol Type. 243 5.3. End Point sub-TLV 245 The value field carries the Network Address to be used as tunnel 246 destination address. 248 If length is 4, the Address Family (AFI) is IPv4. 250 If length is 16, the Address Family (AFI) is IPv6. 252 5.4. Color sub-TLV 254 The valued field is a 4 octets opaque unsigned integer. 256 The color value is user defined and configured locally on the 257 routers. It may be used by the service providers to define policies. 259 6. IANA Considerations 261 6.1. OSPF Router Information 263 This document requests IANA to allocate a new code point from 264 registry OSPF Router Information (RI). 266 Value TLV Name Reference 267 ----- ------------------------------------ ------------- 268 TBD1 Tunnel Capabilities This document 270 6.2. IGP Tunnel Encapsulation Types Registry 272 This document requests IANA to create a new registry "IGP Tunnel 273 Encapsulation Types" with the following registration procedure: 275 Registry Name: IGP Tunnel Encapsulation Type. 277 Value Name Reference 278 ------- ------------------------------------------ ------------- 279 0 Reserved This document 280 1 L2TPv3 over IP This document 281 2 GRE This document 282 3 Transmit tunnel endpoint This document 283 4 IPsec in Tunnel-mode This document 284 5 IP in IP tunnel with IPsec Transport Mode This document 285 6 MPLS-in-IP tunnel with IPsec Transport Mode This document 286 7 IP in IP This document 287 8 VXLAN This document 288 9 NVGRE This document 289 10 MPLS This document 290 11 MPLS-in-GRE This document 291 12 VXLAN-GPE This document 292 13 MPLS-in-UDP This document 293 14 MPLS-in-UDP-with-DTLS This document 294 15 MPLS-in-L2TPv3 This document 295 16 GTP This document 296 17-250 Unassigned 297 251-254 Experimental This document 298 255 Reserved This document 300 Assignments of Encapsulation Types are via Standards Action 301 [RFC5226]. 303 6.3. IGP Tunnel Encapsulation Attribute Types Registry 305 This document requests IANA to create a new registry "IGP Tunnel 306 Encapsulation Attribute Types" with the following registration 307 procedure: 309 Registry Name: IGP Tunnel Encapsulation Attribute Types. 311 Value Name Reference 312 ------- ------------------------------------ ------------- 313 0 Reserved This document 314 1 Encapsulation parameters This document 315 2 Protocol This document 316 3 End Point This document 317 4 Color This document 318 5-250 Unassigned 319 251-254 Experimental This document 320 255 Reserved This document 322 Assignments of Encapsulation Attribute Types are via Standards Action 323 [RFC5226]. 325 7. Security Considerations 327 Security considerations applicable to softwires can be found in the 328 mesh framework [RFC5565]. In general, security issues of the tunnel 329 protocols signaled through this IGP capability extension are 330 inherited. 332 If a third party is able to modify any of the information that is 333 used to form encapsulation headers, to choose a tunnel type, or to 334 choose a particular tunnel for a particular payload type, user data 335 packets may end up getting misrouted, misdelivered, and/or dropped. 337 Security considerations for the base OSPF protocol are covered in 338 [RFC2328] and [RFC5340]. 340 8. Acknowledgements 342 This document is partially inspired by [RFC5512]. 344 The authors would like to thank Carlos Pignataro and Karsten Thomann 345 for their valuable comments on this draft. 347 9. References 349 9.1. Normative References 351 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 352 DOI 10.17487/RFC1700, October 1994, 353 . 355 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 356 DOI 10.17487/RFC2003, October 1996, 357 . 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, 361 DOI 10.17487/RFC2119, March 1997, 362 . 364 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 365 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 366 DOI 10.17487/RFC2784, March 2000, 367 . 369 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 370 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 371 RFC 3931, DOI 10.17487/RFC3931, March 2005, 372 . 374 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 375 for IPv6 Hosts and Routers", RFC 4213, 376 DOI 10.17487/RFC4213, October 2005, 377 . 379 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 380 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 381 DOI 10.17487/RFC5226, May 2008, 382 . 384 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 385 S. Shaffer, "Extensions to OSPF for Advertising Optional 386 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 387 February 2016, . 389 9.2. Informative References 391 [I-D.ietf-bier-architecture] 392 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 393 S. Aldrin, "Multicast using Bit Index Explicit 394 Replication", draft-ietf-bier-architecture-05 (work in 395 progress), October 2016. 397 [I-D.ietf-bier-mpls-encapsulation] 398 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 399 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 400 Explicit Replication in MPLS and non-MPLS Networks", 401 draft-ietf-bier-mpls-encapsulation-06 (work in progress), 402 December 2016. 404 [I-D.ietf-nvo3-vxlan-gpe] 405 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 406 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-03 (work 407 in progress), October 2016. 409 [I-D.xu-mpls-unified-source-routing-instruction] 410 Xu, X., Bryant, S., Raszuk, R., Chunduri, U., Contreras, 411 L., Jalil, L., and H. Assarpour, "Unified Source Routing 412 Instruction using MPLS Label Stack", draft-xu-mpls- 413 unified-source-routing-instruction-00 (work in progress), 414 March 2017. 416 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 417 DOI 10.17487/RFC2328, April 1998, 418 . 420 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 421 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 422 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 423 . 425 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 426 "Encapsulating MPLS in IP or Generic Routing Encapsulation 427 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 428 . 430 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 431 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 432 Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 433 2007, . 435 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 436 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 437 . 439 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 440 Subsequent Address Family Identifier (SAFI) and the BGP 441 Tunnel Encapsulation Attribute", RFC 5512, 442 DOI 10.17487/RFC5512, April 2009, 443 . 445 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 446 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 447 . 449 [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel 450 Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, 451 June 2009, . 453 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 454 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 455 eXtensible Local Area Network (VXLAN): A Framework for 456 Overlaying Virtualized Layer 2 Networks over Layer 3 457 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 458 . 460 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 461 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 462 RFC 7490, DOI 10.17487/RFC7490, April 2015, 463 . 465 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 466 "Encapsulating MPLS in UDP", RFC 7510, 467 DOI 10.17487/RFC7510, April 2015, 468 . 470 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 471 Virtualization Using Generic Routing Encapsulation", 472 RFC 7637, DOI 10.17487/RFC7637, September 2015, 473 . 475 Authors' Addresses 477 Xiaohu Xu (editor) 478 Huawei 480 Email: xuxiaohu@huawei.com 482 Bruno Decraene (editor) 483 Orange 485 Email: bruno.decraene@orange.com 487 Robert Raszuk 488 Bloomberg LP 490 Email: robert@raszuk.net 492 Uma Chunduri 493 Huawei 495 Email: uma.chunduri@gmail.com 497 Luis M. Contreras 498 Telefonica I+D 500 Email: luismiguel.contrerasmurillo@telefonica.com 502 Luay Jalil 503 Verizon 505 Email: luay.jalil@verizon.com