draft-ietf-isis-te-metric-extensions-07.txt   draft-ietf-isis-te-metric-extensions-08.txt 
Networking Working Group S. Previdi, Ed. Networking Working Group S. Previdi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Giacalone Intended status: Standards Track S. Giacalone
Expires: December 18, 2015 Unaffiliated Expires: July 21, 2016 Unaffiliated
D. Ward D. Ward
Cisco Systems, Inc. Cisco Systems, Inc.
J. Drake J. Drake
A. Atlas
Juniper Networks Juniper Networks
C. Filsfils
Cisco Systems, Inc.
Q. Wu Q. Wu
Huawei Huawei
June 16, 2015 January 18, 2016
IS-IS Traffic Engineering (TE) Metric Extensions IS-IS Traffic Engineering (TE) Metric Extensions
draft-ietf-isis-te-metric-extensions-07 draft-ietf-isis-te-metric-extensions-08
Abstract Abstract
In certain networks, such as, but not limited to, financial In certain networks, such as, but not limited to, financial
information networks (e.g. stock market data providers), network information networks (e.g. stock market data providers), network
performance criteria (e.g. latency) are becoming as critical to data performance criteria (e.g. latency) are becoming as critical to data
path selection as other metrics. path selection as other metrics.
This document describes extensions to IS-IS Traffic Engineering This document describes extensions to IS-IS Traffic Engineering
Extensions (RFC5305) such that network performance information can be Extensions (RFC5305) such that network performance information can be
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 December 18, 2015. This Internet-Draft will expire on July 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
4.5. Unidirectional Residual Bandwidth Sub-TLV . . . . . . . . 9 4.5. Unidirectional Residual Bandwidth Sub-TLV . . . . . . . . 9
4.6. Unidirectional Available Bandwidth Sub-TLV . . . . . . . 10 4.6. Unidirectional Available Bandwidth Sub-TLV . . . . . . . 10
4.7. Unidirectional Utilized Bandwidth Sub-TLV . . . . . . . . 11 4.7. Unidirectional Utilized Bandwidth Sub-TLV . . . . . . . . 11
5. Announcement Thresholds and Filters . . . . . . . . . . . . . 12 5. Announcement Thresholds and Filters . . . . . . . . . . . . . 12
6. Announcement Suppression . . . . . . . . . . . . . . . . . . 13 6. Announcement Suppression . . . . . . . . . . . . . . . . . . 13
7. Network Stability and Announcement Periodicity . . . . . . . 13 7. Network Stability and Announcement Periodicity . . . . . . . 13
8. Enabling and Disabling Sub-TLVs . . . . . . . . . . . . . . . 14 8. Enabling and Disabling Sub-TLVs . . . . . . . . . . . . . . . 14
9. Static Metric Override . . . . . . . . . . . . . . . . . . . 14 9. Static Metric Override . . . . . . . . . . . . . . . . . . . 14
10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Normative References . . . . . . . . . . . . . . . . . . 15 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.2. Informative References . . . . . . . . . . . . . . . . . 16 15.1. Normative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 15.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
In certain networks, such as, but not limited to, financial In certain networks, such as, but not limited to, financial
information networks (e.g. stock market data providers), network information networks (e.g. stock market data providers), network
performance information (e.g. latency) is becoming as critical to performance information (e.g. latency) is becoming as critical to
data path selection as other metrics. data path selection as other metrics.
In these networks, extremely large amounts of money rest on the In these networks, extremely large amounts of money rest on the
ability to access market data in "real time" and to predictably make ability to access market data in "real time" and to predictably make
trades faster than the competition. Because of this, using metrics trades faster than the competition. Because of this, using metrics
such as hop count or cost as routing metrics is becoming only such as hop count or cost as routing metrics is becoming only
tangentially important. Rather, it would be beneficial to be able to tangentially important. Rather, it would be beneficial to be able to
make path selection decisions based on performance data (such as make path selection decisions based on performance data (such as
latency) in a cost-effective and scalable way. latency) in a cost-effective and scalable way.
This document describes extensions to IS-IS Extended Reachability TLV This document describes extensions to IS-IS Extended Reachability TLV
defined in [RFC5305] (hereafter called "IS-IS TE Metric Extensions"), defined in [RFC5305] (hereafter called "IS-IS TE Metric Extensions"),
that can be used to distribute network performance information (such that can be used to distribute network performance information (such
as link delay, delay variation, link loss, residual bandwidth, and as link delay, delay variation, packet loss, residual bandwidth, and
available bandwidth). available bandwidth).
The data distributed by the TE Metric Extensions proposed in this The data distributed by the TE Metric Extensions proposed in this
document is meant to be used as part of the operation of the routing document is meant to be used as part of the operation of the routing
protocol (e.g. by replacing cost with latency or considering protocol (e.g. by replacing cost with latency or considering
bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or
for other uses such as supplementing the data used by an ALTO server for other uses such as supplementing the data used by an ALTO server
[RFC7285]. With respect to CSPF, the data distributed by ISIS TE [RFC7285]. With respect to CSPF, the data distributed by ISIS TE
Metric Extensions can be used to setup, fail over, and fail back data Metric Extensions can be used to setup, fail over, and fail back data
paths using protocols such as RSVP-TE [RFC3209]. paths using protocols such as RSVP-TE [RFC3209].
skipping to change at page 4, line 16 skipping to change at page 4, line 17
measurement. For links, such as Forwarding Adjacencies, care must be measurement. For links, such as Forwarding Adjacencies, care must be
taken that measurement of the associated delay avoids significant taken that measurement of the associated delay avoids significant
queuing delay; that could be accomplished in a variety of ways, queuing delay; that could be accomplished in a variety of ways,
including either by measuring with a traffic class that experiences including either by measuring with a traffic class that experiences
minimal queuing or by summing the measured link delays of the minimal queuing or by summing the measured link delays of the
components of the link's path. components of the link's path.
2. TE Metric Extensions to IS-IS 2. TE Metric Extensions to IS-IS
This document proposes new IS-IS TE sub-TLVs that can be announced in This document proposes new IS-IS TE sub-TLVs that can be announced in
TLVs 22, 23, 141, 222, and 223 in order to distribute network TLVs 22, 141, 222, and 223 in order to distribute network performance
performance information. The extensions in this document build on information. The extensions in this document build on the ones
the ones provided in IS-IS TE [RFC5305] and GMPLS [RFC4203]. provided in IS-IS TE [RFC5305] and GMPLS [RFC4203].
IS-IS Extended Reachability TLV 22 (defined in [RFC5305]), Inter-AS IS-IS Extended Reachability TLV 22 (defined in [RFC5305]), Inter-AS
reachability information TLV 141 (defined in [RFC5316]) and MT-ISIS reachability information TLV 141 (defined in [RFC5316]) and MT-ISIS
TLV 222 (defined in [RFC5120]) have nested sub-TLVs which permit the TLV 222 (defined in [RFC5120]) have nested sub-TLVs which permit the
TLVs to be readily extended. This document proposes several TLVs to be readily extended. This document proposes several
additional sub-TLVs: additional sub-TLVs:
Type Value Type Value
---------------------------------------------------- ----------------------------------------------------
33 (Suggested) Unidirectional Link Delay 33 (Suggested) Unidirectional Link Delay
34 (Suggested) Min/Max Unidirectional Link Delay 34 (Suggested) Min/Max Unidirectional Link Delay
35 (Suggested) Unidirectional Delay Variation 35 (Suggested) Unidirectional Delay Variation
36 (Suggested) Unidirectional Link Loss 36 (Suggested) Unidirectional Packet Loss
37 (Suggested) Unidirectional Residual Bandwidth 37 (Suggested) Unidirectional Residual Bandwidth
38 (Suggested) Unidirectional Available Bandwidth 38 (Suggested) Unidirectional Available Bandwidth
39 (Suggested) Unidirectional Bandwidth Utilization 39 (Suggested) Unidirectional Bandwidth Utilization
As can be seen in the list above, the sub-TLVs described in this As can be seen in the list above, the sub-TLVs described in this
document carry different types of network performance information. document carry different types of network performance information.
The new sub-TLVs include a bit called the Anomalous (or "A") bit. The new sub-TLVs include a bit called the Anomalous (or "A") bit.
skipping to change at page 5, line 38 skipping to change at page 5, line 38
Note that when a sub-TLV does not include the A bit, that sub-TLV Note that when a sub-TLV does not include the A bit, that sub-TLV
cannot be used for failover purposes. The A bit was intentionally cannot be used for failover purposes. The A bit was intentionally
omitted from some sub-TLVs to help mitigate oscillations. See omitted from some sub-TLVs to help mitigate oscillations. See
Section 5 for more information. Section 5 for more information.
Consistent with existing IS-IS TE specification [RFC5305], the Consistent with existing IS-IS TE specification [RFC5305], the
bandwidth advertisements defined in this draft MUST be encoded as bandwidth advertisements defined in this draft MUST be encoded as
IEEE floating point values. The delay and delay variation IEEE floating point values. The delay and delay variation
advertisements defined in this draft MUST be encoded as integer advertisements defined in this draft MUST be encoded as integer
values. Delay values MUST be quantified in units of microseconds, values. Delay values MUST be quantified in units of microseconds,
link loss MUST be quantified as a percentage of packets sent, and packet loss MUST be quantified as a percentage of packets sent, and
bandwidth MUST be sent as bytes per second. All values (except bandwidth MUST be sent as bytes per second. All values (except
residual bandwidth) MUST be calculated as rolling averages where the residual bandwidth) MUST be calculated as rolling averages where the
averaging period MUST be a configurable period of time. See averaging period MUST be a configurable period of time. See
Section 5 for more information. Section 5 for more information.
3. Interface and Neighbor Addresses 3. Interface and Neighbor Addresses
The use of TE Metric Extensions SubTLVs is not confined to the TE The use of TE Metric Extensions SubTLVs is not confined to the TE
context. In other words, IS-IS TE Metric Extensions SubTLVs defined context. In other words, IS-IS TE Metric Extensions SubTLVs defined
in this document can also be used for computing paths in the absence in this document can also be used for computing paths in the absence
skipping to change at page 8, line 46 skipping to change at page 8, line 46
Delay Variation. This 24-bit field carries the average link delay Delay Variation. This 24-bit field carries the average link delay
variation over a configurable interval in microseconds, encoded as an variation over a configurable interval in microseconds, encoded as an
integer value. When set to 0, it has not been measured. When set to integer value. When set to 0, it has not been measured. When set to
the maximum value 16,777,215 (16.777215 sec), then the delay is at the maximum value 16,777,215 (16.777215 sec), then the delay is at
least that value and may be larger. least that value and may be larger.
4.4. Unidirectional Link Loss Sub-TLV 4.4. Unidirectional Link Loss Sub-TLV
This sub-TLV advertises the loss (as a packet percentage) between two This sub-TLV advertises the loss (as a packet percentage) between two
directly connected IS-IS neighbors. The link loss advertised by this directly connected IS-IS neighbors. The link loss advertised by this
sub-TLV MUST be the packet loss from the advertising node to its sub-TLV MUST be the packet loss from the local neighbor to the remote
neighbor (i.e. the forward path loss). The format of this sub-TLV is one (i.e. the forward path loss). The format of this sub-TLV is
shown in the following diagram: shown in the following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Link Loss | |A| RESERVED | Link Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 10 skipping to change at page 12, line 10
directly connected IS-IS neighbors. The bandwidth utilization directly connected IS-IS neighbors. The bandwidth utilization
advertised by this sub-TLV MUST be the bandwidth from the system advertised by this sub-TLV MUST be the bandwidth from the system
originating this Sub-TLV. The format of this Sub-TLV is shown in the originating this Sub-TLV. The format of this Sub-TLV is shown in the
following diagram: following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED | | Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Utilization | | Utilized Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Figure 5 Figure 5
Type: TBA (suggested value: 39). Type: TBA (suggested value: 39).
Length: 4. Length: 4.
skipping to change at page 14, line 37 skipping to change at page 14, line 37
simplify migration and to mitigate scenarios where dynamic simplify migration and to mitigate scenarios where dynamic
measurements are not possible. measurements are not possible.
10. Compatibility 10. Compatibility
As per [RFC5305], unrecognized Sub-TLVs should be silently ignored. As per [RFC5305], unrecognized Sub-TLVs should be silently ignored.
11. Security Considerations 11. Security Considerations
This document does not introduce security issues beyond those This document does not introduce security issues beyond those
discussed in [RFC5305] and [RFC5329]. discussed in [RFC5305].
Section 7 describe a mechanism in order to ensure network stability
when the new sub-TLVs defined in this document are advertised.
Implementation SHOULD follow the described guidelines in order to
mitigate the instability risk.
[RFC5304] describes an authentication method for ISIS LSP that allows
cryptographic authentication of IS-IS LSPs. LSP cryptographic
authentication is recommended when
It is anticipated that in most deployments, IS-IS protocol is used
within an infrastructure entirely under control of the dame operator.
However, it is worth to consider that the effect of sending IS-IS
Traffic Engineering Sub-TLVs over insecure links could result in a
man-in-the-middle attacker delaying real time data to a given site
(or destination), which could negatively affect the value of the data
for that site/destination. The use of LSP cryptographic
authentication allows to mitigate the risk of man-in-the-middle
attack.
12. IANA Considerations 12. IANA Considerations
IANA maintains the registry for the sub-TLVs. IS-IS TE Metric IANA maintains the registry for the sub-TLVs. IS-IS TE Metric
Extensions will require one new type code per sub-TLV defined in this Extensions will require one new type code per sub-TLV defined in this
document in the following sub-TLV registry: TLVs 22, 23, 141, 222, document in the following sub-TLV registry: TLVs 22, 23, 141, 222,
and 223: and 223:
Type Value Type Value
---------------------------------------------------- ----------------------------------------------------
33 (Suggested) Unidirectional Link Delay 33 (Suggested) Unidirectional Link Delay
34 (Suggested) Min/Max Unidirectional Link Delay 34 (Suggested) Min/Max Unidirectional Link Delay
35 (Suggested) Unidirectional Delay Variation 35 (Suggested) Unidirectional Delay Variation
36 (Suggested) Unidirectional Link Loss 36 (Suggested) Unidirectional Packet Loss
37 (Suggested) Unidirectional Residual Bandwidth 37 (Suggested) Unidirectional Residual Bandwidth
38 (Suggested) Unidirectional Available Bandwidth 38 (Suggested) Unidirectional Available Bandwidth
39 (Suggested) Unidirectional Bandwidth Utilization 39 (Suggested) Unidirectional Bandwidth Utilization
13. Acknowledgements 13. Contributors
The following people gave a substantial contribution to the content
of this document and should be considered as co-authors:
Alia Atlas
Juniper Networks
US
akatlas@juniper.net
Clarence Filsfils
Cisco Systems Inc.
Belgium
Email: cfilsfil@cisco.com
14. Acknowledgements
The authors would like to recognize Ayman Soliman, Nabil Bitar, David The authors would like to recognize Ayman Soliman, Nabil Bitar, David
McDysan, Les Ginsberg, Edward Crabbe, Don Fedyk, Hannes Gredler and McDysan, Les Ginsberg, Edward Crabbe, Don Fedyk, Hannes Gredler, Uma
Uma Chunduri for their contributions. Chunduri and Brian Weis for their contribution and review of this
document.
The authors also recognize Curtis Villamizar for significant comments The authors also recognize Curtis Villamizar for significant comments
and direct content collaboration. and direct content collaboration.
14. References 15. References
14.1. Normative References 15.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,
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., <http://www.rfc-editor.org/info/rfc2119>.
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005,
<http://www.rfc-editor.org/info/rfc4206>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008. Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<http://www.rfc-editor.org/info/rfc5120>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <http://www.rfc-editor.org/info/rfc5304>.
[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, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, December 2008. Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <http://www.rfc-editor.org/info/rfc5316>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
"Traffic Engineering Extensions to OSPF Version 3", RFC
5329, September 2008.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, February 2011. Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 15.2. Informative References
Measurement for MPLS Networks", RFC 6374, September 2011.
14.2. Informative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Measurement Profile for MPLS-Based Transport Networks", Support of Generalized Multi-Protocol Label Switching
RFC 6375, September 2011. (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>.
[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Measurement for MPLS Networks", RFC 6374,
Traffic Optimization (ALTO) Protocol", RFC 7285, September DOI 10.17487/RFC6374, September 2011,
2014. <http://www.rfc-editor.org/info/rfc6374>.
[RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
Delay Measurement Profile for MPLS-Based Transport
Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011,
<http://www.rfc-editor.org/info/rfc6375>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<http://www.rfc-editor.org/info/rfc7285>.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Via Del Serafico 200 Via Del Serafico 200
Rome 00191 Rome 00191
IT IT
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
skipping to change at page 17, line 20 skipping to change at page 18, line 20
Email: wardd@cisco.com Email: wardd@cisco.com
John Drake John Drake
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: jdrake@juniper.net Email: jdrake@juniper.net
Alia Atlas
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Email: akatlas@juniper.net
Clarence Filsfils
Cisco Systems, Inc.
Brussels
Belgium
Email: cfilsfil@cisco.com
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: sunseawq@huawei.com Email: sunseawq@huawei.com
 End of changes. 31 change blocks. 
73 lines changed or deleted 108 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/