draft-ietf-idr-performance-routing-01.txt   draft-ietf-idr-performance-routing-02.txt 
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Huawei Internet-Draft Alibaba, Inc
Intended status: Standards Track M. Boucadair Intended status: Standards Track S. Hegde
Expires: August 30, 2015 C. Jacquenet Expires: April 12, 2020 Juniper
K. Talaulikar
Cisco
M. Boucadair
C. Jacquenet
France Telecom France Telecom
N. So October 10, 2019
Vinci Systems
Y. Shen
Juniper
U. Chunduri
Ericsson
H. Ni
Huawei
Y. Fan
China Telecom
L. Contreras
Telefonica I+D
February 26, 2015
Performance-based BGP Routing Mechanism Performance-based BGP Routing Mechanism
draft-ietf-idr-performance-routing-01 draft-ietf-idr-performance-routing-02
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 https://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 April 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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 3, line 31 skipping to change at page 3, line 31
performance metric that's the network latency metric. The support of performance metric that's the network latency metric. The support of
multiple network performance metrics is out of scope of this multiple network performance metrics is out of scope of this
document. In addition, this document focuses exclusively on BGP document. In addition, this document focuses exclusively on BGP
matters and therefore all those BGP-irrelevant matters such as the matters and therefore all those BGP-irrelevant matters such as the
mechanisms for measuring network latency are outside the scope of mechanisms for measuring network latency are outside the scope of
this document. this document.
A variant of this performance-based BGP routing is implemented (see A variant of this performance-based BGP routing is implemented (see
http://www.ist-mescal.org/roadmap/qbgp-demo.avi). http://www.ist-mescal.org/roadmap/qbgp-demo.avi).
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
This memo makes use of the terms defined in [RFC4271]. This memo makes use of the terms defined in [RFC4271].
Network latency indicates the amount of time it takes for a packet to Network latency indicates the amount of time it takes for a packet to
traverse a given network path [RFC2679]. Provided a packet was traverse a given network path [RFC2679]. Provided a packet was
forwarded along a path which contains multiple links and routers, the forwarded along a path which contains multiple links and routers, the
network latency would be the sum of the transmission latency of each network latency would be the sum of the transmission latency of each
link (i.e., link latency), plus the sum of the internal delay link (i.e., link latency), plus the sum of the internal delay
occurred within each router (i.e., router latency) which includes occurred within each router (i.e., router latency) which includes
skipping to change at page 6, line 12 skipping to change at page 6, line 5
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. latency from the BGP speaker to the NEXT_HOP of that route.
The Loc-RIB of the performance routing paradigm is independent from The Loc-RIB of the performance routing paradigm is independent from
that of the vanilla routing paradigm. Accordingly, the routing table that of the vanilla routing paradigm. Accordingly, the routing table
of the performance routing paradigm is independent from that of the of the performance routing paradigm is independent from that of the
vanilla routing paradigm. Whether the performance routing paradigm vanilla routing paradigm. Whether the performance routing paradigm
or the vanilla routing paradigm would be applied to a given packet is or the vanilla routing paradigm would be applied to a given packet is
a local policy issue which is outside the scope of this document. a local policy issue which is outside the scope of this document.
For example, by leveraging the Cos-Based Forwarding (CBF) capability
which allows routers to have distinct routing and forwarding tables
for each type of traffic, the selected performance routes could be
installed in the routing and forwarding tables corresponding to high-
priority traffic.
6. Deployment Considerations 6. Deployment Considerations
This section is not normative. This section is not normative.
Enabling the performance-based BGP routing at large (i.e., among Enabling the performance-based BGP routing at large (i.e., among
domains that do not belong to the same administrative entity) may be domains that do not belong to the same administrative entity) may be
conditioned by other administrative settlement considerations that conditioned by other administrative settlement considerations that
are out of scope of this document. Nevertheless, this document does are out of scope of this document. Nevertheless, this document does
not require nor exclude activating the proposed route selection not require nor exclude activating the proposed route selection
scheme between domains that are managed by distinct administrative scheme between domains that are managed by distinct administrative
skipping to change at page 6, line 40 skipping to change at page 6, line 39
throughout the domains. Besides security considerations that may throughout the domains. Besides security considerations that may
arise (and which are further discussed in Section 9), there is indeed arise (and which are further discussed in Section 9), there is indeed
a need to consistently enforce a low-latency-based BGP routing policy a need to consistently enforce a low-latency-based BGP routing policy
within a set of domains that belong to the same administrative within a set of domains that belong to the same administrative
entity. This is motivated by the processing of traffic which is of entity. This is motivated by the processing of traffic which is of
very different nature and which may have different QoS requirements. very different nature and which may have different QoS requirements.
Moreover, the combined use of BGP-inferred low latency information Moreover, the combined use of BGP-inferred low latency information
with traffic engineering tools that would lead to the computation and with traffic engineering tools that would lead to the computation and
the establishment of traffic-engineered LSP paths between "low the establishment of traffic-engineered LSP paths between "low
latency"-enabled BGP peers based upon the manipulation of the latency"-enabled BGP peers based upon the manipulation of the
Unidirectional Link delay sub-TLV Unidirectional Link delay sub-TLV [RFC7810] [RFC7471] would
[I-D.ietf-isis-te-metric-extensions] contribute to guarantee the overall consistency of the low latency
[I-D.ietf-ospf-te-metric-extensions] would contribute to guarantee information within each domain. Furthmore, a BGP color extended
the overall consistency of the low latency information within each community could be attached to the performance routes so as to
domain. associates a low-latency Segment Routing (SR) LSP towards the BGP
NEXT_HOP with these low-latency BGP routes, in this way, those
traffic matching the low-latency BGP routes would be forwarded to the
BGP NEXT_HOP via the low-latency SR LSP towards that BGP NEXT_HOP.
In network environments where router reflectors are deployed but In network environments where router reflectors are deployed but
next-hop-self is disabled on them, route reflectors usually reflect next-hop-self is disabled on them, route reflectors usually reflect
those received routes which are optimal (i.e., lowest latency) from those received routes which are optimal (i.e., lowest latency) from
their perspectives but may not be optimal from the receivers' their perspectives but may not be optimal from the receivers'
perspectives. Some existing solutions as described in perspectives. Some existing solutions as described in [RFC7911], [I-
[I-D.ietf-idr-add-paths], [I-D.ietf-idr-bgp-optimal-route-reflection] D.ietf-idr-bgp-optimal-route-reflection] and [RFC6774] can be used to
and [RFC6774] can be used to address this issue. address this issue.
From a network provider perspective, the ability to manipulate low From a network provider perspective, the ability to manipulate low
latency routes may lead to different, presumably service-specific latency routes may lead to different, presumably service-specific
designs. In particular, there is a need to assess the impact of designs. In particular, there is a need to assess the impact of
using such capability on the overall performance of the BGP peers using such capability on the overall performance of the BGP peers
from a route computation and selection procedure as a function of the from a route computation and selection procedure as a function of the
tie-breaking operation. A typical use case would consist in tie-breaking operation. A typical use case would consist in
selecting low latency routes for traffic that for example pertains to selecting low latency routes for traffic that for example pertains to
the VoIP, or whose nature demands the selection of the lowest latency the VoIP, or whose nature demands the selection of the lowest latency
route in the Adj-RIB-Out database of the corresponding BGP peers. route in the Adj-RIB-Out database of the corresponding BGP peers.
Typically, live broadcasting services or some e-health services could Typically, live broadcasting services or some e-health services could
certainly take advantage of such capability. It is out of scope of certainly take advantage of such capability. It is out of scope of
this document to exhaustively elaborate on such service-specific this document to exhaustively elaborate on such service-specific
designs that are obviously deployment-specific. designs that are obviously deployment-specific.
7. IANA Considerations 7. Contributors
Ning So
Reliance
Email: Ning.So@ril.com
Yimin Shen
Juniper
Email: yshen@juniper.net
Uma Chunduri
Huawei
Email: uma.chunduri@huawei.com
Hui Ni
Huawei
Email: nihui@huawei.com
Yongbing Fan
China Telecom
Email: fanyb@gsta.com
Luis M. Contreras
Telefonica I+D
Email: luismiguel.contrerasmurillo@telefonica.com
8. 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.
9. 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.
8. Security Considerations 10. 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 11. References
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.1. Normative References 11.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,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
Protocol 4 (BGP-4)", RFC 4271, January 2006. BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<https://www.rfc-editor.org/info/rfc3107>.
[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
"The Accumulated IGP Metric Attribute for BGP", RFC 7311, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
August 2014. DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
10.2. Informative References [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[I-D.ietf-idr-add-paths] [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
Walton, D., Retana, A., Chen, E., and J. Scudder, with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- 2009, <https://www.rfc-editor.org/info/rfc5492>.
add-paths-10 (work in progress), October 2014.
[I-D.ietf-idr-bgp-optimal-route-reflection] 11.2. Informative References
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-idr-bgp-optimal-route-reflection]
Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, Raszuk, R., Cassar, C., Aman, E., Decraene, B., and K.
A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering Wang, "BGP Optimal Route Reflection (BGP-ORR)", draft-
(TE) Metric Extensions", draft-ietf-isis-te-metric- ietf-idr-bgp-optimal-route-reflection-19 (work in
extensions-04 (work in progress), October 2014. progress), July 2019.
[I-D.ietf-ospf-te-metric-extensions] [I-D.ietf-spring-segment-routing-policy]
Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
Previdi, "OSPF Traffic Engineering (TE) Metric bogdanov@google.com, b., and P. Mattes, "Segment Routing
Extensions", draft-ietf-ospf-te-metric-extensions-11 (work Policy Architecture", draft-ietf-spring-segment-routing-
in progress), January 2015. policy-03 (work in progress), May 2019.
[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, DOI 10.17487/RFC2679,
September 1999, <https://www.rfc-editor.org/info/rfc2679>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
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,
2003. DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
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, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D.,
with BGP-4", RFC 5492, February 2009. and K. Kumaki, "Distribution of Diverse BGP Paths",
RFC 6774, DOI 10.17487/RFC6774, November 2012,
<https://www.rfc-editor.org/info/rfc6774>.
[RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K. [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Kumaki, "Distribution of Diverse BGP Paths", RFC 6774, Previdi, "OSPF Traffic Engineering (TE) Metric
November 2012. Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
RFC 7810, DOI 10.17487/RFC7810, May 2016,
<https://www.rfc-editor.org/info/rfc7810>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<https://www.rfc-editor.org/info/rfc7911>.
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
Huawei Alibaba, Inc
Email: xuxiaohu@huawei.com Email: xiaohu.xxh@alibaba-inc.com
Shraddha Hegde
Juniper
Email: shraddha@juniper.net
Ketan Talaulikar
Cisco
Email: ketant@cisco.com
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Christian Jacquenet Christian Jacquenet
France Telecom France Telecom
Email: christian.jacquenet@orange.com Email: christian.jacquenet@orange.com
Ning So
Vinci Systems
Email: ning.so@vinci-systems.com
Yimin Shen
Juniper
Email: yshen@juniper.net
Uma Chunduri
Ericsson
Email: uma.chunduri@ericsson.com
Hui Ni
Huawei
Email: nihui@huawei.com
Yongbing Fan
China Telecom
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. 34 change blocks. 
101 lines changed or deleted 150 lines changed or added

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