--- 1/draft-ietf-idr-te-pm-bgp-00.txt 2014-07-04 02:14:31.199453747 -0700 +++ 2/draft-ietf-idr-te-pm-bgp-01.txt 2014-07-04 02:14:31.223454338 -0700 @@ -1,110 +1,108 @@ IDR Working Group Q. Wu -Internet-Draft D. Wang -Intended status: Standards Track Huawei -Expires: July 14, 2014 S. Previdi - Cisco +Internet-Draft Huawei +Intended status: Standards Track S. Previdi +Expires: January 5, 2015 Cisco H. Gredler Juniper S. Ray Cisco - January 10, 2014 + J. Tantsura + Ericsson + July 4, 2014 BGP attribute for North-Bound Distribution of Traffic Engineering (TE) performance Metrics - draft-ietf-idr-te-pm-bgp-00 + draft-ietf-idr-te-pm-bgp-01 Abstract In order to populate network performance information like link latency, latency variation, packet loss and bandwidth into Traffic Engineering Database(TED) and ALTO server, this document describes extensions to BGP protocol, that can be used to distribute network performance information (such as link delay, delay variation, packet loss, residual bandwidth, available bandwidth and utilized bandwidth ). -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 14, 2014. + This Internet-Draft will expire on January 5, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Conventions used in this document . . . . . . . . . . . . . . 4 - 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. MPLS-TE with H-PCE . . . . . . . . . . . . . . . . . . . . 5 - 3.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 5 - 4. Carrying TE Performance information in BGP . . . . . . . . . . 7 - 5. Attribute TLV Details . . . . . . . . . . . . . . . . . . . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 - Appendix A. Contributor Addresses . . . . . . . . . . . . . . . . 13 - Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 14 - B.1. draft-ietf-idr-te-pm-bgp-00 . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions used in this document . . . . . . . . . . . . . . 3 + 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. MPLS-TE with H-PCE . . . . . . . . . . . . . . . . . . . 3 + 3.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 4 + 4. Carrying TE Performance information in BGP . . . . . . . . . 5 + 5. Attribute TLV Details . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 + 8.2. Informative References . . . . . . . . . . . . . . . . . 8 + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 + A.1. draft-ietf-idr-te-pm-bgp-00 . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction As specified in [RFC4655],a Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and of applying computational constraints during the computation. In order to compute an end to end path, the PCE needs to have a unified view of the overall topology[I-D.ietf-pce-pcep- service-aware]. [I.D-ietf-idr-ls-distribution] describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This mechanism can be used by both PCE and ALTO server to gather information about the topologies and capabilities of the network. - With the growth of network virtualization technology, the needs for - inter-connection between various overlay technologies (e.g. - Enterprise BGP/MPLS IP VPNs) in the Wide Area Network (WAN) become - important. The Network performance or QoS requirements such as - latency, limited bandwidth, packet loss, and jitter, are all critical - factors that must be taken into account in the end to end path - computation ([I-D.ietf-pce-pcep-service-aware]) and selection which - enable establishing segment overlay tunnel between overlay nodes and - stitching them together to compute end to end path. + With the growth of network virtualization technology, the Network + performance or QoS requirements such as latency, limited bandwidth, + packet loss, and jitter, for real traffic are all critical factors + that must be taken into account in the end to end path computation + and selection ([I-D.ietf-pce-pcep-service-aware])which enable + optimizing resource usage and degrading gracefully during period of + heavy load . In order to populate network performance information like link latency, latency variation, packet loss and bandwidth into TED and ALTO server, this document describes extensions to BGP protocol, that can be used to distribute network performance information (such as link delay, delay variation, packet loss, residual bandwidth, available bandwidth, and utilized bandwidth). The network performance information can be distributed in the same way as link state information distribution,i.e., either directly or via a peer BGP speaker (see figure 1 of [I.D-ietf-idr-ls-distribution]). @@ -200,29 +198,30 @@ TBD4 Unidirectional Packet Loss TBD5 Unidirectional Residual Bandwidth TBD6 Unidirectional Available Bandwidth TBD7 Unidirectional Utilized Bandwidth As can be seen in the list above, the TLVs described in this document - carry different types of network performance information. These TLVs - include a bit called the Anomalous (or "A") bit at the left-most bit - after length field of each TLV defined in figure 4 of [[I.D-ietf-idr- - ls-distribution]]. The other bits in the first octets after length - field of each TLV is reserved for future use. When the A bit is - clear (or when the TLV does not include an A bit), the TLV describes - steady state link performance. This information could conceivably be - used to construct a steady state performance topology for initial - tunnel path computation, or to verify alternative failover paths. + carry different types of network performance information. Some of + these TLVs include a bit called the Anomalous (or "A") bit at the + left-most bit after length field of each TLV defined in figure 4 of + [[I.D-ietf-idr-ls-distribution]]. The other bits in the first octets + after length field of each TLV is reserved for future use. When the + A bit is clear (or when the TLV does not include an A bit), the TLV + describes steady state link performance. This information could + conceivably be used to construct a steady state performance topology + for initial tunnel path computation, or to verify alternative + failover paths. When network performance downgrades and exceeds configurable maximum thresholds, a TLV with the A bit set is advertised. These TLVs could be used by the receiving BGP peer to determine whether to redirect failing traffic to a backup path, or whether to calculate an entirely new path. If link performance improves later and falls below a configurable value, that TLV can be re- advertised with the Anomalous bit cleared. In this case, a receiving BGP peer can conceivably do whatever re-optimization (or failback) it wishes to do (including nothing). @@ -296,102 +295,84 @@ IANA maintains the registry for the TLVs. BGP TE Performance TLV will require one new type code per TLV defined in this document. 8. References 8.1. Normative References [I-D.ietf-idr-ls-distribution] Gredler, H., "North-Bound Distribution of Link-State and - TE Information using BGP", - ID draft-ietf-idr-ls-distribution-03, May 2013. + TE Information using BGP", ID draft-ietf-idr-ls- + distribution-03, May 2013. [I-D.ietf-pce-pcep-service-aware] Dhruv, D., "Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware - Label Switched Path (LSP)", - ID draft-ietf-pce-pcep-service-aware-01, July 2013. + Label Switched Path (LSP)", ID draft-ietf-pce-pcep- + service-aware-01, July 2013. [ISIS-TE-METRIC] Giacalone, S., "ISIS Traffic Engineering (TE) Metric Extensions", ID draft-ietf-isis-te-metric-extensions-00, June 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. - [RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", - RFC 4271, January 2006. + [RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", RFC + 4271, January 2006. - [RFC5305] Li, T., "IS-IS Extensions for Traffic Engineering", - RFC 5305, October 2008. + [RFC5305] Li, T., "IS-IS Extensions for Traffic Engineering", RFC + 5305, October 2008. 8.2. Informative References - [ALTO] Yang, Y., "ALTO Protocol", - ID http://tools.ietf.org/html/draft-ietf-alto-protocol-16, + [ALTO] Yang, Y., "ALTO Protocol", ID + http://tools.ietf.org/html/draft-ietf-alto-protocol-16, May 2013. [I.D-ietf-pce-hierarchy-extensions] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., and D. King, "Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path - Computation Elements (PCE)", - ID draft-ietf-pce-hierarchy-extensions-00, August 2013. + Computation Elements (PCE)", ID draft-ietf-pce-hierarchy- + extensions-00, August 2013. [RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. -Appendix A. Contributor Addresses - - Jeff Tantsura - Ericsson - 300 Holger Way - San Jose, CA 95134 - US - - Email: Jeff.Tantsura@ericsson.com - -Appendix B. Change Log +Appendix A. Change Log Note to the RFC-Editor: please remove this section prior to publication as an RFC. -B.1. draft-ietf-idr-te-pm-bgp-00 +A.1. draft-ietf-idr-te-pm-bgp-00 The following are the major changes compared to previous version draft-wu-idr-te-pm-bgp-03: o Update PCE case in section 3.1. o Add some texts in section 1 and section 4 to clarify from where to distribute pm info and measurement interval and method. Authors' Addresses Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com - Danhua Wang - Huawei - 101 Software Avenue, Yuhua District - Nanjing, Jiangsu 210012 - China - - Email: wangdanhua@huawei.com - Stefano Previdi Cisco Systems, Inc. Via Del Serafico 200 Rome 00191 Italy Email: sprevidi@cisco.com Hannes Gredler Juniper Networks, Inc. @@ -401,10 +382,18 @@ Email: hannes@juniper.net Saikat Ray Cisco Systems, Inc. 170, West Tasman Drive San Jose, CA 95134 US Email: sairay@cisco.com + + Jeff Tantsura + Ericsson + 300 Holger Way + San Jose, CA 95134 + US + + Email: jeff.tantsura@ericsson.com