idnits 2.17.1 draft-ietf-idr-te-lsp-distribution-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 (January 5, 2015) is 3398 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 (-13) exists of draft-ietf-idr-ls-distribution-07 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-10 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: July 9, 2015 H. Gredler 6 Juniper Networks, Inc. 7 S. Previdi 8 Cisco Systems, Inc. 9 J. Tantsura 10 Ericsson 11 January 5, 2015 13 Distribution of MPLS Traffic Engineering (TE) LSP State using BGP 14 draft-ietf-idr-te-lsp-distribution-02 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 July 9, 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 . . . . . . . . . . . . . . . . . . 5 67 3. Operational Considerations . . . . . . . . . . . . . . . . . 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 In some network environments, the states of established Multi- 79 Protocol Label Switching (MPLS) Traffic Engineering (TE) Label 80 Switched Paths (LSPs) in the network are required by some components 81 external to the network domain. Usually this information is directly 82 maintained by the ingress Label Edge Routers (LERs) of the MPLS TE 83 LSPs. 85 One example of using the LSP information is stateful Path Computation 86 Element (PCE) [I-D.ietf-pce-stateful-pce], which could provide 87 benefits in path reoptimization . While some extensions are proposed 88 in Path Computation Element Communication Protocol (PCEP) for the 89 Path Computation Clients (PCCs) to report the LSP states to the PCE, 90 this mechanism may not be applicable in a management-based PCE 91 architecture as specified in section 5.5 of [RFC4655]. As 92 illustrated in the figure below, the PCC is not an LSR in the routing 93 domain, thus the head-end nodes of the TE-LSP may not implement the 94 PCEP protocol. In this case some general mechanism to collect the 95 TE-LSP states from the ingress LERs is needed. This document 96 proposes an LSP state collection mechanism complementary to the 97 mechanism defined in [I-D.ietf-pce-stateful-pce]. 99 ----------- 100 | ----- | 101 Service | | TED |<-+-----------> 102 Request | ----- | TED synchronization 103 | | | | mechanism (for example, 104 v | | | routing protocol) 105 ------------- Request/ | v | 106 | | Response| ----- | 107 | NMS |<--------+> | PCE | | 108 | | | ----- | 109 ------------- ----------- 110 Service | 111 Request | 112 v 113 ---------- Signaling ---------- 114 | Head-End | Protocol | Adjacent | 115 | Node |<---------->| Node | 116 ---------- ---------- 118 Figure 1. Management-Based PCE Usage 120 In networks with composite PCE nodes as specified in section 5.1 of 121 [RFC4655], the PCE is implemented on several routers in the network, 122 and the PCCs in the network can use the mechanism described in 123 [I-D.ietf-pce-stateful-pce] to report the LSP information to the PCE 124 nodes. An external component may further need to collect the LSP 125 information from all the PCEs in the network to get a global view of 126 the LSP states in the network. 128 In multi-area or multi-AS scenarios, each area or AS can have a child 129 PCE to collect the LSP states of its own domain, in addition a parent 130 PCE needs to collect the LSP information from multiple child PCEs to 131 obtain a global view of LSPs inside and across the domains involved. 133 In another network scenario, a centralized controller is used for 134 service placement. Obtaining the TE LSP state information is quite 135 important for making appropriate service placement decisions with the 136 purpose of both meeting the application's requirements and utilizing 137 the network resource efficiently. 139 The Network Management System (NMS) may need to provide global 140 visibility of the TE LSPs in the network as part of the network 141 visualization function. 143 BGP has been extended to distribute link-state and traffic 144 engineering information to some external components 145 [I-D.ietf-idr-ls-distribution]. Using the same protocol to collect 146 other network layer information would be desirable for the external 147 components, which avoids introducing multiple protocols for network 148 information collection. This document describes a mechanism to 149 distribute the TE LSP information to external components using BGP. 151 2. Carrying LSP State Information in BGP 153 2.1. LSP Identifier Information 155 The TE LSP Identifier information is advertised in BGP UPDATE 156 messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes 157 [RFC4760]. The "Link State NLRI" defined in 158 [I-D.ietf-idr-ls-distribution] is extended to carry the TE LSP 159 Identifier information. BGP speakers that wish to exchange TE LSP 160 information MUST use the BGP Multiprotocol Extensions Capability Code 161 (1) to advertise the corresponding (AFI, SAFI) pair, as specified in 162 [RFC4760]. 164 The format of "Link State NLRI" is defined in 165 [I-D.ietf-idr-ls-distribution]. Two new "NLRI Type" are defined for 166 TE LSP Identifier Information as following: 168 o NLRI Type = 5: IPv4 TE LSP NLRI 170 o NLRI-Type = 6: IPv6 TE LSP NLRI 172 The IPv4 TE LSP NLRI (NLRI Type = 5) is shown in the following 173 figure: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+ 178 | Protocol-ID | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Identifier | 181 | (64 bits) | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | IPv4 Tunnel Sender Address | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Tunnel ID | LSP ID | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | IPv4 Tunnel End-point Address | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 2. IPv4 TE LSP NLRI 191 The IPv6 TE LSP NLRI (NLRI Type = 6) is shown in the following 192 figure: 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+ 197 | Protocol-ID | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Identifier | 200 | (64 bits) | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 + + 204 | IPv6 Tunnel Sender Address | 205 + (16 octets) + 206 | | 207 + + 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Tunnel ID | LSP ID | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 213 + + 214 | IPv6 Tunnel End-point Address | 215 + (16 octets) + 216 | | 217 + + 218 | | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 3. IPv6 TE LSP NLRI 222 For IPv4 TE LSP NLRI and IPv6 TE LSP NLRI, the Protocol-ID field is 223 set to 6, which indicates that the NLRI information has been sourced 224 by RSVP-TE. 226 The Identifier field is used to discriminate between instances with 227 different LSP technology - e.g. one identifier can identify the 228 instance for packet path, and another one is to identify the instance 229 of optical path. 231 The other fields in the IPv4 TE LSP NLRI and IPv6 TE LSP NLRI are the 232 same as specified in [RFC3209]. 234 2.2. LSP State Information 236 The LSP State TLV is used to describe the characteristics of the TE 237 LSPs, which is carried in the optional non-transitive BGP Attribute 238 "LINK_STATE Attribute" defined in [I-D.ietf-idr-ls-distribution]. 240 The "Value" field of the LSP State TLV corresponds to the format and 241 semantics of a set of objects defined in [RFC3209], [RFC3473] and 242 other extensions for TE LSPs. Rather than replicating all RSVP-TE 243 related objects in this document, the semantics and encodings of 244 existing TE LSP objects are re-used. Hence all TE LSP objects are 245 regarded as sub-TLVs. The LSP State TLV SHOULD only be used with 246 IPv4/IPv6 TE LSP NLRI. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 ~ TE LSP Objects (variable) ~ 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 4. LSP State TLV 259 Currently the TE LSP Objects that can be carried in the LSP State TLV 260 include: 262 o SENDER_TSPEC and FLOW_SPEC [RFC2205] 264 o SESSION_ATTRIBUTE [RFC3209] 266 o Explicit Route Object (ERO) [RFC3209] 268 o Record Route Object (RRO) [RFC3209] 270 o FAST_REROUTE Object [RFC4090] 272 o DETOUR Object [RFC4090] 274 o EXCLUDE_ROUTE Object (XRO) [RFC4874] 276 o SECONDARY_EXPLICIT_ROUTE Object (SERO) [RFC4873] 278 o SECONDARY_RECORD_ROUTE (SRRO) [RFC4873] 280 o LSP_ATTRIBUTES Object [RFC5420] 282 o LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 284 o PROTECTION Object [RFC3473][RFC4872][RFC4873] 286 o ASSOCIATION Object [RFC4872] 287 o PRIMARY_PATH_ROUTE Object [RFC4872] 289 o ADMIN_STATUS Object [RFC3473] 291 o BANDWIDTH Object [RFC5440] 293 o METRIC Object [RFC5440] 295 Other TE LSP objects which reflect specific state or attribute of the 296 LSP may also be carried in the LSP state TLV, which is for further 297 study. 299 3. Operational Considerations 301 The Existing BGP operational procedures apply to this document. No 302 new operation procedures are defined in this document. The 303 operational considerations as specified in 304 [I-D.ietf-idr-ls-distribution] apply to this document . 306 4. IANA Considerations 308 IANA needs to assign two code points for "IPv4 TE LSP NLRI" and "IPv6 309 TE LSP NLRI" from the BGP-LS registry of NLRI Types. 311 IANA needs to assign one Protocol-ID for "RSVP-TE" from the BGP-LS 312 registry of Protocol-IDs. 314 IANA needs to assign one new TLV type for "LSP State TLV" from the 315 registry of BGP-LS Attribute TLVs. 317 5. Security Considerations 319 Procedures and protocol extensions defined in this document do not 320 affect the BGP security model. See [RFC6952] for details. 322 6. Acknowledgements 324 The authors would like to thank Dhruv Dhody and Mohammed Abdul Aziz 325 Khalid for their review and valuable comments. 327 7. References 329 7.1. Normative References 331 [I-D.ietf-idr-ls-distribution] 332 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 333 Ray, "North-Bound Distribution of Link-State and TE 334 Information using BGP", draft-ietf-idr-ls-distribution-07 335 (work in progress), November 2014. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 341 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 342 Functional Specification", RFC 2205, September 1997. 344 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 345 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 346 Tunnels", RFC 3209, December 2001. 348 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 349 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 350 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 352 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 353 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 354 2005. 356 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 357 "Multiprotocol Extensions for BGP-4", RFC 4760, January 358 2007. 360 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 361 Extensions in Support of End-to-End Generalized Multi- 362 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 363 2007. 365 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 366 "GMPLS Segment Recovery", RFC 4873, May 2007. 368 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 369 Extension to Resource ReserVation Protocol-Traffic 370 Engineering (RSVP-TE)", RFC 4874, April 2007. 372 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 373 Ayyangarps, "Encoding of Attributes for MPLS LSP 374 Establishment Using Resource Reservation Protocol Traffic 375 Engineering (RSVP-TE)", RFC 5420, February 2009. 377 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 378 (PCE) Communication Protocol (PCEP)", RFC 5440, March 379 2009. 381 7.2. Informative References 383 [I-D.ietf-pce-stateful-pce] 384 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 385 Extensions for Stateful PCE", draft-ietf-pce-stateful- 386 pce-10 (work in progress), October 2014. 388 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 389 Element (PCE)-Based Architecture", RFC 4655, August 2006. 391 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 392 BGP, LDP, PCEP, and MSDP Issues According to the Keying 393 and Authentication for Routing Protocols (KARP) Design 394 Guide", RFC 6952, May 2013. 396 Authors' Addresses 398 Jie Dong 399 Huawei Technologies 400 Huawei Campus, No. 156 Beiqing Rd. 401 Beijing 100095 402 China 404 Email: jie.dong@huawei.com 406 Mach(Guoyi) Chen 407 Huawei Technologies 408 Huawei Campus, No. 156 Beiqing Rd. 409 Beijing 100095 410 China 412 Email: mach.chen@huawei.com 414 Hannes Gredler 415 Juniper Networks, Inc. 416 1194 N. Mathilda Ave. 417 Sunnyvale, CA 94089 418 US 420 Email: hannes@juniper.net 421 Stefano Previdi 422 Cisco Systems, Inc. 423 Via Del Serafico, 200 424 Rome 00142 425 Italy 427 Email: sprevidi@cisco.com 429 Jeff Tantsura 430 Ericsson 431 300 Holger Way 432 San Jose, CA 95134 433 US 435 Email: jeff.tantsura@ericsson.com