idnits 2.17.1 draft-ietf-idr-te-lsp-distribution-04.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 (December 3, 2015) is 3059 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) == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: June 5, 2016 H. Gredler 6 Individual Contributor 7 S. Previdi 8 Cisco Systems, Inc. 9 J. Tantsura 10 Ericsson 11 December 3, 2015 13 Distribution of MPLS Traffic Engineering (TE) LSP State using BGP 14 draft-ietf-idr-te-lsp-distribution-04 16 Abstract 18 This document describes a mechanism to collect the Traffic 19 Engineering (TE) LSP information using BGP. Such information can be 20 used by external components for path reoptimization, service 21 placement, and network visualization. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 5, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Carrying LSP State Information in BGP . . . . . . . . . . . . 4 65 2.1. MPLS TE LSP Information . . . . . . . . . . . . . . . . . 4 66 2.2. IPv4/IPv6 MPLS TE LSP NLRI . . . . . . . . . . . . . . . 5 67 2.2.1. MPLS TE LSP Descriptors . . . . . . . . . . . . . . . 6 68 2.3. LSP State Information . . . . . . . . . . . . . . . . . . 8 69 2.3.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . 10 70 2.3.2. PCE Objects . . . . . . . . . . . . . . . . . . . . . 11 71 2.3.3. SR Encap TLVs . . . . . . . . . . . . . . . . . . . . 11 72 3. Operational Considerations . . . . . . . . . . . . . . . . . 12 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 12 75 4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 12 76 4.3. BGP-LS Descriptors TLVs . . . . . . . . . . . . . . . . . 13 77 4.4. BGP-LS LSP-State TLV Protocol Origin . . . . . . . . . . 13 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 7.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 In some network environments, the state of established Multi-Protocol 88 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 89 (LSPs) and Tunnels in the network are required by components external 90 to the network domain. Usually this information is directly 91 maintained by the ingress Label Edge Routers (LERs) of the MPLS TE 92 LSPs. 94 One example of using the LSP information is stateful Path Computation 95 Element (PCE) [I-D.ietf-pce-stateful-pce], which could provide 96 benefits in path reoptimization. While some extensions are proposed 97 in Path Computation Element Communication Protocol (PCEP) for the 98 Path Computation Clients (PCCs) to report the LSP states to the PCE, 99 this mechanism may not be applicable in a management-based PCE 100 architecture as specified in section 5.5 of [RFC4655]. As 101 illustrated in the figure below, the PCC is not an LSR in the routing 102 domain, thus the head-end nodes of the TE-LSPs may not implement the 103 PCEP protocol. In this case a general mechanism to collect the TE- 104 LSP states from the ingress LERs is needed. This document proposes 105 an LSP state collection mechanism complementary to the mechanism 106 defined in [I-D.ietf-pce-stateful-pce]. 108 ----------- 109 | ----- | 110 Service | | TED |<-+-----------> 111 Request | ----- | TED synchronization 112 | | | | mechanism (for example, 113 v | | | routing protocol) 114 ------------- Request/ | v | 115 | | Response| ----- | 116 | NMS |<--------+> | PCE | | 117 | | | ----- | 118 ------------- ----------- 119 Service | 120 Request | 121 v 122 ---------- Signaling ---------- 123 | Head-End | Protocol | Adjacent | 124 | Node |<---------->| Node | 125 ---------- ---------- 127 Figure 1. Management-Based PCE Usage 129 In networks with composite PCE nodes as specified in section 5.1 of 130 [RFC4655], PCE is implemented on several routers in the network, and 131 the PCCs in the network can use the mechanism described in 132 [I-D.ietf-pce-stateful-pce] to report the LSP information to the PCE 133 nodes. An external component may also need to collect the LSP 134 information from all the PCEs in the network to obtain a global view 135 of the LSP state in the network. 137 In multi-area or multi-AS scenarios, each area or AS can have a child 138 PCE to collect the LSP state in its own domain, in addition, a parent 139 PCE needs to collect LSP information from multiple child PCEs to 140 obtain a global view of LSPs inside and across the domains involved. 142 In another network scenario, a centralized controller is used for 143 service placement. Obtaining the TE LSP state information is quite 144 important for making appropriate service placement decisions with the 145 purpose to both meet the application's requirements and utilize 146 network resources efficiently. 148 The Network Management System (NMS) may need to provide global 149 visibility of the TE LSPs in the network as part of the network 150 visualization function. 152 BGP has been extended to distribute link-state and traffic 153 engineering information to external components 154 [I-D.ietf-idr-ls-distribution]. Using the same protocol to collect 155 TE LSP information is desirable for these external components since 156 this avoids introducing multiple protocols for network information 157 collection. This document describes a mechanism to distribute TE LSP 158 information to external components using BGP. 160 2. Carrying LSP State Information in BGP 162 2.1. MPLS TE LSP Information 164 The MPLS TE LSP information is advertised in BGP UPDATE messages 165 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. 166 The "Link-State NLRI" defined in [I-D.ietf-idr-ls-distribution] is 167 extended to carry the MPLS TE LSP information. BGP speakers that 168 wish to exchange MPLS TE LSP information MUST use the BGP 169 Multiprotocol Extensions Capability Code (1) to advertise the 170 corresponding (AFI, SAFI) pair, as specified in [RFC4760]. 172 The format of "Link-State NLRI" is defined in 173 [I-D.ietf-idr-ls-distribution]. A new "NLRI Type" is defined for 174 MPLS TE LSP Information as following: 176 o NLRI Type: IPv4/IPv6 MPLS TE LSP NLRI (suggested codepoint value 177 5, to be assigned by IANA). 179 [I-D.ietf-idr-ls-distribution] defines the BGP-LS NLRI as follows: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | NLRI Type | Total NLRI Length | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 // Link-State NLRI (variable) // 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 This document defines a new NLRI-Type and its format: the IPv4/IPv6 192 MPLS TE LSP NLRI defined in the following section. 194 2.2. IPv4/IPv6 MPLS TE LSP NLRI 196 The IPv4/IPv6 MPLS TE LSP NLRI (NLRI Type 5. Suggested value, to be 197 assigned by IANA) is shown in the following figure: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+ 202 | Protocol-ID | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Identifier | 205 | (64 bits) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 // MPLS TE LSP Descriptors (variable) // 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 where: 212 o Protocol-ID field specifies the type of signaling of the MPLS TE 213 LSP. The following Protocol-IDs are defined (suggested values, to 214 be assigned by IANA) and apply to the IPv4/IPv6 MPLS TE LSP NLRI: 216 +-------------+----------------------------------+ 217 | Protocol-ID | NLRI information source protocol | 218 +-------------+----------------------------------+ 219 | 7 | RSVP-TE | 220 | 8 | Segment Routing | 221 +-------------+----------------------------------+ 223 o "Identifier" is an 8 octet value as defined in 224 [I-D.ietf-idr-ls-distribution]. 226 o Following MPLS TE LSP Descriptors are defined: 228 +-----------+----------------------------------+ 229 | Codepoint | Descriptor TLV | 230 +-----------+----------------------------------+ 231 | 267 | Tunnel ID | 232 | 268 | LSP ID | 233 | 269 | IPv4/6 Tunnel Head-end address | 234 | 270 | IPv4/6 Tunnel Tail-end address | 235 | 271 | SR-ENCAP Identifier | 236 +-----------+----------------------------------+ 238 2.2.1. MPLS TE LSP Descriptors 240 This sections defines the MPLS TE Descriptors TLVs. 242 2.2.1.1. Tunnel Identifier (Tunnel ID) 244 The Tunnel Identifier TLV contains the Tunnel ID defined in [RFC3209] 245 and has the following format: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Tunnel ID | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 where: 257 o Type: To be assigned by IANA (suggested value: 267) 259 o Length: 2 octets. 261 o Tunnel ID: 2 octets as defined in [RFC3209]. 263 2.2.1.2. LSP Identifier (LSP ID) 265 The LSP Identifier TLV contains the LSP ID defined in [RFC3209] and 266 has the following format: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type | Length | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | LSP ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 where: 278 o Type: To be assigned by IANA (suggested value: 268) 280 o Length: 2 octets. 282 o LSP ID: 2 octets as defined in [RFC3209]. 284 2.2.1.3. IPv4/IPv6 Tunnel Head-End Address 286 The IPv4/IPv6 Tunnel Head-End Address TLV contains the Tunnel Head- 287 End Address defined in [RFC3209] and has following format: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 // IPv4/IPv6 Tunnel Head-End Address (variable) // 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 where: 299 o Type: To be assigned by IANA (suggested value: 269) 301 o Length: 4 or 16 octets. 303 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv4 304 address, its length is 4 (octets). 306 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv6 307 address, its length is 16 (octets). 309 2.2.1.4. IPv4/IPv6 Tunnel Tail-End Address 311 The IPv4/IPv6 Tunnel Tail-End Address TLV contains the Tunnel Tail- 312 End Address defined in [RFC3209] and has following format: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 // IPv4/IPv6 Tunnel Tail-End Address (variable) // 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 where: 324 o Type: To be assigned by IANA (suggested value: 270) 326 o Length: 4 or 16 octets. 328 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv4 329 address, its length is 4 (octets). 331 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv6 332 address, its length is 16 (octets). 334 2.2.1.5. SR-Encap TLV 336 The SR-ENCAP TLV contains the Identifier defined in 337 [I-D.sreekantiah-idr-segment-routing-te] and has the following 338 format: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type | Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | SR-ENCAP Identifier | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 where: 350 o Type: To be assigned by IANA (suggested value: 271) 352 o Length: 4 octets. 354 o SR-ENCAP Identifier: 4 octets as defined in 355 [I-D.sreekantiah-idr-segment-routing-te]. 357 2.3. LSP State Information 359 A new TLV called "LSP State TLV" (codepoint to be assigned by IANA), 360 is used to describe the characteristics of the MPLS TE LSPs, which is 361 carried in the optional non-transitive BGP Attribute "LINK_STATE 362 Attribute" defined in [I-D.ietf-idr-ls-distribution]. These MPLS TE 363 LSP characteristics include the switching technology of the LSP, 364 Quality of Service (QoS) parameters, route information, the 365 protection mechanisms, etc. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 // LSP State Information (variable) // 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 LSP State TLV 379 Type: Suggested value 1158 (to be assigned by IANA) 381 LSP State Information: Consists of a set of TE-LSP objects as defined 382 in [RFC3209],[RFC3473] and [RFC5440]. Rather than replicating all 383 MPLS TE LSP related objects in this document, the semantics and 384 encodings of the MPLS TE LSP objects are reused. These MPLS TE LSP 385 objects are carried in the "LSP State Information" with the following 386 format. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |Protocol-Origin| Reserved | Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 // Protocol specific TE-LSP object // 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 LSP State Information 400 The Protocol-Origin field identifies the protocol from which the 401 contained MPLS TE LSP object originated. This allows for MPLS TE LSP 402 objects defined in different protocols to be collected while avoiding 403 the possible code collisions among these protocols. Three Protocol- 404 Origins are defined in this document (suggested values, to be 405 assigned by IANA) 407 +----------+--------------+ 408 | Protocol | LSP Object | 409 | Origin | Origin | 410 +----------+--------------+ 411 | 1 | RSVP-TE | 412 | 2 | PCE | 413 | 3 | SR ENCAP | 414 +----------+--------------+ 416 The 8-bit Reserved field SHOULD be set to 0 on transmission and 417 ignored on receipt. 419 The Length field is set to the Length of the value field, which is 420 the total length of the contained MPLS TE LSP object. 422 The Valued field is a MPLS-TE LSP object which is defined in the 423 protocol identified by the Protocol-Origin field. 425 2.3.1. RSVP Objects 427 RSVP-TE objects are encoded in the "Value" field of the LSP State TLV 428 and consists of MPLS TE LSP objects defined in RSVP-TE [RFC3209] 429 [RFC3473]. Rather than replicating all MPLS TE LSP related objects 430 in this document, the semantics and encodings of the MPLS TE LSP 431 objects are re-used. These MPLS TE LSP objects are carried in the 432 LSP State TLV. 434 When carrying RSVP-TE objects, the "Protocol-Origin" field is set to 435 "RSVP-TE" (suggested value 1, to be assigned by IANA). 437 The following RSVP-TE Objects are defined: 439 o SENDER_TSPEC and FLOW_SPEC [RFC2205] 441 o SESSION_ATTRIBUTE [RFC3209] 443 o EXPLICIT_ROUTE Object (ERO) [RFC3209] 445 o ROUTE_RECORD Object (RRO) [RFC3209] 447 o FAST_REROUTE Object [RFC4090] 449 o DETOUR Object [RFC4090] 451 o EXCLUDE_ROUTE Object (XRO) [RFC4874] 453 o SECONDARY_EXPLICIT_ROUTE Object (SERO) [RFC4873] 455 o SECONDARY_RECORD_ROUTE (SRRO) [RFC4873] 457 o LSP_ATTRIBUTES Object [RFC5420] 459 o LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 461 o PROTECTION Object [RFC3473][RFC4872][RFC4873] 463 o ASSOCIATION Object [RFC4872] 465 o PRIMARY_PATH_ROUTE Object [RFC4872] 467 o ADMIN_STATUS Object [RFC3473] 469 o LABEL_REQUEST Object [RFC3209][RFC3473] 471 For the MPLS TE LSP Objects listed above, the corresponding sub- 472 objects are also applicable to this mechanism. Note that this list 473 is not exhaustive, other MPLS TE LSP objects which reflect specific 474 characteristics of the MPLS TE LSP can also be carried in the LSP 475 state TLV. 477 2.3.2. PCE Objects 479 PCE objects are encoded in the "Value" field of the MPLS TE LSP State 480 TLV and consists of PCE objects defined in [RFC5440]. Rather than 481 replicating all MPLS TE LSP related objects in this document, the 482 semantics and encodings of the MPLS TE LSP objects are re-used. 483 These MPLS TE LSP objects are carried in the LSP State TLV. 485 When carrying PCE objects, the "Protocol-Origin" field is set to 486 "PCE" (suggested value 2, to be assigned by IANA). 488 The following PCE Objects are defined: 490 o METRIC Object [RFC5440] 492 o BANDWIDTH Object [RFC5440] 494 For the MPLS TE LSP Objects listed above, the corresponding sub- 495 objects are also applicable to this mechanism. Note that this list 496 is not exhaustive, other MPLS TE LSP objects which reflect specific 497 characteristics of the MPLS TE LSP can also be carried in the LSP 498 state TLV. 500 2.3.3. SR Encap TLVs 502 SR-ENCAP objects are encoded in the "Value" field of the LSP State 503 TLV and consists of SR-ENCAP objects defined in 504 [I-D.sreekantiah-idr-segment-routing-te]. Rather than replicating 505 all MPLS TE LSP related objects in this document, the semantics and 506 encodings of the MPLS TE LSP objects are re-used. These MPLS TE LSP 507 objects are carried in the LSP State TLV. 509 When carrying SR-ENCAP objects, the "Protocol-Origin" field is set to 510 "SR-ENCAP" (suggested value 3, to be assigned by IANA). 512 The following SR-ENCAP Objects are defined: 514 o ERO TLV [I-D.sreekantiah-idr-segment-routing-te] 516 o Weight TLV [I-D.sreekantiah-idr-segment-routing-te] 518 o Binding SID TLV [I-D.sreekantiah-idr-segment-routing-te] 519 For the MPLS TE LSP Objects listed above, the corresponding sub- 520 objects are also applicable to this mechanism. Note that this list 521 is not exhaustive, other MPLS TE LSP objects which reflect specific 522 characteristics of the MPLS TE LSP can also be carried in the LSP 523 state TLV. 525 3. Operational Considerations 527 The Existing BGP operational procedures apply to this document. No 528 new operation procedures are defined in this document. The 529 operational considerations as specified in 530 [I-D.ietf-idr-ls-distribution] apply to this document. 532 In general the ingress nodes of the MPLS TE LSPs are responsible for 533 the distribution of LSP state information, while other nodes on the 534 LSP path MAY report the LSP information when needed. For example, 535 the border routers in the inter-domain case will also distribute LSP 536 state information since the ingress node may not have the complete 537 information for the end-to-end path. 539 4. IANA Considerations 541 This document requires new IANA assigned codepoints. 543 4.1. BGP-LS NLRI-Types 545 IANA maintains a registry called "Border Gateway Protocol - Link 546 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI- 547 Types". 549 The following codepoints is suggested (to be assigned by IANA): 551 +------+----------------------------+---------------+ 552 | Type | NLRI Type | Reference | 553 +------+----------------------------+---------------+ 554 | 5 | IPv4/IPv6 MPLS TE LSP NLRI | this document | 555 +------+----------------------------+---------------+ 557 4.2. BGP-LS Protocol-IDs 559 IANA maintains a registry called "Border Gateway Protocol - Link 560 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS 561 Protocol-IDs". 563 The following Protocol-ID codepoints are suggested (to be assigned by 564 IANA): 566 +-------------+----------------------------------+---------------+ 567 | Protocol-ID | NLRI information source protocol | Reference | 568 +-------------+----------------------------------+---------------+ 569 | 7 | RSVP-TE | this document | 570 | 8 | Segment Routing | this document | 571 +-------------+----------------------------------+---------------+ 573 4.3. BGP-LS Descriptors TLVs 575 IANA maintains a registry called "Border Gateway Protocol - Link 576 State (BGP-LS) Parameters" with a sub-registry called "Node Anchor, 577 Link Descriptor and Link Attribute TLVs". 579 The following TLV codepoints are suggested (to be assigned by IANA): 581 +----------+--------------------------------------+---------------+ 582 | TLV Code | Description | Value defined | 583 | Point | | in | 584 +----------+--------------------------------------+---------------+ 585 | 1158 | LSP State TLV | this document | 586 | 267 | Tunnel ID TLV | this document | 587 | 268 | LSP ID TLV | this document | 588 | 269 | IPv4/6 Tunnel Head-end address TLV | this document | 589 | 270 | IPv4/6 Tunnel Tail-end address TLV | this document | 590 | 271 | SR-ENCAP Identifier TLV | this document | 591 +----------+--------------------------------------+---------------+ 593 4.4. BGP-LS LSP-State TLV Protocol Origin 595 This document requests IANA to maintain a new sub-registry under 596 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 597 registry is called "Protocol Origin" and contains the codepoints 598 allocated to the "Protocol Origin" field defined in Section 2.3. The 599 registry contains the following codepoints (suggested values, to be 600 assigned by IANA): 602 +----------+--------------+ 603 | Protocol | Description | 604 | Origin | | 605 +----------+--------------+ 606 | 1 | RSVP-TE | 607 | 2 | PCE | 608 | 3 | SR-ENCAP | 609 +----------+--------------+ 611 5. Security Considerations 613 Procedures and protocol extensions defined in this document do not 614 affect the BGP security model. See [RFC6952] for details. 616 6. Acknowledgements 618 The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz 619 Khalid, Lou Berger, Acee Lindem, Siva Sivabalan and Arjun Sreekantiah 620 for their review and valuable comments. 622 7. References 624 7.1. Normative References 626 [I-D.ietf-idr-ls-distribution] 627 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 628 Ray, "North-Bound Distribution of Link-State and TE 629 Information using BGP", draft-ietf-idr-ls-distribution-13 630 (work in progress), October 2015. 632 [I-D.sreekantiah-idr-segment-routing-te] 633 Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., 634 Mattes, P., and J. Marcon, "Segment Routing Traffic 635 Engineering Policy using BGP", draft-sreekantiah-idr- 636 segment-routing-te-00 (work in progress), October 2015. 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 644 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 645 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 646 September 1997, . 648 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 649 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 650 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 651 . 653 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 654 Switching (GMPLS) Signaling Resource ReserVation Protocol- 655 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 656 DOI 10.17487/RFC3473, January 2003, 657 . 659 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 660 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 661 DOI 10.17487/RFC4090, May 2005, 662 . 664 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 665 "Multiprotocol Extensions for BGP-4", RFC 4760, 666 DOI 10.17487/RFC4760, January 2007, 667 . 669 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 670 Ed., "RSVP-TE Extensions in Support of End-to-End 671 Generalized Multi-Protocol Label Switching (GMPLS) 672 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 673 . 675 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 676 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 677 May 2007, . 679 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 680 Extension to Resource ReserVation Protocol-Traffic 681 Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, 682 April 2007, . 684 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 685 Ayyangarps, "Encoding of Attributes for MPLS LSP 686 Establishment Using Resource Reservation Protocol Traffic 687 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 688 February 2009, . 690 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 691 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 692 DOI 10.17487/RFC5440, March 2009, 693 . 695 7.2. Informative References 697 [I-D.ietf-pce-stateful-pce] 698 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 699 Extensions for Stateful PCE", draft-ietf-pce-stateful- 700 pce-13 (work in progress), December 2015. 702 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 703 Element (PCE)-Based Architecture", RFC 4655, 704 DOI 10.17487/RFC4655, August 2006, 705 . 707 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 708 BGP, LDP, PCEP, and MSDP Issues According to the Keying 709 and Authentication for Routing Protocols (KARP) Design 710 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 711 . 713 Authors' Addresses 715 Jie Dong 716 Huawei Technologies 717 Huawei Campus, No. 156 Beiqing Rd. 718 Beijing 100095 719 China 721 Email: jie.dong@huawei.com 723 Mach(Guoyi) Chen 724 Huawei Technologies 725 Huawei Campus, No. 156 Beiqing Rd. 726 Beijing 100095 727 China 729 Email: mach.chen@huawei.com 731 Hannes Gredler 732 Individual Contributor 733 Austria 735 Email: hannes@gredler.at 737 Stefano Previdi 738 Cisco Systems, Inc. 739 Via Del Serafico, 200 740 Rome 00142 741 Italy 743 Email: sprevidi@cisco.com 744 Jeff Tantsura 745 Ericsson 746 300 Holger Way 747 San Jose, CA 95134 748 US 750 Email: jeff.tantsura@ericsson.com