draft-ietf-isis-te-metric-extensions-08.txt   draft-ietf-isis-te-metric-extensions-09.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: July 21, 2016 Unaffiliated Expires: July 23, 2016 Unaffiliated
D. Ward D. Ward
Cisco Systems, Inc. Cisco Systems, Inc.
J. Drake J. Drake
Juniper Networks Juniper Networks
Q. Wu Q. Wu
Huawei Huawei
January 18, 2016 January 20, 2016
IS-IS Traffic Engineering (TE) Metric Extensions IS-IS Traffic Engineering (TE) Metric Extensions
draft-ietf-isis-te-metric-extensions-08 draft-ietf-isis-te-metric-extensions-09
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
distributed and collected in a scalable fashion. The information distributed and collected in a scalable fashion. The information
distributed using ISIS TE Metric Extensions can then be used to make distributed using IS-IS TE Metric Extensions can then be used to make
path selection decisions based on network performance. path selection decisions based on network performance.
Note that this document only covers the mechanisms with which network Note that this document only covers the mechanisms with which network
performance information is distributed. The mechanisms for measuring performance information is distributed. The mechanisms for measuring
network performance or acting on that information, once distributed, network performance or acting on that information, once distributed,
are outside the scope of this document. are outside the scope of this document.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
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 July 21, 2016. This Internet-Draft will expire on July 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
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 (hereafter called "IS-IS TE Metric
defined in [RFC5305] (hereafter called "IS-IS TE Metric Extensions"), Extensions") to IS-IS Extended Reachability TLV defined in [RFC5305],
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, packet 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 IS-IS TE Metric Extensions proposed in
document is meant to be used as part of the operation of the routing this document is meant to be used as part of the operation of the
protocol (e.g. by replacing cost with latency or considering routing 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 IS-IS 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].
Note that the mechanisms described in this document only disseminate Note that the mechanisms described in this document only disseminate
performance information. The methods for initially gathering that performance information. The methods for initially gathering that
performance information, such as [RFC6375], or acting on it once it performance information, such as [RFC6375], or acting on it once it
is distributed are outside the scope of this document. Example is distributed are outside the scope of this document. Example
mechanisms to measure latency, delay variation, and loss in an MPLS mechanisms to measure latency, delay variation, and loss in an MPLS
network are given in [RFC6374]. While this document does not specify network are given in [RFC6374]. While this document does not specify
how the performance information should be obtained, the measurement how the performance information should be obtained, the measurement
skipping to change at page 5, line 46 skipping to change at page 5, line 46
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,
packet 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 IS-IS TE Metric Extensions sub-TLVs is not confined to the
context. In other words, IS-IS TE Metric Extensions SubTLVs defined TE context. In other words, IS-IS TE Metric Extensions sub-TLVs
in this document can also be used for computing paths in the absence defined in this document can also be used for computing paths in the
of a TE subsystem. absence of a TE subsystem.
However, as for the TE case, Interface Address and Neighbor Address However, as for the TE case, Interface Address and Neighbor Address
SubTLVs (IPv4 or IPv6) MUST be present. The encoding is defined in sub-TLVs (IPv4 or IPv6) MUST be present. The encoding is defined in
[RFC5305] for IPv4 and in [RFC6119] for IPv6. [RFC5305] for IPv4 and in [RFC6119] for IPv6.
4. Sub TLV Details 4. Sub TLV Details
4.1. Unidirectional Link Delay Sub-TLV 4.1. Unidirectional Link Delay Sub-TLV
This sub-TLV advertises the average link delay between two directly This sub-TLV advertises the average link delay between two directly
connected IS-IS neighbors. The delay advertised by this sub-TLV MUST connected IS-IS neighbors. The delay advertised by this sub-TLV MUST
be the delay from the local neighbor to the remote one (i.e. the be the delay from the local neighbor to the remote one (i.e. the
forward path latency). The format of this sub-TLV is shown in the forward path latency). The format of this sub-TLV is shown in the
skipping to change at page 9, line 43 skipping to change at page 9, line 43
The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. This The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. This
value is the highest packet loss percentage that can be expressed value is the highest packet loss percentage that can be expressed
(the assumption being that precision is more important on high speed (the assumption being that precision is more important on high speed
links than the ability to advertise loss rates greater than this, and links than the ability to advertise loss rates greater than this, and
that high speed links with over 50% loss are unusable). Therefore, that high speed links with over 50% loss are unusable). Therefore,
measured values that are larger than the field maximum SHOULD be measured values that are larger than the field maximum SHOULD be
encoded as the maximum value. encoded as the maximum value.
4.5. Unidirectional Residual Bandwidth Sub-TLV 4.5. Unidirectional Residual Bandwidth Sub-TLV
This TLV advertises the residual bandwidth between two directly This sub-TLV advertises the residual bandwidth between two directly
connected IS-IS neighbors. The residual bandwidth advertised by this connected IS-IS neighbors. The residual bandwidth advertised by this
sub-TLV MUST be the residual bandwidth from the system originating sub-TLV MUST be the residual bandwidth from the system originating
the LSA to its neighbor. the LSA to its neighbor.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Residual Bandwidth | | Residual Bandwidth |
skipping to change at page 10, line 44 skipping to change at page 10, line 44
Unreserved Bandwidth, on the other hand, is subtracted from the Unreserved Bandwidth, on the other hand, is subtracted from the
Maximum Reservable Bandwidth (the bandwidth that can theoretically be Maximum Reservable Bandwidth (the bandwidth that can theoretically be
reserved) and provides per priority remainders. Residual Bandwidth reserved) and provides per priority remainders. Residual Bandwidth
and Unreserved Bandwidth [RFC5305] can be used concurrently, and each and Unreserved Bandwidth [RFC5305] can be used concurrently, and each
has a separate use case (e.g. the former can be used for applications has a separate use case (e.g. the former can be used for applications
like Weighted ECMP while the latter can be used for call admission like Weighted ECMP while the latter can be used for call admission
control). control).
4.6. Unidirectional Available Bandwidth Sub-TLV 4.6. Unidirectional Available Bandwidth Sub-TLV
This Sub-TLV advertises the available bandwidth between two directly This sub-TLV advertises the available bandwidth between two directly
connected IS-IS neighbors. The available bandwidth advertised by connected IS-IS neighbors. The available bandwidth advertised by
this sub-TLV MUST be the available bandwidth from the system this sub-TLV MUST be the available 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Bandwidth | | Available Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 38 skipping to change at page 11, line 38
(see Section 4.5 minus the measured bandwidth used for the actual (see Section 4.5 minus the measured bandwidth used for the actual
forwarding of non-RSVP-TE LSP packets. For a bundled link, available forwarding of non-RSVP-TE LSP packets. For a bundled link, available
bandwidth is defined to be the sum of the component link available bandwidth is defined to be the sum of the component link available
bandwidths minus the measured bandwidth used for the actual bandwidths minus the measured bandwidth used for the actual
forwarding of non-RSVP-TE Label Switched Paths packets. For a forwarding of non-RSVP-TE Label Switched Paths packets. For a
bundled link, available bandwidth is defined to be the sum of the bundled link, available bandwidth is defined to be the sum of the
component link available bandwidths. component link available bandwidths.
4.7. Unidirectional Utilized Bandwidth Sub-TLV 4.7. Unidirectional Utilized Bandwidth Sub-TLV
This Sub-TLV advertises the bandwidth utilization between two This sub-TLV advertises the bandwidth utilization between two
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Utilized Bandwidth | | Utilized Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 32 skipping to change at page 14, line 32
9. Static Metric Override 9. Static Metric Override
Implementations SHOULD permit the static configuration and/or manual Implementations SHOULD permit the static configuration and/or manual
override of dynamic measurements for each sub-TLV in order to override of dynamic measurements for each sub-TLV in order to
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]. discussed in [RFC5305].
Section 7 describe a mechanism in order to ensure network stability Section 7 describe a mechanism in order to ensure network stability
when the new sub-TLVs defined in this document are advertised. when the new sub-TLVs defined in this document are advertised.
Implementation SHOULD follow the described guidelines in order to Implementation SHOULD follow the described guidelines in order to
mitigate the instability risk. mitigate the instability risk.
[RFC5304] describes an authentication method for ISIS LSP that allows [RFC5304] describes an authentication method for IS-IS LSP that
cryptographic authentication of IS-IS LSPs. LSP cryptographic allows cryptographic authentication of IS-IS LSPs.
authentication is recommended when
It is anticipated that in most deployments, IS-IS protocol is used It is anticipated that in most deployments, IS-IS protocol is used
within an infrastructure entirely under control of the dame operator. within an infrastructure entirely under control of the dame operator.
However, it is worth to consider that the effect of sending IS-IS However, it is worth to consider that the effect of sending IS-IS
Traffic Engineering Sub-TLVs over insecure links could result in a Traffic Engineering sub-TLVs over insecure links could result in a
man-in-the-middle attacker delaying real time data to a given site man-in-the-middle attacker delaying real time data to a given site
(or destination), which could negatively affect the value of the data (or destination), which could negatively affect the value of the data
for that site/destination. The use of LSP cryptographic for that site/destination. The use of LSP cryptographic
authentication allows to mitigate the risk of man-in-the-middle authentication allows to mitigate the risk of man-in-the-middle
attack. 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
skipping to change at page 16, line 9 skipping to change at page 16, line 9
Clarence Filsfils Clarence Filsfils
Cisco Systems Inc. Cisco Systems Inc.
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
14. Acknowledgements 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, Uma McDysan, Les Ginsberg, Edward Crabbe, Don Fedyk, Hannes Gredler, Uma
Chunduri and Brian Weis for their contribution and review of this Chunduri, Alvaro Retana and Brian Weis for their contribution and
document. 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.
15. References 15. References
15.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, Requirement Levels", BCP 14, RFC 2119,
 End of changes. 19 change blocks. 
28 lines changed or deleted 27 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/