idnits 2.17.1 draft-dong-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 (October 15, 2012) is 4209 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-00 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-01 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: April 18, 2013 October 15, 2012 7 Distribution of MPLS Traffic Engineering (TE) LSP State using BGP 8 draft-dong-idr-te-lsp-distribution-00 10 Abstract 12 This document describes a mechanism to collect the Traffic 13 Engineering (TE) LSP information using BGP. Such information can be 14 used by external components for path reoptimization, service 15 placement and network visualization. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 18, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Carrying LSP State Information in BGP . . . . . . . . . . . . . 4 59 2.1. LSP Information NLRI . . . . . . . . . . . . . . . . . . . 4 60 2.2. LSP State Attribute . . . . . . . . . . . . . . . . . . . . 6 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 In some network environments, the states of established Multi- 72 Protocol Label Switching (MPLS) Traffic Engineering (TE) Label 73 Switched Paths (LSPs) in the network are required by some components 74 external to the network domain. Usually this information is directly 75 maintained by the ingress Label Edge Routers (LERs) of the MPLS TE 76 LSPs. 78 One example of using the LSP information is stateful Path Computation 79 Element (PCE) [I-D.ietf-pce-stateful-pce], which could provide 80 benefits in path reoptimization . While some extensions are proposed 81 in Path Computation Element Communication Protocol (PCEP) for the 82 Path Computation Clients (PCCs) to report the LSP states to the PCE, 83 this mechanism may not be applicable in a management-based PCE 84 architecture as specified in section 5.5 of [RFC4655]. As 85 illustrated in the figure below, the PCC is not an LSR in the routing 86 domain, thus the head-end nodes of the TE-LSP may not implement the 87 PCEP protocol. In this case some general mechanism to collect the 88 TE-LSP states from the ingress LERs is needed. This document 89 proposes an LSP state collection mechanism complementary to the 90 mechanism defined in [I-D.ietf-pce-stateful-pce]. 92 ----------- 93 | ----- | 94 Service | | TED |<-+-----------> 95 Request | ----- | TED synchronization 96 | | | | mechanism (for example, 97 v | | | routing protocol) 98 ------------- Request/ | v | 99 | | Response| ----- | 100 | NMS |<--------+> | PCE | | 101 | | | ----- | 102 ------------- ----------- 103 Service | 104 Request | 105 v 106 ---------- Signaling ---------- 107 | Head-End | Protocol | Adjacent | 108 | Node |<---------->| Node | 109 ---------- ---------- 111 Figure 1. Management-Based PCE Usage 113 In networks with composite PCE nodes as specified in section 5.1 of 114 [RFC4655], the PCE is implemented on some routers in the network, and 115 the PCCs in the network can use the mechanism described in 116 [I-D.ietf-pce-stateful-pce] to report the LSP information to the PCE 117 nodes. An external component may further need to collect the LSP 118 information from all the PCEs in the network to get a global view of 119 the LSP states in the network. 121 In some networks, a centralized controller is used for service 122 placement. Obtaining the TE LSP state information is quite important 123 for making appropriate service placement decisions with the purpose 124 of both meeting the application's requirements and utilizing the 125 network resource efficiently. 127 The Network Management System (NMS) may need to provide global 128 visibility of the TE LSPs in the network as part of the network 129 visualization. 131 BGP has been extended to distribute link-state and traffic 132 engineering information and share with some external components 133 [I-D.ietf-idr-ls-distribution]. Using the same protocol to collect 134 other network layer information would be desired by the external 135 components, which avoids introducing multiple protocols for network 136 information collection. This document describes a mechanism to 137 distribute the TE LSP information to external components using BGP. 139 2. Carrying LSP State Information in BGP 141 2.1. LSP Information NLRI 143 A new NLRI "LSP Information NLRI" is advertised in BGP UPDATE 144 messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes 145 [RFC4760]. The AFI value is TBD, the SAFI value can be 1 for LSPs in 146 the public network. BGP speakers that wish to exchange LSP 147 Information NLRI MUST use the BGP Multiprotocol Extensions Capability 148 Code (1) to advertise the corresponding (AFI, SAFI) pair, as 149 specified in [RFC4760]. 151 The format of the LSP Information NLRI is as follows: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | NLRI-Type | Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | LSP-IDENTIFIER (variable) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 2. LSP Information NLRI 162 The NLRI-Type field can be one of the following values: 164 o NLRI-Type = 1: IPv4 LSP NLRI 166 o NLRI-Type = 2: IPv6 LSP NLRI 168 If the NLRI-Type value is set to 1, the LSP-IDENTIFIER is the IPv4- 169 LSP-IDENTIFER structured as below: 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | IPv4 Tunnel Sender Address | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Tunnel ID | LSP ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | IPv4 Tunnel End-point Address | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 3. IPv4-LSP-IDENTIFIER 182 If the NLRI-Type value is set to 2, the LSP-IDENTIFIER is the IPv6- 183 LSP-IDENTIFIER structured as below: 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 | | 189 + + 190 | IPv6 Tunnel Sender Address | 191 + (16 octets) + 192 | | 193 + + 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Tunnel ID | LSP ID | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | | 199 + + 200 | IPv6 Tunnel End-point Address | 201 + (16 octets) + 202 | | 203 + + 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 4. IPv6-LSP-IDENTIFIER 208 The fields in the IPv4-LSP-IDENTIFIER and IPv6-LSP-IDENTIFIER are the 209 same as specified in [RFC3209]. 211 2.2. LSP State Attribute 213 The LSP State Attribute is an optional non-transitive BGP attribute 214 which is used to describe the characteristics of the LSPs. The LSP 215 State Attribute consists of a set of objects defined in [RFC3209], 216 [RFC3473] and [RFC5440] . This Attribute SHOULD only be used with 217 the LSP Information NLRI. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 ~ Objects (variable) ~ 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 5. LSP State Attribute 228 Currently the Objects that can be carried in the LSP State Attribute 229 include: 231 o LSP Attributes (LSPA) Object 233 o Explicit Route Object (ERO) 235 o Record Route Object (RRO) 237 o BANDWIDTH Object 239 o METRIC Object 241 o Protection Object 243 o Admin Status Object 245 Other Objects may also be carried in the LSP State Attribute, which 246 would be specified in a future version. 248 3. IANA Considerations 250 IANA needs to assign a new AFI value for the LSP Information NLRI. 251 This code point will come from the "Address Family Numbers" registry. 253 IANA needs to assign an new code point for the LSP State Attribute 254 from the "BGP Path Attributes" registry. 256 4. Security Considerations 258 TBD 260 5. Acknowledgements 262 6. References 264 6.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 270 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 271 Tunnels", RFC 3209, December 2001. 273 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 274 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 275 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 277 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 278 "Multiprotocol Extensions for BGP-4", RFC 4760, 279 January 2007. 281 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 282 (PCE) Communication Protocol (PCEP)", RFC 5440, 283 March 2009. 285 6.2. Informative References 287 [I-D.ietf-idr-ls-distribution] 288 Gredler, H., Medved, J., Previdi, S., and A. Farrel, 289 "North-Bound Distribution of Link-State and TE Information 290 using BGP", draft-ietf-idr-ls-distribution-00 (work in 291 progress), September 2012. 293 [I-D.ietf-pce-stateful-pce] 294 Crabbe, E., Medved, J., Varga, R., and I. Minei, "PCEP 295 Extensions for Stateful PCE", 296 draft-ietf-pce-stateful-pce-01 (work in progress), 297 July 2012. 299 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 300 Element (PCE)-Based Architecture", RFC 4655, August 2006. 302 Authors' Addresses 304 Jie Dong 305 Huawei Technologies 306 Huawei Building, No. 156 Beiqing Rd. 307 Beijing 100095 308 China 310 Email: jie.dong@huawei.com 312 Mach(Guoyi) Chen 313 Huawei Technologies 314 Huawei Building, No. 156 Beiqing Rd. 315 Beijing 100095 316 China 318 Email: mach.chen@huawei.com