idnits 2.17.00 (12 Aug 2021) /tmp/idnits43211/draft-ietf-idr-te-lsp-distribution-03.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 (May 7, 2015) is 2571 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: draft-ietf-idr-ls-distribution has been published as RFC 7752 == Outdated reference: draft-ietf-pce-stateful-pce has been published as RFC 8231 Summary: 0 errors (**), 0 flaws (~~), 3 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: November 8, 2015 H. Gredler 6 Juniper Networks, Inc. 7 S. Previdi 8 Cisco Systems, Inc. 9 J. Tantsura 10 Ericsson 11 May 7, 2015 13 Distribution of MPLS Traffic Engineering (TE) LSP State using BGP 14 draft-ietf-idr-te-lsp-distribution-03 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 November 8, 2015. 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. LSP Identifier Information . . . . . . . . . . . . . . . 4 66 2.2. LSP State Information . . . . . . . . . . . . . . . . . . 6 67 3. Operational Considerations . . . . . . . . . . . . . . . . . 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 8 70 4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 8 71 4.3. BGP-LS Instance-IDs . . . . . . . . . . . . . . . . . . . 9 72 4.4. BGP-LS Attribute TLVs . . . . . . . . . . . . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 7.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 In some network environments, the states of established Multi- 83 Protocol Label Switching (MPLS) Traffic Engineering (TE) Label 84 Switched Paths (LSPs) in the network are required by some components 85 external to the network domain. Usually this information is directly 86 maintained by the ingress Label Edge Routers (LERs) of the MPLS TE 87 LSPs. 89 One example of using the LSP information is stateful Path Computation 90 Element (PCE) [I-D.ietf-pce-stateful-pce], which could provide 91 benefits in path reoptimization . While some extensions are proposed 92 in Path Computation Element Communication Protocol (PCEP) for the 93 Path Computation Clients (PCCs) to report the LSP states to the PCE, 94 this mechanism may not be applicable in a management-based PCE 95 architecture as specified in section 5.5 of [RFC4655]. As 96 illustrated in the figure below, the PCC is not an LSR in the routing 97 domain, thus the head-end nodes of the TE-LSP may not implement the 98 PCEP protocol. In this case some general mechanism to collect the 99 TE-LSP states from the ingress LERs is needed. This document 100 proposes an LSP state collection mechanism complementary to the 101 mechanism defined in [I-D.ietf-pce-stateful-pce]. 103 ----------- 104 | ----- | 105 Service | | TED |<-+-----------> 106 Request | ----- | TED synchronization 107 | | | | mechanism (for example, 108 v | | | routing protocol) 109 ------------- Request/ | v | 110 | | Response| ----- | 111 | NMS |<--------+> | PCE | | 112 | | | ----- | 113 ------------- ----------- 114 Service | 115 Request | 116 v 117 ---------- Signaling ---------- 118 | Head-End | Protocol | Adjacent | 119 | Node |<---------->| Node | 120 ---------- ---------- 122 Figure 1. Management-Based PCE Usage 124 In networks with composite PCE nodes as specified in section 5.1 of 125 [RFC4655], the PCE is implemented on several routers in the network, 126 and the PCCs in the network can use the mechanism described in 127 [I-D.ietf-pce-stateful-pce] to report the LSP information to the PCE 128 nodes. An external component may further need to collect the LSP 129 information from all the PCEs in the network to get a global view of 130 the LSP states in the network. 132 In multi-area or multi-AS scenarios, each area or AS can have a child 133 PCE to collect the LSP states of its own domain, in addition a parent 134 PCE needs to collect the LSP information from multiple child PCEs to 135 obtain a global view of LSPs inside and across the domains involved. 137 In another network scenario, a centralized controller is used for 138 service placement. Obtaining the TE LSP state information is quite 139 important for making appropriate service placement decisions with the 140 purpose of both meeting the application's requirements and utilizing 141 the network resource efficiently. 143 The Network Management System (NMS) may need to provide global 144 visibility of the TE LSPs in the network as part of the network 145 visualization function. 147 BGP has been extended to distribute link-state and traffic 148 engineering information to some external components 149 [I-D.ietf-idr-ls-distribution]. Using the same protocol to collect 150 other network layer information would be desirable for the external 151 components, which avoids introducing multiple protocols for network 152 information collection. This document describes a mechanism to 153 distribute the TE LSP information to external components using BGP. 155 2. Carrying LSP State Information in BGP 157 2.1. LSP Identifier Information 159 The TE LSP Identifier information is advertised in BGP UPDATE 160 messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes 161 [RFC4760]. The "Link-State NLRI" defined in 162 [I-D.ietf-idr-ls-distribution] is extended to carry the TE LSP 163 Identifier information. BGP speakers that wish to exchange TE LSP 164 information MUST use the BGP Multiprotocol Extensions Capability Code 165 (1) to advertise the corresponding (AFI, SAFI) pair, as specified in 166 [RFC4760]. 168 The format of "Link-State NLRI" is defined in 169 [I-D.ietf-idr-ls-distribution]. Two new "NLRI Type" are defined for 170 TE LSP Identifier Information as following: 172 o NLRI Type = 5: IPv4 TE LSP NLRI 174 o NLRI Type = 6: IPv6 TE LSP NLRI 176 The IPv4 TE LSP NLRI (NLRI Type = 5) is shown in the following 177 figure: 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+ 182 | Protocol-ID | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Identifier | 185 | (64 bits) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | IPv4 Tunnel Sender Address | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Tunnel ID | LSP ID | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | IPv4 Tunnel End-point Address | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 2. IPv4 TE LSP NLRI 195 The IPv6 TE LSP NLRI (NLRI Type = 6) is shown in the following 196 figure: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+ 201 | Protocol-ID | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Identifier | 204 | (64 bits) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 + + 208 | IPv6 Tunnel Sender Address | 209 + (16 octets) + 210 | | 211 + + 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Tunnel ID | LSP ID | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | | 217 + + 218 | IPv6 Tunnel End-point Address | 219 + (16 octets) + 220 | | 221 + + 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 3. IPv6 TE LSP NLRI 226 For IPv4 and IPv6 TE LSP NLRI, the Protocol-ID field specifies the 227 type of signaling of the TE LSP. The following Protocol-IDs applies 228 to IPv4/IPv6 TE LSP NLRI: 230 +-------------+----------------------------------+ 231 | Protocol-ID | NLRI information source protocol | 232 +-------------+----------------------------------+ 233 | TBD | RSVP-TE | 234 | TBD | Segment Routing | 235 +-------------+----------------------------------+ 237 The 64-Bit 'Identifier' field is used to discriminate between 238 instances with different LSP technologies. The default identifier 239 "0" identifies the instance for packet switched LSPs. A new 240 identifier TBD is used to identify the instance of optical layer 241 LSPs. 243 The other fields in the IPv4 TE LSP NLRI and IPv6 TE LSP NLRI are the 244 same as defined in [RFC3209]. When the Protocol-ID is set to Segment 245 Routing, the Tunnel ID and LSP ID field SHOULD be filled with the 246 source node's locally generated identifiers which can uniquely 247 identify a specific SR LSP. 249 2.2. LSP State Information 251 The LSP State TLV is used to describe the characteristics of the TE 252 LSPs, which is carried in the optional non-transitive BGP Attribute 253 "LINK_STATE Attribute" defined in [I-D.ietf-idr-ls-distribution]. 255 The "Value" field of the LSP State TLV corresponds to the format and 256 semantics of a set of objects defined in [RFC3209], [RFC3473] and 257 other extensions for TE LSPs. Rather than replicating all RSVP-TE 258 related objects in this document, the semantics and encodings of the 259 existing TE LSP objects are re-used. Hence all TE LSP objects are 260 regarded as sub-TLVs. The LSP State TLV SHOULD only be used with 261 IPv4/IPv6 TE LSP NLRI. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 ~ TE LSP Objects (variable) ~ 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 4. LSP State TLV 274 Currently the TE LSP Objects that can be carried in the LSP State TLV 275 include: 277 o SENDER_TSPEC and FLOW_SPEC [RFC2205] 279 o SESSION_ATTRIBUTE [RFC3209] 281 o Explicit Route Object (ERO) [RFC3209] 283 o Record Route Object (RRO) [RFC3209] 285 o FAST_REROUTE Object [RFC4090] 287 o DETOUR Object [RFC4090] 289 o EXCLUDE_ROUTE Object (XRO) [RFC4874] 291 o SECONDARY_EXPLICIT_ROUTE Object (SERO) [RFC4873] 293 o SECONDARY_RECORD_ROUTE (SRRO) [RFC4873] 295 o LSP_ATTRIBUTES Object [RFC5420] 297 o LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 299 o PROTECTION Object [RFC3473][RFC4872][RFC4873] 301 o ASSOCIATION Object [RFC4872] 303 o PRIMARY_PATH_ROUTE Object [RFC4872] 305 o ADMIN_STATUS Object [RFC3473] 307 o BANDWIDTH Object [RFC5440] 309 o METRIC Object [RFC5440] 311 For the TE LSP Objects listed above, the corresponding subobjects are 312 also applicable to this mechanism. Other TE LSP objects which 313 reflect specific states or attributes of the LSP may also be carried 314 in the LSP state TLV, which is for further study. 316 3. Operational Considerations 318 The Existing BGP operational procedures apply to this document. No 319 new operation procedures are defined in this document. The 320 operational considerations as specified in 321 [I-D.ietf-idr-ls-distribution] apply to this document. 323 In general the ingress nodes of the LSPs are responsible for the 324 distribution of LSP state information, while other nodes on the LSP 325 path may report the LSP information if needed, e.g. the border 326 routers in the inter-domain case, where the ingress node may not have 327 the complete information of the end-to-end path. 329 4. IANA Considerations 331 IANA is requested to administer the assignment of new values defined 332 in this document and summarized in this section. 334 IANA needs to assign one new TLV type for "LSP State TLV" from the 335 registry of BGP-LS Attribute TLVs. 337 4.1. BGP-LS NLRI-Types 339 IANA maintains a registry called "Border Gateway Protocol - Link 340 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI- 341 Types". 343 IANA is requested to assign two new NLRI-Types: 345 +------+---------------------------+---------------+ 346 | Type | NLRI Type | Reference | 347 +------+---------------------------+---------------+ 348 | 5 | IPv4 TE LSP NLRI | this document | 349 | 6 | IPv6 TE LSP NLRI | this document | 350 +------+---------------------------+---------------+ 352 4.2. BGP-LS Protocol-IDs 354 IANA maintains a registry called "Border Gateway Protocol - Link 355 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS 356 Protocol-IDs". 358 IANA is requested to assign two new Protocol-IDs: 360 +-------------+----------------------------------+---------------+ 361 | Protocol-ID | NLRI information source protocol | Reference | 362 +-------------+----------------------------------+---------------+ 363 | TBD | RSVP-TE | this document | 364 | TBD | Segment Routing | this document | 365 +-------------+----------------------------------+---------------+ 367 4.3. BGP-LS Instance-IDs 369 IANA maintains a registry called "Border Gateway Protocol - Link 370 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS Well- 371 known Instance-IDs". 373 IANA is requested to assign one new Instance-ID: 375 +------------+----------------------------------+---------------+ 376 | Identifier | Routing Universe | Reference: | 377 +------------+----------------------------------+---------------+ 378 | TBD | Default Optical Network Topology | this document | 379 +------------+----------------------------------+---------------+ 381 4.4. BGP-LS Attribute TLVs 383 IANA maintains a registry called "Border Gateway Protocol - Link 384 State (BGP-LS) Parameters" with a sub-registry called "Node Anchor, 385 Link Descriptor and Link Attribute TLVs". 387 IANA is requested to assign one new TLV code point: 389 +-----------+---------------------+---------------+-----------------+ 390 | TLV Code | Description | IS-IS TLV/ | Value defined | 391 | Point | | Sub-TLV | in: | 392 +-----------+---------------------+---------------+-----------------+ 393 | TBD | LSP State TLV | --- | this document | 394 +-----------+---------------------+---------------+-----------------+ 396 5. Security Considerations 398 Procedures and protocol extensions defined in this document do not 399 affect the BGP security model. See [RFC6952] for details. 401 6. Acknowledgements 403 The authors would like to thank Dhruv Dhody and Mohammed Abdul Aziz 404 Khalid for their review and valuable comments. 406 7. References 408 7.1. Normative References 410 [I-D.ietf-idr-ls-distribution] 411 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 412 Ray, "North-Bound Distribution of Link-State and TE 413 Information using BGP", draft-ietf-idr-ls-distribution-10 414 (work in progress), January 2015. 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 420 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 421 Functional Specification", RFC 2205, September 1997. 423 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 424 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 425 Tunnels", RFC 3209, December 2001. 427 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 428 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 429 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 431 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 432 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 433 2005. 435 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 436 "Multiprotocol Extensions for BGP-4", RFC 4760, January 437 2007. 439 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 440 Extensions in Support of End-to-End Generalized Multi- 441 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 442 2007. 444 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 445 "GMPLS Segment Recovery", RFC 4873, May 2007. 447 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 448 Extension to Resource ReserVation Protocol-Traffic 449 Engineering (RSVP-TE)", RFC 4874, April 2007. 451 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 452 Ayyangarps, "Encoding of Attributes for MPLS LSP 453 Establishment Using Resource Reservation Protocol Traffic 454 Engineering (RSVP-TE)", RFC 5420, February 2009. 456 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 457 (PCE) Communication Protocol (PCEP)", RFC 5440, March 458 2009. 460 7.2. Informative References 462 [I-D.ietf-pce-stateful-pce] 463 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 464 Extensions for Stateful PCE", draft-ietf-pce-stateful- 465 pce-11 (work in progress), April 2015. 467 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 468 Element (PCE)-Based Architecture", RFC 4655, August 2006. 470 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 471 BGP, LDP, PCEP, and MSDP Issues According to the Keying 472 and Authentication for Routing Protocols (KARP) Design 473 Guide", RFC 6952, May 2013. 475 Authors' Addresses 477 Jie Dong 478 Huawei Technologies 479 Huawei Campus, No. 156 Beiqing Rd. 480 Beijing 100095 481 China 483 Email: jie.dong@huawei.com 485 Mach(Guoyi) Chen 486 Huawei Technologies 487 Huawei Campus, No. 156 Beiqing Rd. 488 Beijing 100095 489 China 491 Email: mach.chen@huawei.com 493 Hannes Gredler 494 Juniper Networks, Inc. 495 1194 N. Mathilda Ave. 496 Sunnyvale, CA 94089 497 US 499 Email: hannes@juniper.net 500 Stefano Previdi 501 Cisco Systems, Inc. 502 Via Del Serafico, 200 503 Rome 00142 504 Italy 506 Email: sprevidi@cisco.com 508 Jeff Tantsura 509 Ericsson 510 300 Holger Way 511 San Jose, CA 95134 512 US 514 Email: jeff.tantsura@ericsson.com