idnits 2.17.1 draft-ietf-isis-encapsulation-cap-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 date (April 21, 2017) is 2552 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 4971 (Obsoleted by RFC 7981) ** 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: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISIS 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 IS-IS 17 draft-ietf-isis-encapsulation-cap-01 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 IS-IS Router Capability 25 TLV. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 23, 2017. 50 Copyright Notice 52 Copyright (c) 2017 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 (http://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Advertising Encapsulation Capability . . . . . . . . . . . . 3 70 4. Tunnel Encapsulation Type . . . . . . . . . . . . . . . . . . 3 71 5. Tunnel Encapsulation Attribute . . . . . . . . . . . . . . . 5 72 5.1. Tunnel Parameters sub-TLV . . . . . . . . . . . . . . . . 5 73 5.2. Encapsulated Protocol sub-TLV . . . . . . . . . . . . . . 6 74 5.3. End Point sub-TLV . . . . . . . . . . . . . . . . . . . . 6 75 5.4. Color sub-TLV . . . . . . . . . . . . . . . . . . . . . . 6 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 6.1. IS-IS Router Capability . . . . . . . . . . . . . . . . . 6 78 6.2. IGP Tunnel Encapsulation Types Registry . . . . . . . . . 6 79 6.3. IGP Tunnel Encapsulation Attribute Types Registry . . . . 7 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 84 9.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 Some networks use tunnels for a variety of reasons, such as: 91 o Partial deployment of MPLS-SPRING as described in 92 [I-D.xu-mpls-unified-source-routing-instruction], where IP tunnels 93 are used between MPLS-SPRING-enabled routers so as to traverse 94 non- MPLS routers. 96 o Partial deployment of MPLS-BIER as described in Section 6.9 of 97 [I-D.ietf-bier-architecture], where IP tunnels are used between 98 MPLS-BIER-capable routers so as to traverse non MPLS-BIER 99 [I-D.ietf-bier-mpls-encapsulation] routers. 101 o Partial deployment of IPv6 (resp. IPv4) in IPv4 (resp. IPv6) 102 networks as described in [RFC5565], where IPvx tunnels are used 103 between IPvx-enabled routers so as to traverse non-IPvx routers. 105 o Remote Loop Free Alternate repair tunnels as described in 106 [RFC7490], where tunnels are used between the Point of Local 107 Repair and the selected PQ node. 109 The ingress needs to select a type of tunnel which is supported by 110 the egress. This document describes how to use IS-IS Router 111 Capability TLV to advertise the egress tunnelling capabilities of 112 nodes. 114 2. Terminology 116 This memo makes use of the terms defined in [RFC4971]. 118 3. Advertising Encapsulation Capability 120 Routers advertises their supported encapsulation type(s) by 121 advertising a new sub-TLV of the IS-IS Router CAPABILITY TLV 122 [RFC4971], referred to as Encapsulation Capability sub-TLV. This 123 sub-TLV SHOULD NOT appear more than once within a given IS-IS Router 124 CAPABILITY TLV. The scope of the advertisement depends on the 125 application but it is recommended that it SHOULD be domain-wide. The 126 Type code of the Encapsulation Capability sub-TLV is TBD1, the Length 127 value is variable, and the Value field contains one or more Tunnel 128 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 | Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 | Value | 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Tunnel Type (1 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 (1 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. IS-IS Router Capability 263 This document requests IANA to allocate a new code point from 264 registry IS-IS Router CAPABILITY TLV. 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 IS-IS protocol are covered in 338 [RFC1195]. 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 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 380 "Intermediate System to Intermediate System (IS-IS) 381 Extensions for Advertising Router Information", RFC 4971, 382 DOI 10.17487/RFC4971, July 2007, 383 . 385 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 386 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 387 DOI 10.17487/RFC5226, May 2008, 388 . 390 9.2. Informative References 392 [I-D.ietf-bier-architecture] 393 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 394 S. Aldrin, "Multicast using Bit Index Explicit 395 Replication", draft-ietf-bier-architecture-05 (work in 396 progress), October 2016. 398 [I-D.ietf-bier-mpls-encapsulation] 399 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 400 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 401 Explicit Replication in MPLS and non-MPLS Networks", 402 draft-ietf-bier-mpls-encapsulation-06 (work in progress), 403 December 2016. 405 [I-D.ietf-nvo3-vxlan-gpe] 406 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 407 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-03 (work 408 in progress), October 2016. 410 [I-D.xu-mpls-unified-source-routing-instruction] 411 Xu, X., Bryant, S., Raszuk, R., Chunduri, U., Contreras, 412 L., Jalil, L., and H. Assarpour, "Unified Source Routing 413 Instruction using MPLS Label Stack", draft-xu-mpls- 414 unified-source-routing-instruction-00 (work in progress), 415 March 2017. 417 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 418 dual environments", RFC 1195, DOI 10.17487/RFC1195, 419 December 1990, . 421 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 422 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 423 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 424 . 426 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 427 "Encapsulating MPLS in IP or Generic Routing Encapsulation 428 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 429 . 431 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 432 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 433 Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 434 2007, . 436 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 437 Subsequent Address Family Identifier (SAFI) and the BGP 438 Tunnel Encapsulation Attribute", RFC 5512, 439 DOI 10.17487/RFC5512, April 2009, 440 . 442 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 443 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 444 . 446 [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel 447 Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, 448 June 2009, . 450 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 451 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 452 eXtensible Local Area Network (VXLAN): A Framework for 453 Overlaying Virtualized Layer 2 Networks over Layer 3 454 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 455 . 457 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 458 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 459 RFC 7490, DOI 10.17487/RFC7490, April 2015, 460 . 462 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 463 "Encapsulating MPLS in UDP", RFC 7510, 464 DOI 10.17487/RFC7510, April 2015, 465 . 467 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 468 Virtualization Using Generic Routing Encapsulation", 469 RFC 7637, DOI 10.17487/RFC7637, September 2015, 470 . 472 Authors' Addresses 474 Xiaohu Xu (editor) 475 Huawei 477 Email: xuxiaohu@huawei.com 479 Bruno Decraene (editor) 480 Orange 482 Email: bruno.decraene@orange.com 484 Robert Raszuk 485 Bloomberg LP 487 Email: robert@raszuk.net 489 Uma Chunduri 490 Huawei 492 Email: uma.chunduri@gmail.com 494 Luis M. Contreras 495 Telefonica I+D 497 Email: luismiguel.contrerasmurillo@telefonica.com 499 Luay Jalil 500 Verizon 502 Email: luay.jalil@verizon.com