idnits 2.17.1 draft-ietf-idr-te-pm-bgp-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 (January 10, 2014) is 3760 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 304, but no explicit reference was found in the text == Unused Reference: 'ALTO' is defined on line 331, 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 D. Wang 4 Intended status: Standards Track Huawei 5 Expires: July 14, 2014 S. Previdi 6 Cisco 7 H. Gredler 8 Juniper 9 S. Ray 10 Cisco 11 January 10, 2014 13 BGP attribute for North-Bound Distribution of Traffic Engineering (TE) 14 performance Metrics 15 draft-ietf-idr-te-pm-bgp-00 17 Abstract 19 In order to populate network performance information like link 20 latency, latency variation, packet loss and bandwidth into Traffic 21 Engineering Database(TED) and ALTO server, this document describes 22 extensions to BGP protocol, that can be used to distribute network 23 performance information (such as link delay, delay variation, packet 24 loss, residual bandwidth, available bandwidth and utilized bandwidth 25 ). 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 July 14, 2014. 44 Copyright Notice 46 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . 4 63 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. MPLS-TE with H-PCE . . . . . . . . . . . . . . . . . . . . 5 65 3.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 5 66 4. Carrying TE Performance information in BGP . . . . . . . . . . 7 67 5. Attribute TLV Details . . . . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . . 13 74 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 14 75 B.1. draft-ietf-idr-te-pm-bgp-00 . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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 needs for 93 inter-connection between various overlay technologies (e.g. 94 Enterprise BGP/MPLS IP VPNs) in the Wide Area Network (WAN) become 95 important. The Network performance or QoS requirements such as 96 latency, limited bandwidth, packet loss, and jitter, are all critical 97 factors that must be taken into account in the end to end path 98 computation ([I-D.ietf-pce-pcep-service-aware]) and selection which 99 enable establishing segment overlay tunnel between overlay nodes and 100 stitching them together to compute end to end path. 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. These TLVs 211 include a bit called the Anomalous (or "A") bit at the left-most bit 212 after length field of each TLV defined in figure 4 of [[I.D-ietf-idr- 213 ls-distribution]]. The other bits in the first octets after length 214 field of each TLV is reserved for future use. When the A bit is 215 clear (or when the TLV does not include an A bit), the TLV describes 216 steady state link performance. This information could conceivably be 217 used to construct a steady state performance topology for initial 218 tunnel path computation, or to verify alternative failover paths. 220 When network performance downgrades and exceeds configurable maximum 221 thresholds, a TLV with the A bit set is advertised. These TLVs could 222 be used by the receiving BGP peer to determine whether to redirect 223 failing traffic to a backup path, or whether to calculate an entirely 224 new path. If link performance improves later and falls below a 225 configurable value, that TLV can be re- advertised with the Anomalous 226 bit cleared. In this case, a receiving BGP peer can conceivably do 227 whatever re-optimization (or failback) it wishes to do (including 228 nothing). 230 Note that when a TLV does not include the A bit, that TLV cannot be 231 used for failover purposes. The A bit was intentionally omitted from 232 some TLVs to help mitigate oscillations. 234 Consistent with existing ISIS TE specifications [ISIS-TE-METRIC], the 235 bandwidth advertisements, the delay and delay variation 236 advertisements, packet loss defined in this document MUST be encoded 237 in the same unit as one defined in IS-IS Extended IS Reachability 238 sub-TLVs [ISIS-TE-METRIC]. All values (except residual bandwidth) 239 MUST be obtained by a filter that is reasonably representative of an 240 average or calculated as rolling averages where the averaging period 241 MUST be a configurable period of time. The measurement interval, any 242 filter coefficients, and any advertisement intervals MUST be 243 configurable per sub-TLV in the same way as ones defined in section 5 244 of [ISIS-TE-METRIC]. 246 5. Attribute TLV Details 248 Link attribute TLVs defined in section 3.2.2 of [I-D.ietf-idr-ls- 249 distribution]are TLVs that may be encoded in the BGP-LS attribute 250 with a link NLRI. Each 'Link Attribute' is a Type/Length/ Value 251 (TLV) triplet formatted as defined in Section 3.1 of [I-D.ietf-idr- 252 ls-distribution]. The format and semantics of the 'value' fields in 253 'Link Attribute' TLVs correspond to the format and semantics of value 254 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 255 [RFC5305]. Although the encodings for 'Link Attribute' TLVs were 256 originally defined for IS-IS, the TLVs can carry data sourced either 257 by IS-IS or OSPF. 259 The following 'Link Attribute' TLVs are valid in the LINK_STATE 260 attribute: 262 +------------+---------------------+--------------+-----------------+ 263 | TLV Code | Description | IS-IS | Defined in: | 264 | Point | | TLV/Sub-TLV | | 265 +------------+---------------------+--------------+-----------------+ 266 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 267 | | Link Delay | | METRIC]/4.1 | 268 | | | | | 269 | xxxx | Min/Max Unidirection| 22/xx | [ISIS-TE- | 270 | | Link Delay | | METRIC]/4.2 | 271 | | | | | 272 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 273 | | Delay Variation | | METRIC]/4.3 | 274 | | | | | 275 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 276 | | Link Loss | | METRIC]/4.4 | 277 | | | | | 278 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 279 | |Residual Bandwidth | | METRIC]/4.5 | 280 | | | | | 281 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 282 | |Available Bandwidth | | METRIC]/4.6 | 283 | | | | | 284 | xxxx | Unidirectional | 22/xx | [ISIS-TE- | 285 | |Utilized Bandwidth | | METRIC]/4.7 | 286 +------------+---------------------+--------------+-----------------+ 288 Table 1: Link Attribute TLVs 290 6. Security Considerations 292 This document does not introduce security issues beyond those 293 discussed in [I.D-ietf-idr-ls-distribution] and [RFC4271]. 295 7. IANA Considerations 297 IANA maintains the registry for the TLVs. BGP TE Performance TLV 298 will require one new type code per TLV defined in this document. 300 8. References 302 8.1. Normative References 304 [I-D.ietf-idr-ls-distribution] 305 Gredler, H., "North-Bound Distribution of Link-State and 306 TE Information using BGP", 307 ID draft-ietf-idr-ls-distribution-03, May 2013. 309 [I-D.ietf-pce-pcep-service-aware] 310 Dhruv, D., "Extensions to the Path Computation Element 311 Communication Protocol (PCEP) to compute service aware 312 Label Switched Path (LSP)", 313 ID draft-ietf-pce-pcep-service-aware-01, July 2013. 315 [ISIS-TE-METRIC] 316 Giacalone, S., "ISIS Traffic Engineering (TE) Metric 317 Extensions", ID draft-ietf-isis-te-metric-extensions-00, 318 June 2013. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", March 1997. 323 [RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", 324 RFC 4271, January 2006. 326 [RFC5305] Li, T., "IS-IS Extensions for Traffic Engineering", 327 RFC 5305, October 2008. 329 8.2. Informative References 331 [ALTO] Yang, Y., "ALTO Protocol", 332 ID http://tools.ietf.org/html/draft-ietf-alto-protocol-16, 333 May 2013. 335 [I.D-ietf-pce-hierarchy-extensions] 336 Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., 337 and D. King, "Extensions to Path Computation Element 338 Communication Protocol (PCEP) for Hierarchical Path 339 Computation Elements (PCE)", 340 ID draft-ietf-pce-hierarchy-extensions-00, August 2013. 342 [RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based 343 Architecture", RFC 4655, August 2006. 345 Appendix A. Contributor Addresses 347 Jeff Tantsura 348 Ericsson 349 300 Holger Way 350 San Jose, CA 95134 351 US 353 Email: Jeff.Tantsura@ericsson.com 355 Appendix B. Change Log 357 Note to the RFC-Editor: please remove this section prior to 358 publication as an RFC. 360 B.1. draft-ietf-idr-te-pm-bgp-00 362 The following are the major changes compared to previous version 363 draft-wu-idr-te-pm-bgp-03: 365 o Update PCE case in section 3.1. 367 o Add some texts in section 1 and section 4 to clarify from where to 368 distribute pm info and measurement interval and method. 370 Authors' Addresses 372 Qin Wu 373 Huawei 374 101 Software Avenue, Yuhua District 375 Nanjing, Jiangsu 210012 376 China 378 Email: bill.wu@huawei.com 380 Danhua Wang 381 Huawei 382 101 Software Avenue, Yuhua District 383 Nanjing, Jiangsu 210012 384 China 386 Email: wangdanhua@huawei.com 388 Stefano Previdi 389 Cisco Systems, Inc. 390 Via Del Serafico 200 391 Rome 00191 392 Italy 394 Email: sprevidi@cisco.com 396 Hannes Gredler 397 Juniper Networks, Inc. 398 1194 N. Mathilda Ave. 399 Sunnyvale, CA 94089 400 US 402 Email: hannes@juniper.net 404 Saikat Ray 405 Cisco Systems, Inc. 406 170, West Tasman Drive 407 San Jose, CA 95134 408 US 410 Email: sairay@cisco.com