draft-ietf-isis-te-metric-extensions-09.txt   draft-ietf-isis-te-metric-extensions-10.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 23, 2016 Unaffiliated Expires: August 12, 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 20, 2016 February 9, 2016
IS-IS Traffic Engineering (TE) Metric Extensions IS-IS Traffic Engineering (TE) Metric Extensions
draft-ietf-isis-te-metric-extensions-09 draft-ietf-isis-te-metric-extensions-10
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 July 23, 2016. This Internet-Draft will expire on August 12, 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 4, line 7 skipping to change at page 4, line 7
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
of delay SHOULD NOT vary significantly based upon the offered traffic of delay SHOULD NOT vary significantly based upon the offered traffic
load. Thus, queuing delays SHOULD NOT be included in the delay load. Thus, queuing delays SHOULD NOT be included in the delay
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, 141, 222, and 223 in order to distribute network performance TLVs 22, 141, 222, and 223 in order to distribute network performance
skipping to change at page 7, line 31 skipping to change at page 7, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Figure 2 Figure 2
Type: TBA (suggested value: 34). Type: TBA (suggested value: 34).
Length: 8. Length: 8.
A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set This field represents the Anomalous (A) bit. The A bit is set when
when the measured value of this parameter exceeds its configured one or more measured values exceed a configured maximum threshold.
maximum threshold. The A bit is cleared when the measured value The A bit is cleared when the measured value falls below its
falls below its configured reuse threshold. If the A-bit is clear, configured reuse threshold. If the A bit is clear, the sub-TLV
the sub-TLV represents steady state link performance. represents steady state link performance.
RESERVED. This field is reserved for future use. It MUST be set to RESERVED. This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received. 0 when sent and MUST be ignored when received.
Min Delay. This 24-bit field carries minimum measured link delay Min Delay. This 24-bit field carries minimum measured link delay
value (in microseconds) over a configurable interval, encoded as an value (in microseconds) over a configurable interval, encoded as an
integer value. integer value.
Max Delay. This 24-bit field carries the maximum measured link delay Max Delay. This 24-bit field carries the maximum measured link delay
value (in microseconds) over a configurable interval, encoded as an value (in microseconds) over a configurable interval, encoded as an
skipping to change at page 12, line 39 skipping to change at page 12, line 39
utilization is defined to be the sum of the component link bandwidth utilization is defined to be the sum of the component link bandwidth
utilizations. utilizations.
5. Announcement Thresholds and Filters 5. Announcement Thresholds and Filters
The values advertised in all sub-TLVs (except Min/Max delay and The values advertised in all sub-TLVs (except Min/Max delay and
residual bandwidth) MUST represent an average over a period or be residual bandwidth) MUST represent an average over a period or be
obtained by a filter that is reasonably representative of an average. obtained by a filter that is reasonably representative of an average.
For example, a rolling average is one such filter. For example, a rolling average is one such filter.
Min and max delay MAY be the lowest and/or highest measured value Min and max delay MUST each be derived in one of the following ways:
over a measurement interval or MAY make use of a filter, or other by taking the lowest and/or highest measured value over a measurement
technique, to obtain a reasonable representation of a min and max interval, or by making use of a filter or other technique to obtain a
value representative of the interval with compensation for outliers. reasonable representation of a min and max value representative of
the interval, with compensation for outliers.
The measurement interval, any filter coefficients, and any The measurement interval, any filter coefficients, and any
advertisement intervals MUST be configurable per sub-TLV. advertisement intervals MUST be configurable per sub-TLV.
In addition to the measurement intervals governing re-advertisement, In addition to the measurement intervals governing re-advertisement,
implementations SHOULD provide per sub-TLV configurable accelerated implementations SHOULD provide per sub-TLV configurable accelerated
advertisement thresholds, such that: advertisement thresholds, such that:
1. If the measured parameter falls outside a configured upper 1. If the measured parameter falls outside a configured upper
bound for all but the min delay metric (or lower bound for bound for all but the min delay metric (or lower bound for
skipping to change at page 14, line 36 skipping to change at page 14, line 36
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 The subTLVs introduced in this document allow an operator to
discussed in [RFC5305]. advertise state information of links (bandwidth, delay) that could be
sensitive and that an operator may not want to disclose.
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 IS-IS LSP that [RFC5304] describes an authentication method for IS-IS LSP that
allows cryptographic authentication of IS-IS LSPs. allows cryptographic authentication of IS-IS LSPs.
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 same 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
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, Alvaro Retana and Brian Weis for their contribution and Chunduri, Alvaro Retana, Brian Weis and Barry Leiba for their
review of this document. 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.
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. 10 change blocks. 
19 lines changed or deleted 21 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/