idnits 2.17.1 draft-dong-idr-ls-ip-tunnel-00.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 16, 2016) is 2960 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: 'RFC5342' is defined on line 469, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-04 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-01 == Outdated reference: A later version (-01) exists of draft-hao-idr-flowspec-redirect-tunnel-00 -- Obsolete informational reference (is this intentional?): RFC 5342 (Obsoleted by RFC 7042) -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft Z. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 17, 2016 J. Tantsura 6 Ericsson 7 H. Gredler 8 Private Contributor 9 March 16, 2016 11 BGP Link-State Extension for Distribution of IP Tunnel Information 12 draft-dong-idr-ls-ip-tunnel-00 14 Abstract 16 This document specifies extensions to BGP-LS for the collection and 17 distribution of IP tunnel information. Such information can be 18 distributed to external components for service mapping and tunnel 19 selection. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 17, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Carrying IP Tunnel Information in BGP-LS . . . . . . . . . . 3 63 2.1. IP Tunnel Identifier Information . . . . . . . . . . . . 3 64 2.2. IP Tunnel Parameters TLV . . . . . . . . . . . . . . . . 6 65 3. Operational Considerations . . . . . . . . . . . . . . . . . 8 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 8 68 4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 9 69 4.3. BGP-LS Attribute TLVs . . . . . . . . . . . . . . . . . . 9 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 7.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 BGP has been extended to distribute the link-state 80 [I-D.ietf-idr-ls-distribution] and TE-LSP information 81 [I-D.ietf-idr-te-lsp-distribution] to external components. When IP 82 tunnel technologies, such as Generic Routing Encapsulation (GRE), 83 Layer Two Tunneling Protocol - Version 3 (L2TPv3), VxLAN, NVGRE, 84 etc., are used in the network, it is necessary to collect the 85 information of IP tunnels in the network and share with the external 86 components. Such information can be distributed to external 87 components for service mapping and tunnel selection. One typical use 88 case of IP tunnel information is described in 89 [I-D.hao-idr-flowspec-redirect-tunnel] . This document specifies 90 extensions to BGP-LS for the collection and distribution of IP tunnel 91 information. 93 2. Carrying IP Tunnel Information in BGP-LS 95 2.1. IP Tunnel Identifier Information 97 The IP tunnel Identifier information is advertised in BGP UPDATE 98 messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes 99 [RFC4760]. The "Link-State NLRI" defined in 100 [I-D.ietf-idr-ls-distribution] is extended to carry the IP Tunnel 101 information. BGP speakers that wish to exchange IP Tunnel 102 information MUST use the BGP Multiprotocol Extensions Capability Code 103 (1) to advertise the corresponding (AFI, SAFI) pair, as specified in 104 [RFC4760]. 106 The format of "Link-State NLRI" is defined in 107 [I-D.ietf-idr-ls-distribution]. A new "NLRI Type" is defined for IP 108 Tunnel Identifier Information as following: 110 o NLRI Type = TBA: IPv4/IPv6 Tunnel NLRI 112 The IPv4/IPv6 Tunnel NLRI is shown in the following figure: 114 0 1 2 3 115 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 116 +-+-+-+-+-+-+-+-+ 117 | Protocol-ID | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Identifier | 120 | (64 bits) | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 // IP Tunnel Descriptors (variable) // 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Figure 1. IPv4/IPv6 Tunnel NLRI 126 Where 128 The 'Protocol-ID' field is used to identify the source of the 129 advertised NLRI. For IPv4/IPv6 Tunnel NLRI, according to the method 130 of tunnel establishment, the Protocol-ID field can be set to either 131 "Static configuration" or the specific signaling protocol of the IP 132 tunnel. Several new Protocol-IDs are defined as below: 134 +-------------+----------------------------------+ 135 | Protocol-ID | NLRI information source protocol | 136 +-------------+----------------------------------+ 137 | TBD | L2TPv3 | 138 +-------------+----------------------------------+ 139 | TBD | GTPv2-C | 140 +-------------+----------------------------------+ 142 As defined in [I-D.ietf-idr-ls-distribution], the 64-Bit 'Identifier' 143 field is used to identify the "routing universe" where the NLRI 144 belongs. 146 The "IP Tunnel Descriptors" field consists of a set of Descriptor 147 TLVs which together identifies the IP tunnel. The following 148 Descriptor TLVs as defined in [I-D.ietf-idr-te-lsp-distribution] are 149 reused for IPv4/IPv6 Tunnel NLRI: 151 o Tunnel ID 153 The Tunnel Identifier TLV contains the Tunnel ID defined in 154 [RFC3209] and has the following format: 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type | Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Tunnel ID | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 where: 166 + Type: To be assigned by IANA (suggested value: 267) 168 + Length: 2 octets. 170 + Tunnel ID: 2 octets as defined in [RFC3209]. 172 o IPv4/6 Tunnel Head-end address 174 The IPv4/IPv6 Tunnel Head-End Address TLV contains the Tunnel 175 Head- End Address defined in [RFC3209] and has following 176 format: 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type | Length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 // IPv4/IPv6 Tunnel Head-End Address (variable) // 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 where: 188 + Type: To be assigned by IANA (suggested value: 269) 190 + Length: 4 or 16 octets. 192 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv4 193 address, its length is 4 (octets). 195 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv6 196 address, its length is 16 (octets). 198 o IPv4/6 Tunnel Tail-end address 200 The IPv4/IPv6 Tunnel Tail-End Address TLV contains the Tunnel 201 Tail- End Address defined in [RFC3209] and has following 202 format: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 // IPv4/IPv6 Tunnel Tail-End Address (variable) // 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 where: 214 + Type: To be assigned by IANA (suggested value: 270) 216 + Length: 4 or 16 octets. 218 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv4 219 address, its length is 4 (octets). 221 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv6 222 address, its length is 16 (octets). 224 In addition, a new descriptor TLV called "Tunnel Type TLV" is defined 225 for IP Tunnel as below: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type | Length | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Tunnel Type | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 2. Tunnel Type TLV 236 o Type: TBA. 238 o Length: 2 octets. 240 o Value: The 2-octet Tunnel Type identifies the type of tunneling 241 technology as defined in the "BGP Tunnel Encapsulation Attribute 242 Tunnel Types" registry [RFC5512]. 244 The IPv4/6 Tunnel Head-end address TLV, IPv4/6 Tunnel Tail-end 245 address, Tunnel-type TLV and the Tunnel ID TLV together uniquely 246 identify the IP tunnel. 248 2.2. IP Tunnel Parameters TLV 250 A new TLV called "IP Tunnel Parameters TLV" is defined to describe 251 the detailed information of the IP tunnels, which is carried in the 252 optional non-transitive BGP Attribute "LINK_STATE Attribute" defined 253 in [I-D.ietf-idr-ls-distribution]. The IP Tunnel Parameters TLV 254 SHOULD only be used with IPv4/IPv6 Tunnel NLRI. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type | Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 ~ Tunnel Parameter Sub-TLVs ~ 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 3. IP Tunnel Parameters TLV 267 The "Value" field of the IP Tunnel Parameters TLV is composed of a 268 set of sub-TLVs. The sub-TLV is structured as below: 270 +-----------------------------------+ 271 | Sub-TLV Type (1 Octet) | 272 +-----------------------------------+ 273 | Sub-TLV Length (1 Octet) | 274 +-----------------------------------+ 275 ~ Sub-TLV Value (Variable) ~ 276 +-----------------------------------+ 278 The following sub-TLVs defined in this document can be carried in the 279 Value field of the IP Tunnel Parameters TLV: 281 o Tunnel Name sub-TLV: 283 Type: TBA 285 Length: Variable 287 Value: A string identifies the name of the IP tunnel. 289 o Description sub-TLV 291 Type: TBA 293 Length: Variable 295 Value: A string which contains the textual description of the 296 IP tunnel. 298 o Status sub-TLV: 300 Type: TBA 302 Length: 1 octet 304 Value: 8-bit flags which indicate the status of the IP tunnel. 305 Bit 0 is defined as the Up/Down bit, which SHOULD be set to 1 306 if there is no available route for the tunnel destination. The 307 other bits are reserved which MUST be set to 0 on transmission 308 and ignored on receipt. 310 o Encapsulation sub-TLV: 312 Type: TBA 314 Length: Variable 315 Value: The encapsulation information of the IP tunnel, syntax 316 and semantics of which are determined by the Tunnel Type. The 317 format of Encapsulation sub-TLVs are defined in [RFC5512] and 318 [I-D.ietf-idr-tunnel-encaps]. 320 o CoS Sub-TLV: 322 Type: TBA 324 Length: 1 octet 326 Value: the class of differentiated services that can be 327 provided by the tunnel. The format is same as the DS field as 328 defined in [RFC2474]. 330 o MTU sub-TLV: 332 Type: TBA 334 Length: 2 octets 336 Value: the Maximum Transmission Unit (MTU) of the IP tunnel. 338 3. Operational Considerations 340 The Existing BGP operational procedures apply to this document. No 341 new operation procedures are defined in this document. The 342 operational considerations as specified in 343 [I-D.ietf-idr-ls-distribution] apply to this document. 345 In general the ingress nodes of the IP Tunnels are responsible for 346 the distribution of the IP tunnel information, while the egress nodes 347 of the IP tunnels MAY report the IP tunnel information if needed. 349 4. IANA Considerations 351 IANA is requested to administer the assignment of new values defined 352 in this document and summarized in this section. 354 4.1. BGP-LS NLRI-Types 356 IANA maintains a registry called "Border Gateway Protocol - Link 357 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI- 358 Types". 360 IANA is requested to assign two new NLRI-Types: 362 +------+---------------------------+---------------+ 363 | Type | NLRI Type | Reference | 364 +------+---------------------------+---------------+ 365 | TBD | IPv4/v6 Tunnel NLRI | this document | 366 +------+---------------------------+---------------+ 368 4.2. BGP-LS Protocol-IDs 370 IANA maintains a registry called "Border Gateway Protocol - Link 371 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS 372 Protocol-IDs". 374 IANA is requested to assign two new Protocol-IDs: 376 +-------------+----------------------------------+---------------+ 377 | Protocol-ID | NLRI information source protocol | Reference | 378 +-------------+----------------------------------+---------------+ 379 | TBD | L2TPv3 | this document | 380 +-------------+----------------------------------+---------------+ 381 | TBD | GTPv2-C | this document | 382 +-------------+----------------------------------+---------------+ 384 4.3. BGP-LS Attribute TLVs 386 IANA maintains a registry called "Border Gateway Protocol - Link 387 State (BGP-LS) Parameters" with a sub-registry called "Node Anchor, 388 Link Descriptor and Link Attribute TLVs". 390 IANA is requested to assign one new TLV code point: 392 +-----------+-------------------------+---------------+-----------------+ 393 | TLV Code | Description | IS-IS TLV/ | Value defined | 394 | Point | | Sub-TLV | in: | 395 +-----------+-------------------------+---------------+-----------------+ 396 | TBD |IP Tunnel Parameters TLV | --- | this document | 397 +-----------+-------------------------+---------------+-----------------+ 399 5. Security Considerations 401 Procedures and protocol extensions defined in this document do not 402 affect the BGP security model. See the 'Security Considerations' 403 section of [RFC4271] for a discussion of BGP security. Also refer to 404 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 406 6. Acknowledgements 408 The authors would like to thank Nan Wu, Shunwan Zhuang and Xia Chen 409 for their review and valuable comments. 411 7. References 413 7.1. Normative References 415 [I-D.ietf-idr-ls-distribution] 416 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 417 Ray, "North-Bound Distribution of Link-State and TE 418 Information using BGP", draft-ietf-idr-ls-distribution-13 419 (work in progress), October 2015. 421 [I-D.ietf-idr-te-lsp-distribution] 422 Dong, J., Chen, M., Gredler, H., Previdi, S., and J. 423 Tantsura, "Distribution of MPLS Traffic Engineering (TE) 424 LSP State using BGP", draft-ietf-idr-te-lsp- 425 distribution-04 (work in progress), December 2015. 427 [I-D.ietf-idr-tunnel-encaps] 428 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 429 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-01 430 (work in progress), December 2015. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 438 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 439 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 440 . 442 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 443 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 444 DOI 10.17487/RFC4271, January 2006, 445 . 447 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 448 "Multiprotocol Extensions for BGP-4", RFC 4760, 449 DOI 10.17487/RFC4760, January 2007, 450 . 452 7.2. Informative References 454 [I-D.hao-idr-flowspec-redirect-tunnel] 455 Weiguo, H., Li, Z., and L. Yong, "BGP Flow-Spec Redirect 456 to Tunnel action", draft-hao-idr-flowspec-redirect- 457 tunnel-00 (work in progress), October 2015. 459 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 460 "Definition of the Differentiated Services Field (DS 461 Field) in the IPv4 and IPv6 Headers", RFC 2474, 462 DOI 10.17487/RFC2474, December 1998, 463 . 465 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 466 RFC 4272, DOI 10.17487/RFC4272, January 2006, 467 . 469 [RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol 470 Usage for IEEE 802 Parameters", RFC 5342, 471 DOI 10.17487/RFC5342, September 2008, 472 . 474 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 475 Subsequent Address Family Identifier (SAFI) and the BGP 476 Tunnel Encapsulation Attribute", RFC 5512, 477 DOI 10.17487/RFC5512, April 2009, 478 . 480 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 481 BGP, LDP, PCEP, and MSDP Issues According to the Keying 482 and Authentication for Routing Protocols (KARP) Design 483 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 484 . 486 Authors' Addresses 488 Jie Dong 489 Huawei Technologies 490 Huawei Campus, No.156 Beiqing Rd. 491 Beijing 100095 492 China 494 Email: jie.dong@huawei.com 495 Zhenbin Li 496 Huawei Technologies 497 Huawei Building, No.156 Beiqing Rd. 498 Beijing 100095 499 China 501 Email: lizhenbin@huawei.com 503 Jeff Tantsura 504 Ericsson 505 300 Holger Way 506 San Jose, CA 95134 507 US 509 Email: jeff.tantsura@ericsson.com 511 Hannes Gredler 512 Private Contributor 514 Email: hannes@gredler.at