idnits 2.17.1 draft-ietf-idr-te-pm-bgp-01.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 (July 4, 2014) is 3577 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) == Missing Reference: 'RFC6805' is mentioned on line 120, but not defined == Unused Reference: 'I-D.ietf-idr-ls-distribution' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'ALTO' is defined on line 330, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-03 == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-service-aware-01 == Outdated reference: A later version (-11) exists of draft-ietf-isis-te-metric-extensions-00 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Standards Track S. Previdi 5 Expires: January 5, 2015 Cisco 6 H. Gredler 7 Juniper 8 S. Ray 9 Cisco 10 J. Tantsura 11 Ericsson 12 July 4, 2014 14 BGP attribute for North-Bound Distribution of Traffic Engineering (TE) 15 performance Metrics 16 draft-ietf-idr-te-pm-bgp-01 18 Abstract 20 In order to populate network performance information like link 21 latency, latency variation, packet loss and bandwidth into Traffic 22 Engineering Database(TED) and ALTO server, this document describes 23 extensions to BGP protocol, that can be used to distribute network 24 performance information (such as link delay, delay variation, packet 25 loss, residual bandwidth, available bandwidth and utilized bandwidth 26 ). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 5, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. MPLS-TE with H-PCE . . . . . . . . . . . . . . . . . . . 3 66 3.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 4 67 4. Carrying TE Performance information in BGP . . . . . . . . . 5 68 5. Attribute TLV Details . . . . . . . . . . . . . . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 75 A.1. draft-ietf-idr-te-pm-bgp-00 . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 As specified in [RFC4655],a Path Computation Element (PCE) is an 81 entity that is capable of computing a network path or route based on 82 a network graph, and of applying computational constraints during the 83 computation. In order to compute an end to end path, the PCE needs 84 to have a unified view of the overall topology[I-D.ietf-pce-pcep- 85 service-aware]. [I.D-ietf-idr-ls-distribution] describes a mechanism 86 by which links state and traffic engineering information can be 87 collected from networks and shared with external components using the 88 BGP routing protocol. This mechanism can be used by both PCE and 89 ALTO server to gather information about the topologies and 90 capabilities of the network. 92 With the growth of network virtualization technology, the Network 93 performance or QoS requirements such as latency, limited bandwidth, 94 packet loss, and jitter, for real traffic are all critical factors 95 that must be taken into account in the end to end path computation 96 and selection ([I-D.ietf-pce-pcep-service-aware])which enable 97 optimizing resource usage and degrading gracefully during period of 98 heavy load . 100 In order to populate network performance information like link 101 latency, latency variation, packet loss and bandwidth into TED and 102 ALTO server, this document describes extensions to BGP protocol, that 103 can be used to distribute network performance information (such as 104 link delay, delay variation, packet loss, residual bandwidth, 105 available bandwidth, and utilized bandwidth). The network 106 performance information can be distributed in the same way as link 107 state information distribution,i.e., either directly or via a peer 108 BGP speaker (see figure 1 of [I.D-ietf-idr-ls-distribution]). 110 2. Conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC2119 [RFC2119]. 116 3. Use Cases 118 3.1. MPLS-TE with H-PCE 120 For inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805] 121 may be used to compute the optimal sequence of domains. Within the 122 H-PCE architecture, the child PCE communicates domain connectivity 123 information to the parent PCE, and the parent PCE will use this 124 information to compute a multi-domain path based on the optimal TE 125 links between domains [I.D-ietf-pce-hierarchy-extensions] for the 126 end-to-end path. 128 The following figure demonstrates how a parent PCE may obtain TE 129 performance information beyond that contained in the LINK_STATE 130 attributes [I.D-ietf-idr-ls-distribution] using the mechanism 131 described in this document. 133 +----------+ +---------+ 134 | ----- | | BGP | 135 | | TED |<-+-------------------------->| Speaker | 136 | ----- | TED synchronization | | 137 | | | mechanism: +---------+ 138 | | | BGP with TE performance 139 | v | NLRI 140 | ----- | 141 | | PCE | | 142 | ----- | 143 +----------+ 144 ^ 145 | Request/ 146 | Response 147 v 148 Service +----------+ Signaling +----------+ 149 Request | Head-End | Protocol | Adjacent | 150 -------->| Node |<------------>| Node | 151 +----------+ +----------+ 153 Figure 1: External PCE node using a TED synchronization mechanism 155 3.2. ALTO Server Network API 157 The ALTO Server can aggregate information from multiple systems to 158 provide an abstract and unified view that can be more useful to 159 applications. 161 The following figure shows how an ALTO Server can get TE performance 162 information from the underlying network beyond that contained in the 163 LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using the 164 mechanism described in this document. 166 +--------+ 167 | Client |<--+ 168 +--------+ | 169 | ALTO +--------+ BGP with +---------+ 170 +--------+ | Protocol | ALTO | TE Performance | BGP | 171 | Client |<--+------------| Server |<----------------| Speaker | 172 +--------+ | | | NLR | | 173 | +--------+ +---------+ 174 +--------+ | 175 | Client |<--+ 176 +--------+ 177 Figure 2: ALTO Server using network performance information 179 4. Carrying TE Performance information in BGP 181 This document proposes new BGP TE performance TLVs that can be 182 announced as attribute in the BGP-LS attribute (defined in [I.D-ietf- 183 idr-ls-distribution]) to distribute network performance information. 184 The extensions in this document build on the ones provided in BGP-LS 185 [I.D-ietf-idr-ls-distribution] and BGP-4 [RFC4271]. 187 BGP-LS attribute defined in [I.D-ietf-idr-ls-distribution] has nested 188 TLVs which allow the BGP-LS attribute to be readily extended. This 189 document proposes seven additional TLVs as its attributes: 191 Type Value 193 TBD1 Unidirectional Link Delay 195 TBD2 Min/Max Unidirectional Link Delay 197 TBD3 Unidirectional Delay Variation 199 TBD4 Unidirectional Packet Loss 201 TBD5 Unidirectional Residual Bandwidth 203 TBD6 Unidirectional Available Bandwidth 205 TBD7 Unidirectional Utilized Bandwidth 207 As can be seen in the list above, the TLVs described in this document 208 carry different types of network performance information. Some of 209 these TLVs include a bit called the Anomalous (or "A") bit at the 210 left-most bit after length field of each TLV defined in figure 4 of 211 [[I.D-ietf-idr-ls-distribution]]. The other bits in the first octets 212 after length field of each TLV is reserved for future use. When the 213 A bit is clear (or when the TLV does not include an A bit), the TLV 214 describes steady state link performance. This information could 215 conceivably be used to construct a steady state performance topology 216 for initial tunnel path computation, or to verify alternative 217 failover paths. 219 When network performance downgrades and exceeds configurable maximum 220 thresholds, a TLV with the A bit set is advertised. These TLVs could 221 be used by the receiving BGP peer to determine whether to redirect 222 failing traffic to a backup path, or whether to calculate an entirely 223 new path. If link performance improves later and falls below a 224 configurable value, that TLV can be re- advertised with the Anomalous 225 bit cleared. In this case, a receiving BGP peer can conceivably do 226 whatever re-optimization (or failback) it wishes to do (including 227 nothing). 229 Note that when a TLV does not include the A bit, that TLV cannot be 230 used for failover purposes. The A bit was intentionally omitted from 231 some TLVs to help mitigate oscillations. 233 Consistent with existing ISIS TE specifications [ISIS-TE-METRIC], the 234 bandwidth advertisements, the delay and delay variation 235 advertisements, packet loss defined in this document MUST be encoded 236 in the same unit as one defined in IS-IS Extended IS Reachability 237 sub-TLVs [ISIS-TE-METRIC]. All values (except residual bandwidth) 238 MUST be obtained by a filter that is reasonably representative of an 239 average or calculated as rolling averages where the averaging period 240 MUST be a configurable period of time. The measurement interval, any 241 filter coefficients, and any advertisement intervals MUST be 242 configurable per sub-TLV in the same way as ones defined in section 5 243 of [ISIS-TE-METRIC]. 245 5. Attribute TLV Details 247 Link attribute TLVs defined in section 3.2.2 of [I-D.ietf-idr-ls- 248 distribution]are TLVs that may be encoded in the BGP-LS attribute 249 with a link NLRI. Each 'Link Attribute' is a Type/Length/ Value 250 (TLV) triplet formatted as defined in Section 3.1 of [I-D.ietf-idr- 251 ls-distribution]. The format and semantics of the 'value' fields in 252 'Link Attribute' TLVs correspond to the format and semantics of value 253 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 254 [RFC5305]. Although the encodings for 'Link Attribute' TLVs were 255 originally defined for IS-IS, the TLVs can carry data sourced either 256 by IS-IS or OSPF. 258 The following 'Link Attribute' TLVs are valid in the LINK_STATE 259 attribute: 261 +------------+---------------------+--------------+-----------------+ 262 | TLV Code | Description | IS-IS | Defined in: | 263 | Point | | TLV/Sub-TLV | | 264 +------------+---------------------+--------------+-----------------+ 265 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 266 | | Link Delay | | METRIC]/4.1 | 267 | | | | | 268 | xxxx | Min/Max Unidirection| 22/xx | [ISIS-TE- | 269 | | Link Delay | | METRIC]/4.2 | 270 | | | | | 271 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 272 | | Delay Variation | | METRIC]/4.3 | 273 | | | | | 274 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 275 | | Link Loss | | METRIC]/4.4 | 276 | | | | | 277 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 278 | |Residual Bandwidth | | METRIC]/4.5 | 279 | | | | | 280 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 281 | |Available Bandwidth | | METRIC]/4.6 | 282 | | | | | 283 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 284 | |Utilized Bandwidth | | METRIC]/4.7 | 285 +------------+---------------------+--------------+-----------------+ 287 Table 1: Link Attribute TLVs 289 6. Security Considerations 291 This document does not introduce security issues beyond those 292 discussed in [I.D-ietf-idr-ls-distribution] and [RFC4271]. 294 7. IANA Considerations 296 IANA maintains the registry for the TLVs. BGP TE Performance TLV 297 will require one new type code per TLV defined in this document. 299 8. References 301 8.1. Normative References 303 [I-D.ietf-idr-ls-distribution] 304 Gredler, H., "North-Bound Distribution of Link-State and 305 TE Information using BGP", ID draft-ietf-idr-ls- 306 distribution-03, May 2013. 308 [I-D.ietf-pce-pcep-service-aware] 309 Dhruv, D., "Extensions to the Path Computation Element 310 Communication Protocol (PCEP) to compute service aware 311 Label Switched Path (LSP)", ID draft-ietf-pce-pcep- 312 service-aware-01, July 2013. 314 [ISIS-TE-METRIC] 315 Giacalone, S., "ISIS Traffic Engineering (TE) Metric 316 Extensions", ID draft-ietf-isis-te-metric-extensions-00, 317 June 2013. 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", March 1997. 322 [RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", RFC 323 4271, January 2006. 325 [RFC5305] Li, T., "IS-IS Extensions for Traffic Engineering", RFC 326 5305, October 2008. 328 8.2. Informative References 330 [ALTO] Yang, Y., "ALTO Protocol", ID 331 http://tools.ietf.org/html/draft-ietf-alto-protocol-16, 332 May 2013. 334 [I.D-ietf-pce-hierarchy-extensions] 335 Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., 336 and D. King, "Extensions to Path Computation Element 337 Communication Protocol (PCEP) for Hierarchical Path 338 Computation Elements (PCE)", ID draft-ietf-pce-hierarchy- 339 extensions-00, August 2013. 341 [RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based 342 Architecture", RFC 4655, August 2006. 344 Appendix A. Change Log 346 Note to the RFC-Editor: please remove this section prior to 347 publication as an RFC. 349 A.1. draft-ietf-idr-te-pm-bgp-00 351 The following are the major changes compared to previous version 352 draft-wu-idr-te-pm-bgp-03: 354 o Update PCE case in section 3.1. 356 o Add some texts in section 1 and section 4 to clarify from where to 357 distribute pm info and measurement interval and method. 359 Authors' Addresses 361 Qin Wu 362 Huawei 363 101 Software Avenue, Yuhua District 364 Nanjing, Jiangsu 210012 365 China 367 Email: bill.wu@huawei.com 369 Stefano Previdi 370 Cisco Systems, Inc. 371 Via Del Serafico 200 372 Rome 00191 373 Italy 375 Email: sprevidi@cisco.com 377 Hannes Gredler 378 Juniper Networks, Inc. 379 1194 N. Mathilda Ave. 380 Sunnyvale, CA 94089 381 US 383 Email: hannes@juniper.net 385 Saikat Ray 386 Cisco Systems, Inc. 387 170, West Tasman Drive 388 San Jose, CA 95134 389 US 391 Email: sairay@cisco.com 393 Jeff Tantsura 394 Ericsson 395 300 Holger Way 396 San Jose, CA 95134 397 US 399 Email: jeff.tantsura@ericsson.com