draft-ietf-teas-te-express-path-05.txt   rfc7823.txt 
TEAS Working Group A. Atlas Internet Engineering Task Force (IETF) A. Atlas
Internet-Draft J. Drake Request for Comments: 7823 J. Drake
Intended status: Informational Juniper Networks Category: Informational Juniper Networks
Expires: April 3, 2016 S. Giacalone ISSN: 2070-1721 S. Giacalone
Unaffiliated Microsoft
S. Previdi S. Previdi
Cisco Systems Cisco Systems
October 1, 2015 May 2016
Performance-based Path Selection for Explicitly Routed LSPs using TE Performance-Based Path Selection for
Metric Extensions Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions
draft-ietf-teas-te-express-path-05
Abstract Abstract
In certain networks, it is critical to consider network performance In certain networks, it is critical to consider network performance
criteria when selecting the path for an explicitly routed RSVP-TE criteria when selecting the path for an explicitly routed RSVP-TE
LSP. Such performance criteria can include latency, jitter, and loss Label Switched Path (LSP). Such performance criteria can include
or other indications such as the conformance to link performance latency, jitter, and loss or other indications such as the
objectives and non-RSVP TE traffic load. This specification conformance to link performance objectives and non-RSVP TE traffic
describes how a path computation function may use network performance load. This specification describes how a path computation function
data, such as is advertised via the OSPF and ISIS TE metric may use network performance data, such as is advertised via the OSPF
extensions (defined outside the scope of this document) to perform and IS-IS TE metric extensions (defined outside the scope of this
such path selections. document) to perform such path selections.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 3, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7823.
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
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. Basic Requirements . . . . . . . . . . . . . . . . . . . 3 1.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 4
1.2. Oscillation and Stability Considerations . . . . . . . . 4 1.2. Oscillation and Stability Considerations . . . . . . . . 4
2. Using Performance Data Constraints . . . . . . . . . . . . . 5 2. Using Performance Data Constraints . . . . . . . . . . . . . 5
2.1. End-to-End Constraints . . . . . . . . . . . . . . . . . 5 2.1. End-to-End Constraints . . . . . . . . . . . . . . . . . 5
2.2. Link Constraints . . . . . . . . . . . . . . . . . . . . 6 2.2. Link Constraints . . . . . . . . . . . . . . . . . . . . 6
2.3. Links out of compliance with Link Performance Objectives 6 2.3. Links out of Compliance with Link Performance Objectives 6
2.3.1. Use of Anomalous Links for New Paths . . . . . . . . 7 2.3.1. Use of Anomalous Links for New Paths . . . . . . . . 7
2.3.2. Links entering the Anomalous State . . . . . . . . . 7 2.3.2. Links Entering the Anomalous State . . . . . . . . . 7
2.3.3. Links leaving the Anomalous State . . . . . . . . . . 8 2.3.3. Links Leaving the Anomalous State . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Normative References . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Informative References . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
In certain networks, such as financial information networks, network In certain networks, such as financial information networks, network
performance information is becoming as critical to data path performance information is becoming as critical to data-path
selection as other existing metrics. Network performance information selection as other existing metrics. Network performance information
can be obtained via either the TE Metric Extensions in OSPF [RFC7471] can be obtained via either the TE Metric Extensions in OSPF [RFC7471]
or ISIS [I-D.ietf-isis-te-metric-extensions] or via a management or IS-IS [RFC7810] or via a management system. As with other TE
system. As with other TE information flooded via OSPF or ISIS, the information flooded via OSPF or IS-IS, the TE metric extensions have
TE metric extensions have a flooding scope limited to the local area a flooding scope limited to the local area or level. This document
or level. This document describes how a path computation function, describes how a path computation function, whether in an ingress LSR
whether in an ingress LSR or a PCE[RFC4655] , can use that or a PCE [RFC4655], can use that information for path selection for
information for path selection for explicitly routed LSPs. The explicitly routed LSPs. The selected path may be signaled via RSVP-
selected path may be signaled via RSVP-TE [RFC3209], [RFC3473] or TE [RFC3209] [RFC3473] or simply used by the ingress with segment
simply used by the ingress with segment routing routing [SEG-ROUTE-MPLS] to properly forward the packet. Methods of
[I-D.ietf-spring-segment-routing-mpls] to properly forward the optimizing path selection for multiple parameters are generally
packet. Methods of optimizing path selection for multiple parameters computationally complex. However, there are good heuristics for the
are generally computationally complex. However, there are good delay-constrained lowest-cost (DCLC) computation problem
heuristics for the delay-constrained lowest-cost (DCLC) computation [k-Paths_DCLC] that can be applied to consider both path cost and a
problem [k-Paths_DCLC] that can be applied to consider both path cost maximum delay bound. Some of the network performance information can
and a maximum delay bound. Some of the network performance also be used to prune links from a topology before computing the
information can also be used to prune links from a topology before path.
computing the path.
The path selection mechanisms described in this document apply to The path selection mechanisms described in this document apply to
paths that are fully computed by the head-end of the LSP and then paths that are fully computed by the head-end of the LSP and then
signaled in an Explicit Route Object (ERO) where every sub-object is signaled in an Explicit Route Object (ERO) where every sub-object is
strict. This allows the head-end to consider IGP-distributed strict. This allows the head-end to consider IGP-distributed
performance data without requiring the ability to signal the performance data without requiring the ability to signal the
performance constraints in an object of the RSVP Path message. performance constraints in an object of the RSVP Path message.
When considering performance-based data, it is obvious that there are When considering performance-based data, it is obvious that there are
additional contributors to latency beyond just the links. Clearly additional contributors to latency beyond just the links. Clearly
end-to-end latency is a combination of router latency (e.g. latency end-to-end latency is a combination of router latency (e.g., latency
from traversing a router without queueing delay), queuing latency, from traversing a router without queueing delay), queuing latency,
physical link latency and other factors. While traversing a router physical link latency, and other factors. While traversing a router
can cause delay, that router latency can be included in the can cause delay, that router latency can be included in the
advertised link delay. As described in [RFC7471] and advertised link delay. As described in [RFC7471] and [RFC7810],
[I-D.ietf-isis-te-metric-extensions], queuing delay must not be queuing delay must not be included in the measurements advertised by
included in the measurements advertised by OSPF or ISIS. OSPF or IS-IS.
Queuing latency is specifically excluded to insure freedom from Queuing latency is specifically excluded to insure freedom from
oscillations and stability issues that have plagued prior attempts to oscillations and stability issues that have plagued prior attempts to
use delay as a routing metric. If application traffic follows a path use delay as a routing metric. If application traffic follows a path
based upon latency constraints, the same traffic might be in an based upon latency constraints, the same traffic might be in an
Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing Expedited Forwarding Per-Hop Behavior (PHB) [RFC3246] with minimal
delay or another PHB with potentially very substantial per-hop queuing delay or another PHB with potentially very substantial per-
queuing delay. Only traffic which experiences relatively low hop queuing delay. Only traffic that experiences relatively low
congestion, such as Expedited Forwarding traffic, will experience congestion, such as Expedited Forwarding traffic, will experience
delays very close to the sum of the reported link delays. delays very close to the sum of the reported link delays.
This document does not specify how a router determines what values to This document does not specify how a router determines what values to
advertise by the IGP; it does assume that the constraints specified advertise by the IGP; it does assume that the constraints specified
in [RFC7471] and [I-D.ietf-isis-te-metric-extensions] are followed. in [RFC7471] and [RFC7810] are followed. Additionally, the end-to-
Additionally, the end-to-end performance that is computed for an LSP end performance that is computed for an LSP path should be built from
path should be built from the individual link data. Any end-to-end the individual link data. Any end-to-end characterization used to
characterization used to determine an LSP's performance compliance determine an LSP's performance compliance should be fully reflected
should be fully reflected in the Traffic Engineering Database so that in the Traffic Engineering Database so that a path calculation can
a path calculation can also determine whether a path under also determine whether a path under consideration would be in
consideration would be in compliance. compliance.
1.1. Basic Requirements 1.1. Basic Requirements
The following are the requirements considered for a path computation The following are the requirements considered for a path computation
function that uses network performance criteria. function that uses network performance criteria.
1. Select a TE tunnel's path based upon a combination of existing 1. Select a TE tunnel's path based upon a combination of existing
constraints as well as on link-latency, packet loss, jitter, link constraints as well as on link-latency, packet loss, jitter,
performance objectives conformance, and bandwidth consumed by conformance with link performance objectives, and bandwidth
non-RSVP-TE traffic. consumed by non-RSVP-TE traffic.
2. Ability to define different end-to-end performance requirements 2. Ability to define different end-to-end performance requirements
for each TE tunnel regardless of common use of resources. for each TE tunnel regardless of common use of resources.
3. Ability to periodically verify with the TE LSDB that a TE 3. Ability to periodically verify with the TE Link State Database
tunnel's current LSP complies with its configured end-to-end (LSDB) that a TE tunnel's current LSP complies with its
performance requirements. configured end-to-end performance requirements.
4. Ability to move tunnels, using make-before-break, based upon 4. Ability to move tunnels, using make-before-break, based upon
computed end-to-end performance complying with constraints. computed end-to-end performance complying with constraints.
5. Ability to move tunnels away from any link that is violating an 5. Ability to move tunnels away from any link that is violating an
underlying link performance objective. underlying link performance objective.
6. Ability to optionally avoid setting up tunnels using any link 6. Ability to optionally avoid setting up tunnels using any link
that is violating a link performance objective, regardless of that is violating a link performance objective, regardless of
whether end-to-end performance would still meet requirements. whether end-to-end performance would still meet requirements.
7. Ability to revert back using make-before-break to the best path 7. Ability to revert back, using make-before-break, to the best path
after a configurable period. after a configurable period.
1.2. Oscillation and Stability Considerations 1.2. Oscillation and Stability Considerations
Past attempts to use unbounded delay or loss as metric sufferred from Past attempts to use unbounded delay or loss as a metric suffered
severe oscillations. The use of performance based data must be such from severe oscillations. The use of performance based data must be
that undampened oscillations are not possible and stability cannot be such that undamped oscillations are not possible and stability cannot
impacted. be impacted.
The use of timers is often cited as a cure. Oscillation that is The use of timers is often cited as a cure. Oscillation that is
damped by timers is known as "slosh". If advertisement timers are damped by timers is known as "slosh". If advertisement timers are
very short relative to the jitter applied to RSVP-TE CSPF timers, very short relative to the jitter applied to RSVP-TE Constrained
then a partial oscillation occurs. If RSVP-TE CSPF timers are short Shortest Path First (CSPF) timers, then a partial oscillation occurs.
relative to advertisement timers, full oscillation (all traffic If RSVP-TE CSPF timers are short relative to advertisement timers,
moving back and forth) can occur. Even a partial oscillation causes full oscillation (all traffic moving back and forth) can occur. Even
unnecessary reordering which is considered at least minimally a partial oscillation causes unnecessary reordering that is
disruptive. considered at least minimally disruptive.
Delay variation or jitter is affected by even small traffic levels. Delay variation or jitter is affected by even small traffic levels.
At even tiny traffic levels, the probability of a queue occupancy of At even tiny traffic levels, the probability of a queue occupancy of
one can produce a measured jitter proportional to or equal to the one can produce a measured jitter proportional to or equal to the
packet serialization delay. Very low levels of traffic can increase packet serialization delay. Very low levels of traffic can increase
the probability of queue occupancies of two or three packets enough the probability of queue occupancies of two or three packets enough
to further increase the measured jitter. Because jitter measurement to further increase the measured jitter. Because jitter measurement
is extremely sensitive to very low traffic levels, any use of jitter is extremely sensitive to very low traffic levels, any use of jitter
is likely to oscillate. However, there may be uses of a jitter is likely to oscillate. However, there may be uses of a jitter
measurement in path computation that can be considered free of measurement in path computation that can be considered free of
oscillation. oscillation.
Delay measurements that are not sensitive to traffic loads may be Delay measurements that are not sensitive to traffic loads may be
safely used in path computation. Delay measurements made at the link safely used in path computation. Delay measurements made at the link
layer or measurements made at a queuing priority higher than any layer or measurements made at a queuing priority higher than any
significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not CS2 significant traffic (such as Differentiated Services Code Point
if traffic levels at CS3 and higher or EF and AF can affect the (DSCP) CS7 or CS6 [RFC4594], but not CS2 if traffic levels at CS3 and
higher or Expedited Forwarding and Assured Forwarding can affect the
measurement). Making delay measurements at the same priority as the measurement). Making delay measurements at the same priority as the
traffic on affected paths is likely to cause oscillations. traffic on affected paths is likely to cause oscillations.
2. Using Performance Data Constraints 2. Using Performance Data Constraints
2.1. End-to-End Constraints 2.1. End-to-End Constraints
The per-link performance data available in the IGP [RFC7471] The per-link performance data available in the IGP [RFC7471]
[I-D.ietf-isis-te-metric-extensions] includes: unidirectional link [RFC7810] includes: unidirectional link delay, unidirectional delay
delay, unidirectional delay variation, and link loss. Each (or all) variation, and link loss. Each (or all) of these parameters can be
of these parameters can be used to create the path-level link-based used to create the path-level link-based parameter.
parameter.
It is possible to compute a CSPF where the link latency values are It is possible to compute a CSPF where the link latency values are
used instead of TE metrics, this results in ignoring the TE metrics used instead of TE metrics; this results in ignoring the TE metrics
and causing LSPs to prefer the lowest-latency paths. In practical and causing LSPs to prefer the lowest-latency paths. In practical
scenarios, latency constraints are typically a bound constraint scenarios, latency constraints are typically a bound constraint
rather than a minimization objective. An end-to-end latency upper rather than a minimization objective. An end-to-end latency upper
bound merely requires that the path computed be no more than that bound merely requires that the path computed be no more than that
bound and does not require that it be the minimum latency path. The bound and does not require that it be the minimum latency path. The
latter is exactly the delay-constrained lowest-cost (DCLC) problem to latter is exactly the DCLC problem to which good heuristics have been
which good heuristics have been proposed in the literature (e.g. proposed in the literature (e.g., [k-Paths_DCLC]).
[k-Paths_DCLC]).
An end-to-end bound on delay variation can be used similarly as a An end-to-end bound on delay variation can be used similarly as a
constraint in the path computation on what links to explore where the constraint in the path computation on what links to explore where the
path's delay variation is the sum of the used links' delay path's delay variation is the sum of the used links' delay
variations. variations.
For link loss, the path loss is not the sum of the used links' For link loss, the path loss is not the sum of the used links'
losses. Instead, the path loss fraction is 1 - (1 - loss_L1)*(1 - losses. Instead, the path loss fraction is 1 - (1 - loss_L1)*
loss_L2)*...*(1 - loss_Ln), where the links along the path are L1 to (1 - loss_L2)*...*(1 - loss_Ln), where the links along the path are
Ln with loss_Li in fractions. This computation is discussed in more L1 to Ln with loss_Li in fractions. This computation is discussed in
detail in Sections 5.1.4 and 5.1.5 in [RFC6049]. The end-to-end link more detail in Sections 5.1.4 and 5.1.5 in [RFC6049]. The end-to-end
loss bound, computed in this fashion, can also be used as a link loss bound, computed in this fashion, can also be used as a
constraint in the path computation. constraint in the path computation.
The heuristic algorithms for DCLC only address one constraint bound The heuristic algorithms for DCLC only address one constraint bound
but having a CSPF that limits the paths explored (i.e. based on hop- but having a CSPF that limits the paths explored (i.e., based on hop
count) can be combined [hop-count_DCLC]. count) can be combined [hop-count_DCLC].
2.2. Link Constraints 2.2. Link Constraints
In addition to selecting paths that conform to a bound on performance In addition to selecting paths that conform to a bound on performance
data, it is also useful to avoid using links that do not meet a data, it is also useful to avoid using links that do not meet a
necessary constraint. Naturally, if such a parameter were a known necessary constraint. Naturally, if such a parameter were a known
fixed value, then resource attribute flags could be used to express fixed value, then resource attribute flags could be used to express
this behavior. However, when the parameter associated with a link this behavior. However, when the parameter associated with a link
may vary dynamically, there is not currently a configuration-time may vary dynamically, there is not currently a configuration-time
mechanism to enforce such behavior. An example of this is described mechanism to enforce such behavior. An example of this is described
in Section 2.3, where links may move in and out of conformance for in Section 2.3, where links may move in and out of conformance for
link performance objectives with regards to latency, delay variation, link performance objectives with regards to latency, delay variation,
and link loss. and link loss.
When doing path selection for TE tunnels, it has not been possible to When doing path selection for TE tunnels, it has not been possible to
know how much actual bandwidth is available that includes the know how much actual bandwidth is available that includes the
bandwidth used by non-RSVP-TE traffic. In [RFC7471] bandwidth used by non-RSVP-TE traffic. In [RFC7471] and [RFC7810],
[I-D.ietf-isis-te-metric-extensions], the Unidirectional Available the Unidirectional Available Bandwidth is advertised as is the
Bandwidth is advertised as is the Residual Bandwidth. When computing Residual Bandwidth. When computing the path for a TE tunnel, only
the path for a TE tunnel, only links with at least a minimum amount links with at least a minimum amount of Unidirectional Available
of Unidirectional Available Bandwidth might be permitted. Bandwidth might be permitted.
Similarly, only links whose loss is under a configurable value might Similarly, only links whose loss is under a configurable value might
be acceptable. For these constraints, each link can be tested be acceptable. For these constraints, each link can be tested
against the constraint and only explored in the path computation if against the constraint and only explored in the path computation if
the link passes. In essence, a link that fails the constraint test the link passes. In essence, a link that fails the constraint test
is treated as if it contained a resource attribute in the exclude-any is treated as if it contained a resource attribute in the exclude-any
filter. filter.
2.3. Links out of compliance with Link Performance Objectives 2.3. Links out of Compliance with Link Performance Objectives
Link conformance to a link performance objective can change as a Link conformance to a link performance objective can change as a
result of rerouting at lower layers. This could be due to optical result of rerouting at lower layers. This could be due to optical
regrooming or simply rerouting of a FA-LSP. When this occurs, there regrooming or simply rerouting of an FA-LSP. When this occurs, there
are two questions to be asked: are two questions to be asked:
a. Should the link be trusted and used for the setup of new LSPs? a. Should the link be trusted and used for the setup of new LSPs?
b. Should LSPs using this link automatically be moved to a secondary b. Should LSPs using this link automatically be moved to a secondary
path? path?
2.3.1. Use of Anomalous Links for New Paths 2.3.1. Use of Anomalous Links for New Paths
If the answer to (a) is no for link latency performance objectives, If the answer to (a) is no for link latency performance objectives,
then any link which has the Anomalous bit set in the Unidirectional then any link that has the Anomalous bit set in the Unidirectional
Link Delay sub-TLV[RFC7471] [I-D.ietf-isis-te-metric-extensions] Link Delay sub-TLV [RFC7471] [RFC7810] should be removed from the
should be removed from the topology before a path calculation is used topology before a path calculation is used to compute a new path. In
to compute a new path. In essence, the link should be treated essence, the link should be treated exactly as if it fails the
exactly as if it fails the exclude-any resource attributes exclude-any resource attributes filter [RFC3209].
filter.[RFC3209].
Similarly, if the answer to (a) is no for link loss performance Similarly, if the answer to (a) is no for link loss performance
objectives, then any link which has the Anomalous bit set in the Link objectives, then any link that has the Anomalous bit set in the Link
Loss sub-TLV should be treated as if it fails the exclude-any Loss sub-TLV should be treated as if it fails the exclude-any
resource attributes filter. resource attributes filter.
2.3.2. Links entering the Anomalous State 2.3.2. Links Entering the Anomalous State
When the Anomalous bit transitions from clear to set, this indicates When the Anomalous bit transitions from clear to set, this indicates
that the associated link has entered the Anomalous state with respect that the associated link has entered the Anomalous state with respect
to the associated parameter; similarly, a transition from set to to the associated parameter; similarly, a transition from set to
clear indicates that the Anomalous state has been exited for that clear indicates that the Anomalous state has been exited for that
link and associated parameter. link and associated parameter.
When a link enters the Anomalous state with respect to a parameter, When a link enters the Anomalous state with respect to a parameter,
this is an indication that LSPs using that link might also no longer this is an indication that LSPs using that link might also no longer
be in compliance with their performance bounds. It can also be be in compliance with their performance bounds. It can also be
considered an indication that something is changing that link and so considered an indication that something is changing that link and so
it might no longer be trustworthy to carry performance-critical it might no longer be trustworthy to carry performance-critical
traffic. Naturally, which performance criteria are important for a traffic. Naturally, which performance criteria are important for a
particular LSP is dependent upon the LSP's configuration and thus the particular LSP is dependent upon the LSP's configuration; thus, the
compliance of a link with respect to a particular link performance compliance of a link with respect to a particular link performance
objective is indicated per performance criterion. objective is indicated per performance criterion.
At the ingress of a TE tunnel, a TE tunnel may be configured to be At the ingress of a TE tunnel, a TE tunnel may be configured to be
sensitive to the Anomalous state of links in reference to latency, sensitive to the Anomalous state of links in reference to latency,
delay variation, and/or loss. Additionally, such a TE tunnel may be delay variation, and/or loss. Additionally, such a TE tunnel may be
configured to either verify continued compliance, to switch configured to either verify continued compliance, to switch
immediately to a standby LSP, or to move to a different path. immediately to a standby LSP, or to move to a different path.
When a sub-TLV is received with the Anomalous bit set when previously When a sub-TLV is received with the Anomalous bit set when previously
it was clear, the list of interested TE tunnels must be scanned. it was clear, the list of interested TE tunnels must be scanned.
Each such TE tunnel should either have its continued compliance Each such TE tunnel should have its continued compliance verified, be
verified, be switched to a hot standby, or do a make-before-break to switched to a hot standby, or do a make-before-break to a secondary
a secondary path. path.
It is not sufficient to just look at the Anomalous bit in order to It is not sufficient to just look at the Anomalous bit in order to
determine when TE tunnels must have their compliance verified. When determine when TE tunnels must have their compliance verified. When
changing to set, the Anomalous bit merely provides a hint that changing to set, the Anomalous bit merely provides a hint that
interested TE tunnels should have their continued compliance interested TE tunnels should have their continued compliance
verified. verified.
2.3.3. Links leaving the Anomalous State 2.3.3. Links Leaving the Anomalous State
When a link leaves the Anomalous state with respect to a parameter, When a link leaves the Anomalous state with respect to a parameter,
this can serve as an indication that those TE tunnels, whose LSPs this can serve as an indication that those TE tunnels, whose LSPs
were changed due to administrative policy when the link entered the were changed due to administrative policy when the link entered the
Anomalous state, may want to reoptimize to a better path. The hint Anomalous state, may want to reoptimize to a better path. The hint
provided by the Anomalous state change may help optimize when to provided by the Anomalous state change may help optimize when to
recompute for a better path. recompute for a better path.
3. IANA Considerations 3. Security Considerations
This document includes no request to IANA.
4. Security Considerations
This document is not currently believed to introduce new security This document is not currently believed to introduce new security
concerns. concerns.
5. Contributors 4. References
Dave Ward and Clarence Filsfils contributed to this document.
6. Acknowledgements
The authors would like to thank Curtis Villamizar for his extensive
detailed comments and suggested text in the Section 1 and
Section 1.2. The authors would like to thank Dhruv Dhody for his
useful comments, and his care and persistence in making sure that
these important corrections weren't missed. The authors would also
like to thank Xiaohu Xu and Sriganesh Kini for their review.
7. References
7.1. Normative References
[I-D.ietf-isis-te-metric-extensions] 4.1. Normative References
Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,
A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering
(TE) Metric Extensions", draft-ietf-isis-te-metric-
extensions-07 (work in progress), June 2015.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <http://www.rfc-editor.org/info/rfc3209>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<http://www.rfc-editor.org/info/rfc7471>. <http://www.rfc-editor.org/info/rfc7471>.
7.2. Informative References [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/7810, May 2016,
<http://www.rfc-editor.org/info/rfc7810>.
4.2. Informative References
[hop-count_DCLC] [hop-count_DCLC]
Agrawal, H., Grah, M., and M. Gregory, "Optimization of Agrawal, H., Grah, M., and M. Gregory, "Optimization of
QoS Routing", 6th IEEE/AACIS International Conference on QoS Routing", 6th IEEE/AACIS International Conference on
Computer and Information Science 2007, 2007, Computer and Information Science,
DOI 10.1109/ICIS.2007.144, July 2007,
<http://ieeexplore.ieee.org/xpl/ <http://ieeexplore.ieee.org/xpl/
articleDetails.jsp?arnumber=4276447>. articleDetails.jsp?arnumber=4276447>.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing with MPLS data plane",
draft-ietf-spring-segment-routing-mpls-01 (work in
progress), May 2015.
[k-Paths_DCLC] [k-Paths_DCLC]
Jia, Z. and P. Varaiya, "Heuristic methods for delay Jia, Z. and P. Varaiya, "Heuristic methods for delay
constrained least cost routing using k-shortest-paths", constrained least cost routing using k-shortest-paths",
IEEE Transactions on Automatic Control 51(4), 2006, IEEE Transactions on Automatic Control, vol. 51, no. 4,
<http://paleale.eecs.berkeley.edu/~varaiya/papers_ps.dir/ April 2006, <http://dx.doi.org/10.1109/TAC.2006.872827>.
kdclc-ieeev4.pdf>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>. <http://www.rfc-editor.org/info/rfc3246>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
10.17487/RFC3473, January 2003, DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>. <http://www.rfc-editor.org/info/rfc3473>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, DOI Guidelines for DiffServ Service Classes", RFC 4594,
10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>. <http://www.rfc-editor.org/info/rfc4594>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/ Element (PCE)-Based Architecture", RFC 4655,
RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <http://www.rfc-editor.org/info/rfc4655>.
[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of
Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011,
<http://www.rfc-editor.org/info/rfc6049>. <http://www.rfc-editor.org/info/rfc6049>.
[SEG-ROUTE-MPLS]
Filsfils, C., Ed., Previdi, S., Ed., Bashandy, A.,
Decraene, B., Litkowski, S., Horneffer, M., Shakir, R.,
Tantsura, J., and E. Crabbe, "Segment Routing with MPLS
data plane", Work in Progress, draft-ietf-spring-segment-
routing-mpls-04, March 2016.
Acknowledgements
The authors would like to thank Curtis Villamizar for his extensive
detailed comments and suggested text in Sections 1 and 1.2. The
authors would like to thank Dhruv Dhody for his useful comments and
his care and persistence in making sure that these important
corrections weren't missed. The authors would also like to thank
Xiaohu Xu and Sriganesh Kini for their reviews.
Contributors
Dave Ward and Clarence Filsfils contributed to this document.
Authors' Addresses Authors' Addresses
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA United States
Email: akatlas@juniper.net Email: akatlas@juniper.net
John Drake John Drake
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA United States
Email: jdrake@juniper.net Email: jdrake@juniper.net
Spencer Giacalone Spencer Giacalone
Unaffiliated Microsoft
Email: spencer.giacalone@gmail.com Email: spencer.giacalone@gmail.com
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
Via Del Serafico 200 Via Del Serafico 200
Rome 00142 Rome 00142
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
 End of changes. 52 change blocks. 
172 lines changed or deleted 161 lines changed or added

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