idnits 2.17.1 draft-dong-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 : ---------------------------------------------------------------------------- ** There is 1 instance 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 (July 15, 2013) is 3494 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: 1 error (**), 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: January 16, 2014 H. Gredler 6 Juniper Networks, Inc. 7 S. Previdi 8 Cisco Systems, Inc. 9 July 15, 2013 11 Distribution of MPLS Traffic Engineering (TE) LSP State using BGP 12 draft-dong-idr-te-lsp-distribution-03 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 January 16, 2014. 44 Copyright Notice 46 Copyright (c) 2013 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 233 [RFC5440] for TE LSPs. Rather than replicating all RSVP-TE related 234 objects in this document the semantics and encodings of existing 235 RSVP-TE objects are re-used. Hence all RSVP-TE LSP objects are 236 regarded as sub-TLVs. The LSP State TLV SHOULD only be used with 237 IPv4/IPv6 TE LSP NLRI. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 ~ TE LSP Objects (variable) ~ 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 4. LSP State TLV 250 Currently the TE LSP Objects that can be carried in the LSP State TLV 251 include: 253 o LSP Attributes (LSPA) Object [RFC5440] 255 o Explicit Route Object (ERO) [RFC3209] 257 o Record Route Object (RRO) [RFC3209] 259 o BANDWIDTH Object [RFC5440] 261 o METRIC Object [RFC5440] 263 o Protection Object [RFC3473] 265 o Admin_Status Object [RFC3473] 267 Other TE LSP objects may also be carried in LSP state TLV, which is 268 for further study. 270 3. IANA Considerations 272 IANA needs to assign one new TLV type for "LSP State TLV" from the 273 TLV registry of Link_State Attribute. 275 IANA needs to assign one Protocol-ID for 'RSVP-TE' from the BGP-TE/LS 276 registry of Protocol-IDs. 278 4. Security Considerations 280 TBD 282 5. References 284 5.1. Normative References 286 [I-D.ietf-idr-ls-distribution] 287 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 288 Ray, "North-Bound Distribution of Link-State and TE 289 Information using BGP", draft-ietf-idr-ls-distribution-03 290 (work in progress), May 2013. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 296 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 297 Tunnels", RFC 3209, December 2001. 299 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 300 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 301 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 303 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 304 "Multiprotocol Extensions for BGP-4", RFC 4760, January 305 2007. 307 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 308 (PCE) Communication Protocol (PCEP)", RFC 5440, March 309 2009. 311 5.2. Informative References 313 [I-D.ietf-pce-stateful-pce] 314 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 315 Extensions for Stateful PCE", draft-ietf-pce-stateful- 316 pce-05 (work in progress), July 2013. 318 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 319 Element (PCE)-Based Architecture", RFC 4655, August 2006. 321 Authors' Addresses 323 Jie Dong 324 Huawei Technologies 325 Huawei Building, No. 156 Beiqing Rd. 326 Beijing 100095 327 China 329 Email: jie.dong@huawei.com 331 Mach(Guoyi) Chen 332 Huawei Technologies 333 Huawei Building, No. 156 Beiqing Rd. 334 Beijing 100095 335 China 337 Email: mach.chen@huawei.com 339 Hannes Gredler 340 Juniper Networks, Inc. 341 1194 N. Mathilda Ave. 342 Sunnyvale, CA 94089 343 US 345 Email: hannes@juniper.net 347 Stefano Previdi 348 Cisco Systems, Inc. 349 Via Del Serafico, 200 350 Rome 00142 351 Italy 353 Email: sprevidi@cisco.com