idnits 2.17.1 draft-dong-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 : ---------------------------------------------------------------------------- ** 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 3937 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-03 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-05 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 July 15, 2013 9 Distribution of MPLS Traffic Engineering (TE) LSP State using BGP 10 draft-dong-idr-te-lsp-distribution-02 12 Abstract 14 This document describes a mechanism to collect the Traffic 15 Engineering (TE) LSP information using BGP. Such information can be 16 used by external components for path reoptimization, service 17 placement and network visualization. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 16, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Carrying LSP State Information in BGP . . . . . . . . . . . . 3 61 2.1. LSP Identifier Information . . . . . . . . . . . . . . . 3 62 2.2. LSP State Information . . . . . . . . . . . . . . . . . . 5 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 5.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 In some network environments, the states of established Multi- 73 Protocol Label Switching (MPLS) Traffic Engineering (TE) Label 74 Switched Paths (LSPs) in the network are required by some components 75 external to the network domain. Usually this information is directly 76 maintained by the ingress Label Edge Routers (LERs) of the MPLS TE 77 LSPs. 79 One example of using the LSP information is stateful Path Computation 80 Element (PCE) [I-D.ietf-pce-stateful-pce], which could provide 81 benefits in path reoptimization . While some extensions are proposed 82 in Path Computation Element Communication Protocol (PCEP) for the 83 Path Computation Clients (PCCs) to report the LSP states to the PCE, 84 this mechanism may not be applicable in a management-based PCE 85 architecture as specified in section 5.5 of [RFC4655]. As 86 illustrated in the figure below, the PCC is not an LSR in the routing 87 domain, thus the head-end nodes of the TE-LSP may not implement the 88 PCEP protocol. In this case some general mechanism to collect the 89 TE-LSP states from the ingress LERs is needed. This document 90 proposes an LSP state collection mechanism complementary to the 91 mechanism defined in [I-D.ietf-pce-stateful-pce]. 93 ----------- 94 | ----- | 95 Service | | TED |<-+-----------> 96 Request | ----- | TED synchronization 97 | | | | mechanism (for example, 98 v | | | routing protocol) 99 ------------- Request/ | v | 100 | | Response| ----- | 101 | NMS |<--------+> | PCE | | 102 | | | ----- | 103 ------------- ----------- 104 Service | 105 Request | 106 v 107 ---------- Signaling ---------- 108 | Head-End | Protocol | Adjacent | 109 | Node |<---------->| Node | 110 ---------- ---------- 112 Figure 1. Management-Based PCE Usage 114 In networks with composite PCE nodes as specified in section 5.1 of 115 [RFC4655], the PCE is implemented on several routers in the network, 116 and the PCCs in the network can use the mechanism described in 117 [I-D.ietf-pce-stateful-pce] to report the LSP information to the PCE 118 nodes. An external component may further need to collect the LSP 119 information from all the PCEs in the network to get a global view of 120 the LSP states in the network. 122 In some networks, a centralized controller is used for service 123 placement. Obtaining the TE LSP state information is quite important 124 for making appropriate service placement decisions with the purpose 125 of both meeting the application's requirements and utilizing the 126 network resource efficiently. 128 The Network Management System (NMS) may need to provide global 129 visibility of the TE LSPs in the network as part of the network 130 visualization function. 132 BGP has been extended to distribute link-state and traffic 133 engineering information and share with some external components 134 [I-D.ietf-idr-ls-distribution]. Using the same protocol to collect 135 other network layer information would be desired by the external 136 components, which avoids introducing multiple protocols for network 137 information collection. This document describes a mechanism to 138 distribute the TE LSP information to external components using BGP. 140 2. Carrying LSP State Information in BGP 142 2.1. LSP Identifier Information 143 The TE LSP Identifier information is advertised in BGP UPDATE 144 messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes 145 [RFC4760]. The "Link State NLRI" defined in 146 [I-D.ietf-idr-ls-distribution] is extended to carry the TE LSP 147 Identifier information. BGP speakers that wish to exchange TE LSP 148 information MUST use the BGP Multiprotocol Extensions Capability Code 149 (1) to advertise the corresponding (AFI, SAFI) pair, as specified in 150 [RFC4760]. 152 The format of "Link State NLRI" is defined in 153 [I-D.ietf-idr-ls-distribution]. Two new "NLRI Type" are defined for 154 TE LSP Identifier Information as following: 156 o NLRI Type = 5: IPv4 TE LSP NLRI 158 o NLRI-Type = 6: IPv6 TE LSP NLRI 160 The IPv4 TE LSP NLRI (NLRI Type = 5) is shown in the following 161 figure: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+ 166 | Protocol-ID | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Identifier | 169 | (64 bits) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | IPv4 Tunnel Sender Address | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Tunnel ID | LSP ID | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | IPv4 Tunnel End-point Address | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 2. IPv4 TE LSP NLRI 179 The IPv6 TE LSP NLRI (NLRI Type = 6) is shown in the following 180 figure: 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+ 185 | Protocol-ID | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Identifier | 188 | (64 bits) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 + + 192 | IPv6 Tunnel Sender Address | 193 + (16 octets) + 194 | | 195 + + 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Tunnel ID | LSP ID | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 + + 202 | IPv6 Tunnel End-point Address | 203 + (16 octets) + 204 | | 205 + + 206 | | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 3. IPv6 TE LSP NLRI 210 For IPv4 TE LSP NLRI and IPv6 TE LSP NLRI, the Protocol-ID field is 211 set to 6, which indicates that the NLRI information has been sourced 212 by RSVP-TE. 214 The Identifier field is used to discriminate between instances with 215 different LSP technology - e.g. one identifier can identify the 216 instance for packet path, and another one is to identify the instance 217 of optical path. 219 The other fields in the IPv4 TE LSP NLRI and IPv6 TE LSP NLRI are the 220 same as specified in [RFC3209]. 222 2.2. LSP State Information 224 The LSP State TLV is used to describe the characteristics of the TE 225 LSPs, which is carried in the optional non-transitive BGP Attribute 226 "LINK_STATE Attribute" defined in [I-D.ietf-idr-ls-distribution]. 228 The "Value" field of the LSP State TLV corresponds to the format and 229 semantics of a set of objects defined in [RFC3209], [RFC3473] and 230 [RFC5440] for TE LSPs. Rather than replicating all RSVP-TE related 231 objects in this document the semantics and encodings of existing 232 RSVP-TE objects are re-used. Hence all RSVP-TE LSP objects are 233 regarded as sub-TLVs. The LSP State TLV SHOULD only be used with 234 IPv4/IPv6 TE LSP NLRI. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type | Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 ~ TE LSP Objects (variable) ~ 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 4. LSP State TLV 247 Currently the TE LSP Objects that can be carried in the LSP State TLV 248 include: 250 o LSP Attributes (LSPA) Object [RFC5440] 252 o Explicit Route Object (ERO) [RFC3209] 254 o Record Route Object (RRO) [RFC3209] 256 o BANDWIDTH Object [RFC5440] 258 o METRIC Object [RFC5440] 260 o Protection Object [RFC3473] 262 o Admin_Status Object [RFC3473] 264 Other TE LSP objects may also be carried in LSP state TLV, which is 265 for further study. 267 3. IANA Considerations 269 IANA needs to assign one new TLV type for "LSP State TLV" from the 270 TLV registry of Link_State Attribute. 272 IANA needs to assign one Protocol-ID for 'RSVP-TE' from the BGP-TE/LS 273 registry of Protocol-IDs. 275 4. Security Considerations 277 TBD 279 5. References 281 5.1. Normative References 283 [I-D.ietf-idr-ls-distribution] 284 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 285 Ray, "North-Bound Distribution of Link-State and TE 286 Information using BGP", draft-ietf-idr-ls-distribution-03 287 (work in progress), May 2013. 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 293 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 294 Tunnels", RFC 3209, December 2001. 296 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 297 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 298 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 300 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 301 "Multiprotocol Extensions for BGP-4", RFC 4760, January 302 2007. 304 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 305 (PCE) Communication Protocol (PCEP)", RFC 5440, March 306 2009. 308 5.2. Informative References 310 [I-D.ietf-pce-stateful-pce] 311 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 312 Extensions for Stateful PCE", draft-ietf-pce-stateful- 313 pce-05 (work in progress), July 2013. 315 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 316 Element (PCE)-Based Architecture", RFC 4655, August 2006. 318 Authors' Addresses 320 Jie Dong 321 Huawei Technologies 322 Huawei Building, No. 156 Beiqing Rd. 323 Beijing 100095 324 China 326 Email: jie.dong@huawei.com 327 Mach(Guoyi) Chen 328 Huawei Technologies 329 Huawei Building, No. 156 Beiqing Rd. 330 Beijing 100095 331 China 333 Email: mach.chen@huawei.com 335 Hannes Gredler 336 Juniper Networks, Inc. 337 1194 N. Mathilda Ave. 338 Sunnyvale, CA 94089 339 US 341 Email: hannes@juniper.net