draft-ietf-idr-performance-routing-00.txt   draft-ietf-idr-performance-routing-01.txt 
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track M. Boucadair Intended status: Standards Track M. Boucadair
Expires: July 11, 2015 C. Jacquenet Expires: August 30, 2015 C. Jacquenet
France Telecom France Telecom
N. So N. So
Vinci Systems Vinci Systems
Y. Shen Y. Shen
Juniper Juniper
U. Chunduri U. Chunduri
Ericsson Ericsson
H. Ni H. Ni
Huawei Huawei
Y. Fan Y. Fan
China Telecom China Telecom
January 7, 2015 L. Contreras
Telefonica I+D
February 26, 2015
Performance-based BGP Routing Mechanism Performance-based BGP Routing Mechanism
draft-ietf-idr-performance-routing-00 draft-ietf-idr-performance-routing-01
Abstract Abstract
The current BGP specification doesn't use network performance metrics The current BGP specification doesn't use network performance metrics
(e.g., network latency) in the route selection decision process. (e.g., network latency) in the route selection decision process.
This document describes a performance-based BGP routing mechanism in This document describes a performance-based BGP routing mechanism in
which network latency metric is taken as one of the route selection which network latency metric is taken as one of the route selection
criteria. This routing mechanism is useful for those server criteria. This routing mechanism is useful for those server
providers with global reach to deliver low-latency network providers with global reach to deliver low-latency network
connectivity services to their customers. connectivity services to their customers.
skipping to change at page 1, line 47 skipping to change at page 2, line 4
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 August 30, 2015.
This Internet-Draft will expire on July 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 29 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Performance Route Advertisement . . . . . . . . . . . . . . . 4 3. Performance Route Advertisement . . . . . . . . . . . . . . . 4
4. Capability Advertisement . . . . . . . . . . . . . . . . . . 5 4. Capability Advertisement . . . . . . . . . . . . . . . . . . 5
5. Performance Route Selection . . . . . . . . . . . . . . . . . 5 5. Performance Route Selection . . . . . . . . . . . . . . . . . 5
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Network latency is widely recognized as one of major obstacles in Network latency is widely recognized as one of major obstacles in
migrating business applications to the cloud since cloud-based migrating business applications to the cloud since cloud-based
applications usually have very clearly defined and stringent network applications usually have very clearly defined and stringent network
latency requirements. Service providers with global reach aim at latency requirements. Service providers with global reach aim at
delivering low-latency network connectivity services to their cloud delivering low-latency network connectivity services to their cloud
service customers as a competitive advantage. Sometimes, the network service customers as a competitive advantage. Sometimes, the network
connectivity may travel across more than one Autonomous System (AS) connectivity may travel across more than one Autonomous System (AS)
skipping to change at page 4, line 47 skipping to change at page 4, line 47
maximum value of 0xFFFFFFFF, the value field SHOULD be set to maximum value of 0xFFFFFFFF, the value field SHOULD be set to
0xFFFFFFFF. Note that the NETWORK_LATENCY TLV MUST NOT co-exisit 0xFFFFFFFF. Note that the NETWORK_LATENCY TLV MUST NOT co-exisit
with the AIGP TLV within the same AIGP attribute. with the AIGP TLV within the same AIGP attribute.
A BGP speaker SHOULD be configurable to enable or disable the A BGP speaker SHOULD be configurable to enable or disable the
origination of performance routes. If enabled, a local latency value origination of performance routes. If enabled, a local latency value
for a given to-be-originated performance route MUST be configured to for a given to-be-originated performance route MUST be configured to
the BGP speaker so that it can be filled to the NETWORK_LATENCY TLV the BGP speaker so that it can be filled to the NETWORK_LATENCY TLV
of that performance route. of that performance route.
A BGP speaker that is enabled to process NETWORK_LATENCY, but it was
not provisioned with the local latency value SHOULD remove the
NETWORK_LATENCY attribute when it advertises the corresponding route
downstream.
When distributing a performance route learnt from a BGP peer, if this When distributing a performance route learnt from a BGP peer, if this
BGP speaker has set itself as the NEXT_HOP of such route, the value BGP speaker has set itself as the NEXT_HOP of such route, the value
of the NETWORK_LATENCY TLV SHOULD be increased by adding the network of the NETWORK_LATENCY TLV SHOULD be increased by adding the network
latency from itself to the previous NEXT_HOP of such route. latency from itself to the previous NEXT_HOP of such route.
Otherwise, the NETWORK_LATENCY TLV of such route MUST NOT be Otherwise, the NETWORK_LATENCY TLV of such route MUST NOT be
modified. modified.
As for how to obtain the network latency to a given BGP NEXT_HOP is As for how to obtain the network latency to a given BGP NEXT_HOP is
outside the scope of this document. However, note that the path outside the scope of this document. However, note that the path
latency to the NEXT HOP SHOULD approximately represent the network latency to the NEXT HOP SHOULD approximately represent the network
latency of the exact forwarding path towards the NEXT_HOP. For latency of the exact forwarding path towards the NEXT_HOP. For
example, if a BGP speaker uses a Traffic Engineering (TE) Label example, if a BGP speaker uses a Traffic Engineering (TE) Label
Switching Path (LSP) from itself to the NEXT_HOP, rather than the Switching Path (LSP) from itself to the NEXT_HOP, rather than the
shortest path calculated by Interior Gateway Protocol (IGP), the shortest path calculated by Interior Gateway Protocol (IGP), the
skipping to change at page 5, line 46 skipping to change at page 5, line 50
BGP speaker that advertises the Performance Routing Capability to a BGP speaker that advertises the Performance Routing Capability to a
peer using BGP Capabilities advertisement [RFC5492] does not have to peer using BGP Capabilities advertisement [RFC5492] does not have to
advertise the BGP Labeled Route Capability to that peer. advertise the BGP Labeled Route Capability to that peer.
5. Performance Route Selection 5. Performance Route Selection
Performance route selection only requires the following modification Performance route selection only requires the following modification
to the tie-breaking procedures of the BGP route selection decision to the tie-breaking procedures of the BGP route selection decision
(phase 2) described in [RFC4271]: network latency metric comparison (phase 2) described in [RFC4271]: network latency metric comparison
SHOULD be executed just ahead of the AS-Path Length comparison step. SHOULD be executed just ahead of the AS-Path Length comparison step.
Prior to executing the network latency metric comparison, the value Prior to executing the network latency metric comparison, the value
of the NETWORK_LATENCY TLV SHOULD be increased by adding the network of the NETWORK_LATENCY TLV SHOULD be increased by adding the network
latency from the BGP speaker to the NEXT_HOP of that route. In the latency from the BGP speaker to the NEXT_HOP of that route.
case where a router reflector is deployed without next-hop-self
enabled when reflecting received routes from one IBGP peer to other
IBGP peer, it is RECOMMENDED to enable such route reflector to
reflect all received performance routes by using some mechanisms such
as [I-D.ietf-idr-add-paths], rather than reflecting only the
performance route which is the best from its own perspective.
Otherwise, it may result in a non-optimal choice by its clients and/
or its IBGP peers.
The Loc-RIB of performance routing paradigm is independent from that The Loc-RIB of the performance routing paradigm is independent from
of vanilla routing paradigm. Accordingly, the routing table of that of the vanilla routing paradigm. Accordingly, the routing table
performance routing paradigm is independent from that of the vanilla of the performance routing paradigm is independent from that of the
routing paradigm. Whether performance routing paradigm or vanilla vanilla routing paradigm. Whether the performance routing paradigm
routing paradigm would be used for a given packet is a local policy or the vanilla routing paradigm would be applied to a given packet is
issue which is outside the scope of this document. a local policy issue which is outside the scope of this document.
6. Deployment Considerations 6. Deployment Considerations
It is strongly RECOMMENDED to deploy this performance-based BGP This section is not normative.
routing mechanism across multiple ASes which belong to a single
administrative domain. Within each AS, it is RECOMMENDED to deliver Enabling the performance-based BGP routing at large (i.e., among
a packet from a BGP speaker to the BGP NEXT_HOP via tunnels, domains that do not belong to the same administrative entity) may be
typically TE LSP tunnels. Furthermore, if a TE LSP is used between conditioned by other administrative settlement considerations that
iBGP peers, it is RECOMMENDED to use the latency metric carried in are out of scope of this document. Nevertheless, this document does
Unidirectional Link Delay Sub-TLV not require nor exclude activating the proposed route selection
scheme between domains that are managed by distinct administrative
entities.
The main deployment case targeted by this specification is where
involved domains are managed by the same administrative entity.
Concretely, this performance-based BGP routing mechanism can
advantageously be enabled in a multi-domain environment, where all
the involved domains are operated by the same administrative entity
so that the processing of the low latency routes can be consistent
throughout the domains. Besides security considerations that may
arise (and which are further discussed in Section 9), there is indeed
a need to consistently enforce a low-latency-based BGP routing policy
within a set of domains that belong to the same administrative
entity. This is motivated by the processing of traffic which is of
very different nature and which may have different QoS requirements.
Moreover, the combined use of BGP-inferred low latency information
with traffic engineering tools that would lead to the computation and
the establishment of traffic-engineered LSP paths between "low
latency"-enabled BGP peers based upon the manipulation of the
Unidirectional Link delay sub-TLV
[I-D.ietf-isis-te-metric-extensions] [I-D.ietf-isis-te-metric-extensions]
[I-D.ietf-ospf-te-metric-extensions] if possible, rather than the TE [I-D.ietf-ospf-te-metric-extensions] would contribute to guarantee
metric [RFC3630][RFC5305] to calculate the cumulative link latency the overall consistency of the low latency information within each
associated with the TE LSP and use that cumulative link latency to domain.
approximately represent the network latency. Thus, there is no need
for frequent measurement of network latency between IBGP peers.
7. Acknowledgements In network environments where router reflectors are deployed but
next-hop-self is disabled on them, route reflectors usually reflect
those received routes which are optimal (i.e., lowest latency) from
their perspectives but may not be optimal from the receivers'
perspectives. Some existing solutions as described in
[I-D.ietf-idr-add-paths], [I-D.ietf-idr-bgp-optimal-route-reflection]
and [RFC6774] can be used to address this issue.
Thanks to Joel Halpern, Alvaro Retana, Jim Uttaro, Robert Raszuk, From a network provider perspective, the ability to manipulate low
Eric Rosen, Qing Zeng, Jie Dong, Mach Chen, Saikat Ray, Wes George, latency routes may lead to different, presumably service-specific
Jeff Haas, John Scudder, Stephane Litkowski and Sriganesh Kini for designs. In particular, there is a need to assess the impact of
their valuable comments on the initial idea of this document. using such capability on the overall performance of the BGP peers
Special thanks should be given to Jim Uttaro and Eric Rosen for their from a route computation and selection procedure as a function of the
proposal of using a new TLV of the AIGP attribute to convey the tie-breaking operation. A typical use case would consist in
network latency metric. selecting low latency routes for traffic that for example pertains to
the VoIP, or whose nature demands the selection of the lowest latency
route in the Adj-RIB-Out database of the corresponding BGP peers.
Typically, live broadcasting services or some e-health services could
certainly take advantage of such capability. It is out of scope of
this document to exhaustively elaborate on such service-specific
designs that are obviously deployment-specific.
8. IANA Considerations 7. IANA Considerations
A new BGP Capability Code for the Performance Routing Capability, a A new BGP Capability Code for the Performance Routing Capability, a
new SAFI specific for performance routing and a new type code for new SAFI specific for performance routing and a new type code for
NETWORK_LATENCY TLV of the AIGP attribute are required to be NETWORK_LATENCY TLV of the AIGP attribute are required to be
allocated by IANA. allocated by IANA.
9. Security Considerations 8. Security Considerations
In addition to the considerations discussed in [RFC4271], the In addition to the considerations discussed in [RFC4271], the
following items should be considered as well: following items should be considered as well:
a. Tweaking the value of the NETWORK_LATENCY by an illegitimate a. Tweaking the value of the NETWORK_LATENCY by an illegitimate
party may influence the route selection results. Therefore, the party may influence the route selection results. Therefore, the
Performance Routing Capability negotiation between BGP peers Performance Routing Capability negotiation between BGP peers
which belong to different administration domains MUST be disabled which belong to different administration domains MUST be disabled
by default. Furthermore, a BGP speaker MUST discard all by default. Furthermore, a BGP speaker MUST discard all
performance routes received from the BGP peer for which the performance routes received from the BGP peer for which the
Performance Routing Capability negotiation has been disabled. Performance Routing Capability negotiation has been disabled.
b. Frequent updates of the NETWORK_LATENCY TLV may have a severe b. Frequent updates of the NETWORK_LATENCY TLV may have a severe
impact on the stability of the routing system. Such practice impact on the stability of the routing system. Such practice
SHOULD be avoided by setting a reasonable threshold for network SHOULD be avoided by setting a reasonable threshold for network
latency fluctuation. latency fluctuation.
9. Acknowledgements
Thanks to Joel Halpern, Alvaro Retana, Jim Uttaro, Robert Raszuk,
Eric Rosen, Bruno Decraene, Qing Zeng, Jie Dong, Mach Chen, Saikat
Ray, Wes George, Jeff Haas, John Scudder, Stephane Litkowski and
Sriganesh Kini for their valuable comments on this document. Special
thanks should be given to Jim Uttaro and Eric Rosen for their
proposal of using a new TLV of the AIGP attribute to convey the
network latency metric.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
skipping to change at page 7, line 44 skipping to change at page 8, line 26
"The Accumulated IGP Metric Attribute for BGP", RFC 7311, "The Accumulated IGP Metric Attribute for BGP", RFC 7311,
August 2014. August 2014.
10.2. Informative References 10.2. Informative References
[I-D.ietf-idr-add-paths] [I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-10 (work in progress), October 2014. add-paths-10 (work in progress), October 2014.
[I-D.ietf-idr-bgp-optimal-route-reflection]
Raszuk, R., Cassar, C., Aman, E., Decraene, B., and S.
Litkowski, "BGP Optimal Route Reflection (BGP-ORR)",
draft-ietf-idr-bgp-optimal-route-reflection-08 (work in
progress), October 2014.
[I-D.ietf-isis-te-metric-extensions] [I-D.ietf-isis-te-metric-extensions]
Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,
A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering
(TE) Metric Extensions", draft-ietf-isis-te-metric- (TE) Metric Extensions", draft-ietf-isis-te-metric-
extensions-04 (work in progress), October 2014. extensions-04 (work in progress), October 2014.
[I-D.ietf-ospf-te-metric-extensions] [I-D.ietf-ospf-te-metric-extensions]
Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", draft-ietf-ospf-te-metric-extensions-10 (work Extensions", draft-ietf-ospf-te-metric-extensions-11 (work
in progress), January 2015. in progress), January 2015.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Delay Metric for IPPM", RFC 2679, September 1999.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630, September
skipping to change at page 8, line 31 skipping to change at page 9, line 15
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January "Multiprotocol Extensions for BGP-4", RFC 4760, January
2007. 2007.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009. with BGP-4", RFC 5492, February 2009.
[RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K.
Kumaki, "Distribution of Diverse BGP Paths", RFC 6774,
November 2012.
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
Huawei Huawei
Email: xuxiaohu@huawei.com Email: xuxiaohu@huawei.com
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
skipping to change at line 397 skipping to change at page 10, line 18
Hui Ni Hui Ni
Huawei Huawei
Email: nihui@huawei.com Email: nihui@huawei.com
Yongbing Fan Yongbing Fan
China Telecom China Telecom
Email: fanyb@gsta.com Email: fanyb@gsta.com
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid, 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://people.tid.es/LuisM.Contreras/
 End of changes. 21 change blocks. 
52 lines changed or deleted 98 lines changed or added

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