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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/