idnits 2.17.1 draft-ietf-idr-te-pm-bgp-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 : ---------------------------------------------------------------------------- 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 4, 2015) is 3372 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 122, but not defined == Unused Reference: 'I-D.ietf-idr-ls-distribution' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'ALTO' is defined on line 338, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-07 == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-service-aware-06 == Outdated reference: A later version (-11) exists of draft-ietf-isis-te-metric-extensions-04 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: July 8, 2015 Cisco 6 H. Gredler 7 Juniper 8 S. Ray 9 Cisco 10 J. Tantsura 11 Ericsson 12 January 4, 2015 14 BGP attribute for North-Bound Distribution of Traffic Engineering (TE) 15 performance Metrics 16 draft-ietf-idr-te-pm-bgp-02 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 July 8, 2015. 45 Copyright Notice 47 Copyright (c) 2015 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. Manageability Considerations . . . . . . . . . . . . . . . . 7 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 76 A.1. draft-ietf-idr-te-pm-bgp-00 . . . . . . . . . . . . . . . 9 77 A.2. draft-ietf-idr-te-pm-bgp-02 . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 As specified in [RFC4655],a Path Computation Element (PCE) is an 83 entity that is capable of computing a network path or route based on 84 a network graph, and of applying computational constraints during the 85 computation. In order to compute an end to end path, the PCE needs 86 to have a unified view of the overall topology[I-D.ietf-pce-pcep- 87 service-aware]. [I.D-ietf-idr-ls-distribution] describes a mechanism 88 by which links state and traffic engineering information can be 89 collected from networks and shared with external components using the 90 BGP routing protocol. This mechanism can be used by both PCE and 91 ALTO server to gather information about the topologies and 92 capabilities of the network. 94 With the growth of network virtualization technology, the Network 95 performance or QoS requirements such as latency, limited bandwidth, 96 packet loss, and jitter, for real traffic are all critical factors 97 that must be taken into account in the end to end path computation 98 and selection ([I-D.ietf-pce-pcep-service-aware])which enable 99 optimizing resource usage and degrading gracefully during period of 100 heavy load . 102 In order to populate network performance information like link 103 latency, latency variation, packet loss and bandwidth into TED and 104 ALTO server, this document describes extensions to BGP protocol, that 105 can be used to distribute network performance information (such as 106 link delay, delay variation, packet loss, residual bandwidth, 107 available bandwidth, and utilized bandwidth). The network 108 performance information can be distributed in the same way as link 109 state information distribution,i.e., either directly or via a peer 110 BGP speaker (see figure 1 of [I.D-ietf-idr-ls-distribution]). 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC2119 [RFC2119]. 118 3. Use Cases 120 3.1. MPLS-TE with H-PCE 122 For inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805] 123 may be used to compute the optimal sequence of domains. Within the 124 H-PCE architecture, the child PCE communicates domain connectivity 125 information to the parent PCE, and the parent PCE will use this 126 information to compute a multi-domain path based on the optimal TE 127 links between domains [I.D-ietf-pce-hierarchy-extensions] for the 128 end-to-end path. 130 The following figure demonstrates how a parent PCE may obtain TE 131 performance information beyond that contained in the LINK_STATE 132 attributes [I.D-ietf-idr-ls-distribution] using the mechanism 133 described in this document. 135 +----------+ +---------+ 136 | ----- | | BGP | 137 | | TED |<-+-------------------------->| Speaker | 138 | ----- | TED synchronization | | 139 | | | mechanism: +---------+ 140 | | | BGP with TE performance 141 | v | NLRI 142 | ----- | 143 | | PCE | | 144 | ----- | 145 +----------+ 146 ^ 147 | Request/ 148 | Response 149 v 150 Service +----------+ Signaling +----------+ 151 Request | Head-End | Protocol | Adjacent | 152 -------->| Node |<------------>| Node | 153 +----------+ +----------+ 155 Figure 1: External PCE node using a TED synchronization mechanism 157 3.2. ALTO Server Network API 159 The ALTO Server can aggregate information from multiple systems to 160 provide an abstract and unified view that can be more useful to 161 applications. 163 The following figure shows how an ALTO Server can get TE performance 164 information from the underlying network beyond that contained in the 165 LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using the 166 mechanism described in this document. 168 +--------+ 169 | Client |<--+ 170 +--------+ | 171 | ALTO +--------+ BGP with +---------+ 172 +--------+ | Protocol | ALTO | TE Performance | BGP | 173 | Client |<--+------------| Server |<----------------| Speaker | 174 +--------+ | | | NLR | | 175 | +--------+ +---------+ 176 +--------+ | 177 | Client |<--+ 178 +--------+ 179 Figure 2: ALTO Server using network performance information 181 4. Carrying TE Performance information in BGP 183 This document proposes new BGP TE performance TLVs that can be 184 announced as attribute in the BGP-LS attribute (defined in [I.D-ietf- 185 idr-ls-distribution]) to distribute network performance information. 186 The extensions in this document build on the ones provided in BGP-LS 187 [I.D-ietf-idr-ls-distribution] and BGP-4 [RFC4271]. 189 BGP-LS attribute defined in [I.D-ietf-idr-ls-distribution] has nested 190 TLVs which allow the BGP-LS attribute to be readily extended. This 191 document proposes seven additional TLVs as its attributes: 193 Type Value 195 TBD1 Unidirectional Link Delay 197 TBD2 Min/Max Unidirectional Link Delay 199 TBD3 Unidirectional Delay Variation 201 TBD4 Unidirectional Packet Loss 203 TBD5 Unidirectional Residual Bandwidth 205 TBD6 Unidirectional Available Bandwidth 207 TBD7 Unidirectional Utilized Bandwidth 209 As can be seen in the list above, the TLVs described in this document 210 carry different types of network performance information. Some of 211 these TLVs include a bit called the Anomalous (or "A") bit at the 212 left-most bit after length field of each TLV defined in figure 4 of 213 [[I.D-ietf-idr-ls-distribution]]. The other bits in the first octets 214 after length field of each TLV is reserved for future use. When the 215 A bit is clear (or when the TLV does not include an A bit), the TLV 216 describes steady state link performance. This information could 217 conceivably be used to construct a steady state performance topology 218 for initial tunnel path computation, or to verify alternative 219 failover paths. 221 When network performance downgrades and exceeds configurable maximum 222 thresholds, a TLV with the A bit set is advertised. These TLVs could 223 be used by the receiving BGP peer to determine whether to redirect 224 failing traffic to a backup path, or whether to calculate an entirely 225 new path. If link performance improves later and falls below a 226 configurable value, that TLV can be re- advertised with the Anomalous 227 bit cleared. In this case, a receiving BGP peer can conceivably do 228 whatever re-optimization (or failback) it wishes to do (including 229 nothing). 231 Note that when a TLV does not include the A bit, that TLV cannot be 232 used for failover purposes. The A bit was intentionally omitted from 233 some TLVs to help mitigate oscillations. 235 Consistent with existing ISIS TE specifications [ISIS-TE-METRIC], the 236 bandwidth advertisements, the delay and delay variation 237 advertisements, packet loss defined in this document MUST be encoded 238 in the same unit as one defined in IS-IS Extended IS Reachability 239 sub-TLVs [ISIS-TE-METRIC]. All values (except residual bandwidth) 240 MUST be obtained by a filter that is reasonably representative of an 241 average or calculated as rolling averages where the averaging period 242 MUST be a configurable period of time. The measurement interval, any 243 filter coefficients, and any advertisement intervals MUST be 244 configurable per sub-TLV in the same way as ones defined in section 5 245 of [ISIS-TE-METRIC]. 247 5. Attribute TLV Details 249 Link attribute TLVs defined in section 3.2.2 of [I-D.ietf-idr-ls- 250 distribution]are TLVs that may be encoded in the BGP-LS attribute 251 with a link NLRI. Each 'Link Attribute' is a Type/Length/ Value 252 (TLV) triplet formatted as defined in Section 3.1 of [I-D.ietf-idr- 253 ls-distribution]. The format and semantics of the 'value' fields in 254 'Link Attribute' TLVs correspond to the format and semantics of value 255 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 256 [RFC5305]. Although the encodings for 'Link Attribute' TLVs were 257 originally defined for IS-IS, the TLVs can carry data sourced either 258 by IS-IS or OSPF. 260 The following 'Link Attribute' TLVs are valid in the LINK_STATE 261 attribute: 263 +------------+---------------------+--------------+-----------------+ 264 | TLV Code | Description | IS-IS | Defined in: | 265 | Point | | TLV/Sub-TLV | | 266 +------------+---------------------+--------------+-----------------+ 267 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 268 | | Link Delay | | METRIC]/4.1 | 269 | | | | | 270 | xxxx | Min/Max Unidirection| 22/xx | [ISIS-TE- | 271 | | Link Delay | | METRIC]/4.2 | 272 | | | | | 273 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 274 | | Delay Variation | | METRIC]/4.3 | 275 | | | | | 276 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 277 | | Link Loss | | METRIC]/4.4 | 278 | | | | | 279 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 280 | |Residual Bandwidth | | METRIC]/4.5 | 281 | | | | | 282 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 283 | |Available Bandwidth | | METRIC]/4.6 | 284 | | | | | 285 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 286 | |Utilized Bandwidth | | METRIC]/4.7 | 287 +------------+---------------------+--------------+-----------------+ 289 Table 1: Link Attribute TLVs 291 6. Manageability Considerations 293 Manageability Considerations described in section 6.2 of [I-D.ietf- 294 idr-ls-distribution] can be applied to Traffic Engineering (TE) 295 performance Metrics as well. 297 7. Security Considerations 299 This document does not introduce security issues beyond those 300 discussed in [I.D-ietf-idr-ls-distribution] and [RFC4271]. 302 8. IANA Considerations 304 IANA maintains the registry for the TLVs. BGP TE Performance TLV 305 will require one new type code per TLV defined in this document. 307 9. References 309 9.1. Normative References 311 [I-D.ietf-idr-ls-distribution] 312 Gredler, H., "North-Bound Distribution of Link-State and 313 TE Information using BGP", ID draft-ietf-idr-ls- 314 distribution-07, November 2014. 316 [I-D.ietf-pce-pcep-service-aware] 317 Dhruv, D., "Extensions to the Path Computation Element 318 Communication Protocol (PCEP) to compute service aware 319 Label Switched Path (LSP)", ID draft-ietf-pce-pcep- 320 service-aware-06, December 2014. 322 [ISIS-TE-METRIC] 323 Giacalone, S., "ISIS Traffic Engineering (TE) Metric 324 Extensions", ID draft-ietf-isis-te-metric-extensions-04, 325 October 2014. 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", March 1997. 330 [RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", RFC 331 4271, January 2006. 333 [RFC5305] Li, T., "IS-IS Extensions for Traffic Engineering", RFC 334 5305, October 2008. 336 9.2. Informative References 338 [ALTO] Yang, Y., "ALTO Protocol", ID 339 http://tools.ietf.org/html/draft-ietf-alto-protocol-16, 340 May 2013. 342 [I.D-ietf-pce-hierarchy-extensions] 343 Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., 344 and D. King, "Extensions to Path Computation Element 345 Communication Protocol (PCEP) for Hierarchical Path 346 Computation Elements (PCE)", ID draft-ietf-pce-hierarchy- 347 extensions-01, February 2014. 349 [RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based 350 Architecture", RFC 4655, August 2006. 352 Appendix A. Change Log 354 Note to the RFC-Editor: please remove this section prior to 355 publication as an RFC. 357 A.1. draft-ietf-idr-te-pm-bgp-00 359 The following are the major changes compared to previous version 360 draft-wu-idr-te-pm-bgp-03: 362 o Update PCE case in section 3.1. 364 o Add some texts in section 1 and section 4 to clarify from where to 365 distribute pm info and measurement interval and method. 367 A.2. draft-ietf-idr-te-pm-bgp-02 369 The following are the major changes compared to previous version 370 draft-wu-idr-te-pm-bgp-03: 372 o Some Editorial changes. 374 Authors' Addresses 376 Qin Wu 377 Huawei 378 101 Software Avenue, Yuhua District 379 Nanjing, Jiangsu 210012 380 China 382 Email: bill.wu@huawei.com 384 Stefano Previdi 385 Cisco Systems, Inc. 386 Via Del Serafico 200 387 Rome 00191 388 Italy 390 Email: sprevidi@cisco.com 391 Hannes Gredler 392 Juniper Networks, Inc. 393 1194 N. Mathilda Ave. 394 Sunnyvale, CA 94089 395 US 397 Email: hannes@juniper.net 399 Saikat Ray 400 Cisco Systems, Inc. 401 170, West Tasman Drive 402 San Jose, CA 95134 403 US 405 Email: sairay@cisco.com 407 Jeff Tantsura 408 Ericsson 409 300 Holger Way 410 San Jose, CA 95134 411 US 413 Email: jeff.tantsura@ericsson.com