idnits 2.17.1 draft-ietf-idr-te-lsp-distribution-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 : ---------------------------------------------------------------------------- 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 24, 2014) is 3716 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-04 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-07 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 28, 2014 H. Gredler 6 Juniper Networks, Inc. 7 S. Previdi 8 Cisco Systems, Inc. 9 January 24, 2014 11 Distribution of MPLS Traffic Engineering (TE) LSP State using BGP 12 draft-ietf-idr-te-lsp-distribution-00 14 Abstract 16 This document describes a mechanism to collect the Traffic 17 Engineering (TE) LSP information using BGP. Such information can be 18 used by external components for path reoptimization, service 19 placement and network visualization. 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 July 28, 2014. 44 Copyright Notice 46 Copyright (c) 2014 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 LSP State Information in BGP . . . . . . . . . . . . 4 63 2.1. LSP Identifier Information . . . . . . . . . . . . . . . 4 64 2.2. LSP State Information . . . . . . . . . . . . . . . . . . 5 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 5.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 In some network environments, the states of established Multi- 75 Protocol Label Switching (MPLS) Traffic Engineering (TE) Label 76 Switched Paths (LSPs) in the network are required by some components 77 external to the network domain. Usually this information is directly 78 maintained by the ingress Label Edge Routers (LERs) of the MPLS TE 79 LSPs. 81 One example of using the LSP information is stateful Path Computation 82 Element (PCE) [I-D.ietf-pce-stateful-pce], which could provide 83 benefits in path reoptimization . While some extensions are proposed 84 in Path Computation Element Communication Protocol (PCEP) for the 85 Path Computation Clients (PCCs) to report the LSP states to the PCE, 86 this mechanism may not be applicable in a management-based PCE 87 architecture as specified in section 5.5 of [RFC4655]. As 88 illustrated in the figure below, the PCC is not an LSR in the routing 89 domain, thus the head-end nodes of the TE-LSP may not implement the 90 PCEP protocol. In this case some general mechanism to collect the 91 TE-LSP states from the ingress LERs is needed. This document 92 proposes an LSP state collection mechanism complementary to the 93 mechanism defined in [I-D.ietf-pce-stateful-pce]. 95 ----------- 96 | ----- | 97 Service | | TED |<-+-----------> 98 Request | ----- | TED synchronization 99 | | | | mechanism (for example, 100 v | | | routing protocol) 101 ------------- Request/ | v | 102 | | Response| ----- | 103 | NMS |<--------+> | PCE | | 104 | | | ----- | 105 ------------- ----------- 106 Service | 107 Request | 108 v 109 ---------- Signaling ---------- 110 | Head-End | Protocol | Adjacent | 111 | Node |<---------->| Node | 112 ---------- ---------- 114 Figure 1. Management-Based PCE Usage 116 In networks with composite PCE nodes as specified in section 5.1 of 117 [RFC4655], the PCE is implemented on several routers in the network, 118 and the PCCs in the network can use the mechanism described in 119 [I-D.ietf-pce-stateful-pce] to report the LSP information to the PCE 120 nodes. An external component may further need to collect the LSP 121 information from all the PCEs in the network to get a global view of 122 the LSP states in the network. 124 In some networks, a centralized controller is used for service 125 placement. Obtaining the TE LSP state information is quite important 126 for making appropriate service placement decisions with the purpose 127 of both meeting the application's requirements and utilizing the 128 network resource efficiently. 130 The Network Management System (NMS) may need to provide global 131 visibility of the TE LSPs in the network as part of the network 132 visualization function. 134 BGP has been extended to distribute link-state and traffic 135 engineering information and share with some external components 136 [I-D.ietf-idr-ls-distribution]. Using the same protocol to collect 137 other network layer information would be desired by the external 138 components, which avoids introducing multiple protocols for network 139 information collection. This document describes a mechanism to 140 distribute the TE LSP information to external components using BGP. 142 2. Carrying LSP State Information in BGP 144 2.1. LSP Identifier Information 146 The TE LSP Identifier information is advertised in BGP UPDATE 147 messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes 148 [RFC4760]. The "Link State NLRI" defined in 149 [I-D.ietf-idr-ls-distribution] is extended to carry the TE LSP 150 Identifier information. BGP speakers that wish to exchange TE LSP 151 information MUST use the BGP Multiprotocol Extensions Capability Code 152 (1) to advertise the corresponding (AFI, SAFI) pair, as specified in 153 [RFC4760]. 155 The format of "Link State NLRI" is defined in 156 [I-D.ietf-idr-ls-distribution]. Two new "NLRI Type" are defined for 157 TE LSP Identifier Information as following: 159 o NLRI Type = 5: IPv4 TE LSP NLRI 161 o NLRI-Type = 6: IPv6 TE LSP NLRI 163 The IPv4 TE LSP NLRI (NLRI Type = 5) is shown in the following 164 figure: 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+ 169 | Protocol-ID | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Identifier | 172 | (64 bits) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | IPv4 Tunnel Sender Address | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Tunnel ID | LSP ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | IPv4 Tunnel End-point Address | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 2. IPv4 TE LSP NLRI 182 The IPv6 TE LSP NLRI (NLRI Type = 6) is shown in the following 183 figure: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+ 188 | Protocol-ID | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Identifier | 191 | (64 bits) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 + + 195 | IPv6 Tunnel Sender Address | 196 + (16 octets) + 197 | | 198 + + 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Tunnel ID | LSP ID | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | 204 + + 205 | IPv6 Tunnel End-point Address | 206 + (16 octets) + 207 | | 208 + + 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 3. IPv6 TE LSP NLRI 213 For IPv4 TE LSP NLRI and IPv6 TE LSP NLRI, the Protocol-ID field is 214 set to 6, which indicates that the NLRI information has been sourced 215 by RSVP-TE. 217 The Identifier field is used to discriminate between instances with 218 different LSP technology - e.g. one identifier can identify the 219 instance for packet path, and another one is to identify the instance 220 of optical path. 222 The other fields in the IPv4 TE LSP NLRI and IPv6 TE LSP NLRI are the 223 same as specified in [RFC3209]. 225 2.2. LSP State Information 227 The LSP State TLV is used to describe the characteristics of the TE 228 LSPs, which is carried in the optional non-transitive BGP Attribute 229 "LINK_STATE Attribute" defined in [I-D.ietf-idr-ls-distribution]. 231 The "Value" field of the LSP State TLV corresponds to the format and 232 semantics of a set of objects defined in [RFC3209], [RFC3473] and 234 [RFC5440] for TE LSPs. Rather than replicating all RSVP-TE related 235 objects in this document the semantics and encodings of existing 236 RSVP-TE objects are re-used. Hence all RSVP-TE LSP objects are 237 regarded as sub-TLVs. The LSP State TLV SHOULD only be used with 238 IPv4/IPv6 TE LSP NLRI. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type | Length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 ~ TE LSP Objects (variable) ~ 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 4. LSP State TLV 251 Currently the TE LSP Objects that can be carried in the LSP State TLV 252 include: 254 o LSP Attributes (LSPA) Object [RFC5440] 256 o Explicit Route Object (ERO) [RFC3209] 258 o Record Route Object (RRO) [RFC3209] 260 o BANDWIDTH Object [RFC5440] 262 o METRIC Object [RFC5440] 264 o Protection Object [RFC3473] 266 o Admin_Status Object [RFC3473] 268 Other TE LSP objects may also be carried in LSP state TLV, which is 269 for further study. 271 3. IANA Considerations 273 IANA needs to assign one new TLV type for "LSP State TLV" from the 274 TLV registry of Link_State Attribute. 276 IANA needs to assign one Protocol-ID for 'RSVP-TE' from the BGP-TE/LS 277 registry of Protocol-IDs. 279 4. Security Considerations 281 Procedures and protocol extensions defined in this document do not 282 affect the BGP security model. See [RFC6952] for details. 284 5. References 286 5.1. Normative References 288 [I-D.ietf-idr-ls-distribution] 289 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 290 Ray, "North-Bound Distribution of Link-State and TE 291 Information using BGP", draft-ietf-idr-ls-distribution-04 292 (work in progress), November 2013. 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 298 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 299 Tunnels", RFC 3209, December 2001. 301 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 302 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 303 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 305 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 306 "Multiprotocol Extensions for BGP-4", RFC 4760, January 307 2007. 309 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 310 (PCE) Communication Protocol (PCEP)", RFC 5440, March 311 2009. 313 5.2. Informative References 315 [I-D.ietf-pce-stateful-pce] 316 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 317 Extensions for Stateful PCE", draft-ietf-pce-stateful- 318 pce-07 (work in progress), October 2013. 320 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 321 Element (PCE)-Based Architecture", RFC 4655, August 2006. 323 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 324 BGP, LDP, PCEP, and MSDP Issues According to the Keying 325 and Authentication for Routing Protocols (KARP) Design 326 Guide", RFC 6952, May 2013. 328 Authors' Addresses 330 Jie Dong 331 Huawei Technologies 332 Huawei Building, No. 156 Beiqing Rd. 333 Beijing 100095 334 China 336 Email: jie.dong@huawei.com 338 Mach(Guoyi) Chen 339 Huawei Technologies 340 Huawei Building, No. 156 Beiqing Rd. 341 Beijing 100095 342 China 344 Email: mach.chen@huawei.com 346 Hannes Gredler 347 Juniper Networks, Inc. 348 1194 N. Mathilda Ave. 349 Sunnyvale, CA 94089 350 US 352 Email: hannes@juniper.net 354 Stefano Previdi 355 Cisco Systems, Inc. 356 Via Del Serafico, 200 357 Rome 00142 358 Italy 360 Email: sprevidi@cisco.com