draft-ietf-teas-sr-rsvp-coexistence-rec-04.txt   rfc8426.txt 
TEAS Working Group H. Sitaraman, Ed. Internet Engineering Task Force (IETF) H. Sitaraman, Ed.
Internet-Draft V. Beeram Request for Comments: 8426 V. Beeram
Intended status: Informational Juniper Networks Category: Informational Juniper Networks
Expires: November 17, 2018 I. Minei ISSN: 2070-1721 I. Minei
Google, Inc. Google, Inc.
S. Sivabalan S. Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
May 16, 2018 July 2018
Recommendations for RSVP-TE and Segment Routing LSP co-existence Recommendations for RSVP-TE and Segment Routing (SR)
draft-ietf-teas-sr-rsvp-coexistence-rec-04.txt Label Switched Path (LSP) Coexistence
Abstract Abstract
Operators are looking to introduce services over Segment Routing (SR) Operators are looking to introduce services over Segment Routing (SR)
LSPs in networks running Resource Reservation Protocol (RSVP-TE) Label Switched Paths (LSPs) in networks running Resource Reservation
LSPs. In some instances, operators are also migrating existing Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances,
services from RSVP-TE to SR LSPs. For example, there might be operators are also migrating existing services from RSVP-TE to SR
certain services that are well suited for SR and need to co-exist LSPs. For example, there might be certain services that are well
with RSVP-TE in the same network. Such introduction or migration of suited for SR and need to coexist with RSVP-TE in the same network.
traffic to SR might require co-existence with RSVP-TE in the same Such introduction or migration of traffic to SR might require
network for an extended period of time depending on the operator's coexistence with RSVP-TE in the same network for an extended period
intent. The following document provides solution options for keeping of time, depending on the operator's intent. The following document
the traffic engineering database consistent across the network, provides solution options for keeping the traffic engineering
accounting for the different bandwidth utilization between SR and database consistent across the network, accounting for the different
RSVP-TE. bandwidth utilization between SR and RSVP-TE.
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 https://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 candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on November 17, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8426.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Solution options . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Options . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Static partitioning of bandwidth . . . . . . . . . . . . 4 3.1. Static Partitioning of Bandwidth . . . . . . . . . . . . 4
3.2. Centralized management of available capacity . . . . . . 4 3.2. Centralized Management of Available Capacity . . . . . . 4
3.3. Flooding SR utilization in IGP . . . . . . . . . . . . . 4 3.3. Flooding SR Utilization in IGP . . . . . . . . . . . . . 5
3.4. Running SR over RSVP-TE . . . . . . . . . . . . . . . . . 5 3.4. Running SR over RSVP-TE . . . . . . . . . . . . . . . . . 5
3.5. TED consistency by reflecting SR traffic . . . . . . . . 5 3.5. TED Consistency by Reflecting SR Traffic . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Multiplier Value Range . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Multiplier value range . . . . . . . . . . . . . . . 11 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Introduction of SR [I-D.ietf-spring-segment-routing] in the same Introduction of SR [RFC8402] in the same network domain as RSVP-TE
network domain as RSVP-TE [RFC3209] presents the problem of [RFC3209] presents the problem of accounting for SR traffic and
accounting for SR traffic and making RSVP-TE aware of the actual making RSVP-TE aware of the actual available bandwidth on the network
available bandwidth on the network links. RSVP-TE is not aware of links. RSVP-TE is not aware of how much bandwidth is being consumed
how much bandwidth is being consumed by SR services on the network by SR services on the network links; hence, both at computation time
links and hence both at computation time (for a distributed (for a distributed computation) and at signaling time, RSVP-TE LSPs
computation) and at signaling time RSVP-TE LSPs will incorrectly will incorrectly place loads. This is true where RSVP-TE paths are
place loads. This is true where RSVP-TE paths are distributed or distributed or centrally computed without a common entity managing
centrally computed without a common entity managing both SR and RSVP- both SR and RSVP-TE computation for the entire network domain.
TE computation for the entire network domain.
The problem space can be generalized as a dark bandwidth problem to The problem space can be generalized as a dark bandwidth problem to
cases where any other service exists in the network that runs in cases where any other service exists in the network that runs in
parallel across common links and whose bandwidth is not reflected in parallel across common links and whose bandwidth is not reflected in
the available and reserved values in the traffic engineering database the available and reserved values in the Traffic Engineering Database
(TED). In most practical instances given the static nature of the (TED). In most practical instances, given the static nature of the
traffic demands, limiting the available reservable bandwidth traffic demands, limiting the reservable bandwidth available to RSVP-
available to RSVP-TE has been an acceptable solution. However, in TE has been an acceptable solution. However, in the case of SR
the case of SR traffic, there is assumed to be very dynamic traffic traffic, there is assumed to be very dynamic traffic demands, and
demands and there is considerable risk associated with stranding there is considerable risk associated with stranding capacity or
capacity or overbooking service traffic resulting in traffic drops. overbooking service traffic resulting in traffic drops.
The high level requirements to consider are: The high-level requirements to consider are:
1. Placement of SR LSPs in the same domain as RSVP-TE LSPs must not 1. Placement of SR LSPs in the same domain as RSVP-TE LSPs must not
introduce inaccuracies in the TED used by distributed or introduce inaccuracies in the TED used by distributed or
centralized path computation engines. centralized path computation engines.
2. Engines that compute RSVP-TE paths may have no knowledge of the 2. Engines that compute RSVP-TE paths may have no knowledge of the
existence of the SR paths in the same domain. existence of the SR paths in the same domain.
3. Engines that compute RSVP-TE paths should not require a software 3. Engines that compute RSVP-TE paths should not require a software
upgrade or change to their path computation logic. upgrade or change to their path-computation logic.
4. Protocol extensions should be avoided or be minimal as in many 4. Protocol extensions should be avoided or be minimal as, in many
cases this co-existence of RSVP-TE and SR may be needed only cases, this coexistence of RSVP-TE and SR may be needed only
during a transition phase. during a transition phase.
5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are 5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are
computed in a distributed fashion must not require migration to a computed in a distributed fashion must not require migration to a
central controller architecture for the RSVP-TE LSPs. central controller architecture for the RSVP-TE LSPs.
2. Conventions used in this document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Solution options 3. Solution Options
The following section lists SR and RSVP co-existence solution The following section lists SR and RSVP coexistence solution options.
options. A specific solution is not recommended as all solutions are A specific solution is not recommended as all solutions are valid,
valid even though some may not satisfy all the requirements. If a even though some may not satisfy all the requirements. If a solution
solution is acceptable for an operator based on their deployment is acceptable for an operator based on their deployment model, then
model then such a solution can be chosen. such a solution can be chosen.
3.1. Static partitioning of bandwidth 3.1. Static Partitioning of Bandwidth
In this model, the static reservable bandwidth of an interface can be In this model, the static reservable bandwidth of an interface can be
statically partitioned between SR and RSVP-TE and each can operate statically partitioned between SR and RSVP-TE; each one can operate
within that bandwidth allocation and SHOULD NOT preempt each other. within that bandwidth allocation and SHOULD NOT preempt the other.
While it is possible to configure RSVP-TE to only reserve up to a While it is possible to configure RSVP-TE to only reserve up to a
certain maximum link bandwidth and manage the remaining link certain maximum link bandwidth and manage the remaining link
bandwidth for other services, this is a deployment where SR and RSVP- bandwidth for other services, this is a deployment where SR and RSVP-
TE are separated in the same network (ships in the night) and can TE are separated in the same network (ships in the night) and can
lead to suboptimal link bandwidth utilization not allowing each to lead to suboptimal link bandwidth utilization not allowing each to
consume more, if required and constraining the respective consume more, if required and constraining the respective
deployments. deployments.
The downside of this approach is the inability to use the reservable The downside of this approach is the inability to use the reservable
bandwidth effectively and inability to use bandwidth left unused by bandwidth effectively and the inability to use bandwidth left unused
the other protocol. by the other protocol.
3.2. Centralized management of available capacity 3.2. Centralized Management of Available Capacity
In this model, a central controller performs path placement for both In this model, a central controller performs path placement for both
RSVP-TE and SR LSPs. The controller manages and updates its own view RSVP-TE and SR LSPs. The controller manages and updates its own view
of the in-use and the available capacity. As the controller is a of the in-use and available capacity. As the controller is a single
single common entity managing the network it can have a unified and common entity managing the network it can have a unified and
consistent view of the available capacity at all times. consistent view of the available capacity at all times.
A practical drawback of this model is that it requires the A practical drawback of this model is that it requires the
introduction of a central controller managing the RSVP-TE LSPs as a introduction of a central controller managing the RSVP-TE LSPs as a
prerequisite to the deployment of any SR LSPs. Therefore, this prerequisite to the deployment of any SR LSPs. Therefore, this
approach is not practical for networks where distributed TE with approach is not practical for networks where distributed TE with
RSVP-TE LSPs is already deployed, as it requires a redesign of the RSVP-TE LSPs is already deployed, as it requires a redesign of the
network and is not backwards compatible. This does not satisfy network and is not backwards compatible. This does not satisfy
requirement 5. requirement 5.
Note that it is not enough for the controller to just maintain the Note that it is not enough for the controller to just maintain the
unified view of the available capacity, it must also perform the path unified view of the available capacity, it must also perform the path
computation for the RSVP-TE LSPs, as the reservations for the SR LSPs computation for the RSVP-TE LSPs, as the reservations for the SR LSPs
are not reflected in the TED. are not reflected in the TED.
3.3. Flooding SR utilization in IGP 3.3. Flooding SR Utilization in IGP
Using techniques in [RFC7810], [RFC7471] and [RFC7823], the SR Using techniques in [RFC7810], [RFC7471], and [RFC7823], the SR
utilization information can be flooded in IGP-TE and the RSVP-TE path utilization information can be flooded in IGP-TE, and the RSVP-TE
computation engine (CSPF) can be changed to consider this path computation engine (Constrained Shortest Path First (CSPF)) can
information. This requires changes to the RSVP-TE path computation be changed to consider this information. This requires changes to
logic and would require upgrades in deployments where distributed the RSVP-TE path computation logic and would require upgrades in
computation is done across the network. deployments where distributed computation is done across the network.
This does not fit with requirements 3 and 4 mentioned earlier. This does not fit with requirements 3 and 4 mentioned earlier.
3.4. Running SR over RSVP-TE 3.4. Running SR over RSVP-TE
SR can run over dedicated RSVP-TE LSPs that carry only SR traffic. SR can run over dedicated RSVP-TE LSPs that carry only SR traffic.
In this model, the LSPs can be one-hop or multi-hop and can provide In this model, the LSPs can be one-hop or multi-hop and can provide
bandwidth reservation for the SR traffic based on functionality such bandwidth reservation for the SR traffic based on functionality such
as auto-bandwidth. The model of deployment would be similar in as auto-bandwidth. The model of deployment would be similar in
nature to running LDP over RSVP-TE. This would allow the TED to stay nature to running LDP over RSVP-TE. This would allow the TED to stay
consistent across the network and any other RSVP-TE LSPs will also be consistent across the network and any other RSVP-TE LSPs will also be
aware of the SR traffic reservations. In this approach, non-SR aware of the SR traffic reservations. In this approach, non-SR
traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless required traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless required
by policy. by policy.
The drawback of this solution is that it requires SR to rely on RSVP- The drawback of this solution is that it requires SR to rely on RSVP-
TE for deployment. Furthermore, the accounting accuracy/frequency of TE for deployment. Furthermore, the accounting accuracy/frequency of
this method is dependent on performance of auto-bandwidth for RSVP- this method is dependent on performance of auto-bandwidth for RSVP-
TE. Note that for this method to work, the SR-dedicated RSVP-TE LSPs TE. Note that, for this method to work, the SR-dedicated RSVP-TE
must be set up with the best setup and hold priorities in the LSPs must be set up with the best setup and hold priorities in the
network. network.
3.5. TED consistency by reflecting SR traffic 3.5. TED Consistency by Reflecting SR Traffic
The solution relies on dynamically measuring SR traffic utilization The solution relies on dynamically measuring SR traffic utilization
on each TE interface and reducing the bandwidth allowed for use by on each TE interface and reducing the bandwidth allowed for use by
RSVP-TE. It is assumed that SR traffic receives precedence in terms RSVP-TE. It is assumed that SR traffic receives precedence in terms
of the placement on the path over RSVP traffic (that is, RSVP traffic of the placement on the path over RSVP traffic (that is, RSVP traffic
can be preempted from the path in case of insufficient resources). can be preempted from the path in case of insufficient resources).
This is logically equivalent to SR traffic having the best preemption This is logically equivalent to SR traffic having the best preemption
priority in the network. Note that this does not necessarily mean priority in the network. Note that this does not necessarily mean
that SR traffic has higher QoS priority, in fact, SR and RSVP traffic that SR traffic has higher QoS priority; in fact, SR and RSVP traffic
may be in the same QoS class. may be in the same QoS class.
Reducing the bandwidth allowed for use by RSVP-TE can be explored Reducing the bandwidth allowed for use by RSVP-TE can be explored
using the three parameters available in IGP-TE ([RFC5305],[RFC3630]), using the three parameters available in IGP-TE ([RFC5305] [RFC3630]),
namely Maximum-Link-Bandwidth, Maximum-Reservable-Bandwidth and namely Maximum-Link-Bandwidth, Maximum-Reservable-Bandwidth, and
Unreserved-Bandwidth. Unreserved-Bandwidth.
o Maximum-Link-Bandwidth: This parameter can be adjusted to o Maximum-Link-Bandwidth: This parameter can be adjusted to
accommodate the bandwidth required for SR traffic with cascading accommodate the bandwidth required for SR traffic with cascading
impacts on Maximum-Reservable-Bandwidth and Unreserved-Bandwidth. impacts on Maximum-Reservable-Bandwidth and Unreserved-Bandwidth.
However, changing the maximum bandwidth for the TE link will However, changing the maximum bandwidth for the TE link will
prevent any compute engine for SR or RSVP from determining the prevent any compute engine for SR or RSVP from determining the
real static bandwidth of the TE link. Further, when the Maximum- real static bandwidth of the TE link. Further, when the Maximum-
Reservable-Bandwidth is derived from the Maximum-Link-Bandwidth, Reservable-Bandwidth is derived from the Maximum-Link-Bandwidth,
its definition changes since Maximum-Link-Bandwidth will account its definition changes since Maximum-Link-Bandwidth will account
skipping to change at page 6, line 19 skipping to change at page 6, line 34
overloading IGP-TE advertisements to directly reflect both RSVP-TE overloading IGP-TE advertisements to directly reflect both RSVP-TE
bandwidth bookings and SR bandwidth measurements. bandwidth bookings and SR bandwidth measurements.
o Maximum-Reservable-Bandwidth: As the preferred option, SR traffic o Maximum-Reservable-Bandwidth: As the preferred option, SR traffic
could adjust the Maximum-Reservable-Bandwidth, with cascading could adjust the Maximum-Reservable-Bandwidth, with cascading
impact on the Unreserved-Bandwidth. impact on the Unreserved-Bandwidth.
The following methodology can be used at every TE node for this The following methodology can be used at every TE node for this
solution, using the following parameters: solution, using the following parameters:
o T: Traffic statistics collection time interval o T: Traffic statistics collection time interval.
o k: The number of traffic statistics samples that can provide a o k: The number of traffic statistics samples that can provide a
smoothing function to the statistics collection. The value of k smoothing function to the statistics collection. The value of k
is a constant integer multiplier greater or equal to 1. is a constant integer multiplier greater or equal to 1.
o N: Traffic averaging calculation (adjustment) interval such that N o N: Traffic averaging calculation (adjustment) interval such that N
= k * T = k * T.
o Maximum-Reservable-Bandwidth: The maximum available bandwidth for o Maximum-Reservable-Bandwidth: The maximum available bandwidth for
RSVP-TE. RSVP-TE.
If Differentiated-Service (Diffserv)-aware MPLS Traffic o If Diffserv-aware MPLS Traffic Engineering (DS-TE) [RFC4124] is
Engineering (DS-TE) [RFC4124] is enabled, the Maximum-Reservable- enabled, the Maximum-Reservable-Bandwidth SHOULD be interpreted as
Bandwidth SHOULD be interpreted as the aggregate bandwidth the aggregate bandwidth constraint across all Class-Types
constraint across all Class-Types independent of the Bandwidth independent of the Bandwidth Constraints model.
Constraints model.
o Initial Maximum-Reservable-Bandwidth: The Maximum-reservable- o Initial Maximum-Reservable-Bandwidth: The Maximum-reservable-
bandwidth for TE when no SR traffic or RSVP-TE reservations exist bandwidth for TE when no SR traffic or RSVP-TE reservations exist
on the interface. on the interface.
o RSVP-unreserved-bandwidth-at-priority-X: Maximum-Reservable- o RSVP-unreserved-bandwidth-at-priority-X: Maximum-Reservable-
Bandwidth - sum of (existing reservations at priority X and all Bandwidth - sum of (existing reservations at priority X and all
priorities better than X) priorities better than X).
o SR traffic threshold percentage: The percentage difference of o SR traffic threshold percentage: The percentage difference of
traffic demand that when exceeded can result in a change to the traffic demand that, when exceeded, can result in a change to the
RSVP-TE Maximum-Reservable-Bandwidth RSVP-TE Maximum-Reservable-Bandwidth.
o IGP-TE update threshold: Specifies the frequency at which IGP-TE o IGP-TE update threshold: Specifies the frequency at which IGP-TE
updates should be triggered based on TE bandwidth updates on a updates should be triggered based on TE bandwidth updates on a
link link.
o M: An optional multiplier that can be applied to the SR traffic o M: An optional multiplier that can be applied to the SR traffic
average. This multiplier provides the ability to grow or shrink average. This multiplier provides the ability to grow or shrink
the bandwidth used by SR. Appendix A offers further guidance on the bandwidth used by SR. Appendix A offers further guidance on
M. M.
At every interval T, each node SHOULD collect the SR traffic At every interval T, each node SHOULD collect the SR traffic
statistics for each of its TE interfaces. The measured SR traffic statistics for each of its TE interfaces. The measured SR traffic
includes all labelled SR traffic and any traffic entering the SR includes all labeled SR traffic and any traffic entering the SR
network over that TE interface. Further, at every interval N, given network over that TE interface. Further, at every interval N, given
a configured SR traffic threshold percentage and a set of collected a configured SR traffic threshold percentage and a set of collected
SR traffic statistics samples across the interval N, the SR traffic SR traffic statistics samples across the interval N, the SR traffic
average (or any other traffic metric depending on the algorithm used) average (or any other traffic metric depending on the algorithm used)
over this period is calculated. This method of sampling traffic over this period is calculated. This method of sampling traffic
statistics and adjusting bandwidth reservation accordingly is similar statistics and adjusting bandwidth reservation accordingly is similar
to how bandwidth gets adjusted for auto-bandwidth RSVP-TE LSPs. to how bandwidth gets adjusted for auto-bandwidth RSVP-TE LSPs.
If the difference between the new calculated SR traffic average and If the difference between the new calculated SR traffic average and
the current SR traffic average (that was computed in the prior the current SR traffic average (that was computed in the prior
adjustment) is at least SR traffic threshold percentage, then two adjustment) is at least SR traffic threshold percentage, then two
values MUST be updated: values MUST be updated:
o New Maximum-Reservable-Bandwidth = Initial Maximum-Reservable- o New Maximum-Reservable-Bandwidth = Initial Maximum-Reservable-
Bandwidth - (new SR traffic average * M) Bandwidth - (new SR traffic average * M)
o New RSVP-unreserved-bandwidth-at-priority-X = New Maximum- o New RSVP-unreserved-bandwidth-at-priority-X = New Maximum-
Reservable-Bandwidth - sum of (existing reservations at priority X Reservable-Bandwidth - sum of (existing reservations at priority X
and all priorities better than X) and all priorities better than X)
A DS-TE LSR that advertises Bandwidth Constraints TLV should update A DS-TE LSR that advertises a Bandwidth Constraints TLV should update
the bandwidth constraints for class-types based on operator policy. the bandwidth constraints for class-types based on operator policy.
For example, when Russian Dolls Model (RDM) [RFC4127] is in use, then For example, when Russian Dolls Model (RDM) [RFC4127] is in use, then
only BC0 may be updated. Whereas, when Maximum Allocation Model only BC0 may be updated. Whereas, when Maximum Allocation Model
(MAM) [RFC4125] is in use, then all BCs may be updated equally such (MAM) [RFC4125] is in use, then all Bandwidth Constraints (BCs) may
that the total value updated is equal to the newly calculated SR be updated equally such that the total value updated is equal to the
traffic average. newly calculated SR traffic average.
Note that the computation of the new RSVP-unreserved-bandwidth-at- Note that the computation of the new RSVP-unreserved-bandwidth-at-
priority-X MAY result in RSVP-TE LSPs being hard or soft preempted. priority-X MAY result in RSVP-TE LSPs being hard or soft preempted.
Such preemption will be based on relative priority (e.g. low to high) Such preemption will be based on relative priority (e.g., low to
between RSVP-TE LSPs. The IGP-TE update threshold SHOULD allow for high) between RSVP-TE LSPs. The IGP-TE update threshold SHOULD allow
more frequent flooding of unreserved bandwidth. From an operational for more frequent flooding of unreserved bandwidth. From an
point of view, an implementation SHOULD be able to expose both the operational point of view, an implementation SHOULD be able to expose
configured and the actual values of the Maximum-Reservable-Bandwidth. both the configured and the actual values of the Maximum-Reservable-
Bandwidth.
If LSP preemption is not acceptable, then the RSVP-TE Maximum- If LSP preemption is not acceptable, then the RSVP-TE Maximum-
Reservable-Bandwidth cannot be reduced below what is currently Reservable-Bandwidth cannot be reduced below what is currently
reserved by RSVP-TE on that interface. This may result in bandwidth reserved by RSVP-TE on that interface. This may result in bandwidth
not being available for SR traffic. Thus, it is required that any not being available for SR traffic. Thus, it is required that any
external controller managing SR LSPs SHOULD be able to detect this external controller managing SR LSPs SHOULD be able to detect this
situation (for example by subscribing to TED updates [RFC7752]) and situation (for example, by subscribing to TED updates [RFC7752]) and
SHOULD take action to reroute existing SR paths. SHOULD take action to reroute existing SR paths.
Generically, SR traffic (or any non-RSVP-TE traffic) should have its Generically, SR traffic (or any non-RSVP-TE traffic) should have its
own priority allocated from the available priorities. This would own priority allocated from the available priorities. This would
allow SR to preempt other traffic according to the preemption allow SR to preempt other traffic according to the preemption
priority order. priority order.
In this solution, the logic to retrieve the statistics, calculating In this solution, the logic to retrieve the statistics, calculating
averages and taking action to change the Maximum-Reservable-Bandwidth averages and taking action to change the Maximum-Reservable-Bandwidth
is an implementation choice, and all changes are local in nature. is an implementation choice, and all changes are local in nature.
However, note that this is a new network trigger for RSVP-TE However, note that this is a new network trigger for RSVP-TE
preemption and thus is a consideration for the operator. preemption and thus is a consideration for the operator.
The above solution offers the advantage of not introducing new The above solution offers the advantage of not introducing new
network-wide mechanisms especially during scenarios of migrating to network-wide mechanisms especially during scenarios of migrating to
SR in an existing RSVP-TE network and reusing existing protocol SR in an existing RSVP-TE network and reusing existing protocol
mechanisms. mechanisms.
4. Acknowledgements 4. IANA Considerations
The authors would like to thank Steve Ulrich for his detailed review
and comments.
5. Contributors
The following individuals contributed to this document:
Chandra Ramachandran
Juniper Networks
Email: csekar@juniper.net
Raveendra Torvi
Juniper Networks
Email: rtorvi@juniper.net
Sudharsana Venkataraman
Juniper Networks
Email: sudharsana@juniper.net
Martin Vigoureux
Nokia
Email: martin.vigoureux@nokia.com
6. IANA Considerations
This draft does not have any request for IANA.
7. Security Considerations This document has no IANA actions.
This document describes solution options for the co-existence of 5. Security Considerations
RSVP-TE and SR LSPs in the same administrative domain. The security
considerations for SR are described in
[I-D.ietf-spring-segment-routing]. The security considerations
pertaining to RSVP-TE are described in [RFC5920]. The security
considerations of each architecture are typically unaffected by the
presence of the other. However, when RSVP-TE and SR LSPs co-exist,
it is possible for a hijacked SR traffic stream to maliciously
consume sufficient bandwidth and cause disruption to RSVP-TE LSPs.
With the solution option specified in Section 3.5, the impact to
RSVP-TE traffic can be controlled and paths re-routed. Some latent
risk of disruption still remains because this solution option relies
on taking statistics samples and adopting to new traffic flows only
after the adjustment period. The defensive mechanisms described in
the base SR security framework should be employed to guard against
situations that result in SR traffic hijacking or denial of service.
8. References This document describes solution options for the coexistence of RSVP-
TE and SR LSPs in the same administrative domain. The security
considerations for SR are described in [RFC8402]. The security
considerations pertaining to RSVP-TE are described in [RFC5920]. The
security considerations of each architecture are typically unaffected
by the presence of the other. However, when RSVP-TE and SR LSPs
coexist, it is possible for a hijacked SR traffic stream to
maliciously consume sufficient bandwidth and cause disruption to
RSVP-TE LSPs. With the solution option specified in Section 3.5, the
impact to RSVP-TE traffic can be controlled and paths re-routed.
Some latent risk of disruption still remains because this solution
option relies on taking statistics samples and adopting to new
traffic flows only after the adjustment period. The defensive
mechanisms described in the base SR security framework should be
employed to guard against situations that result in SR traffic
hijacking or denial of service.
8.1. Normative References 6. References
[I-D.ietf-spring-segment-routing] 6.1. Normative References
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
6.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, Diffserv-aware MPLS Traffic Engineering", RFC 4124,
DOI 10.17487/RFC4124, June 2005, DOI 10.17487/RFC4124, June 2005,
<https://www.rfc-editor.org/info/rfc4124>. <https://www.rfc-editor.org/info/rfc4124>.
skipping to change at page 11, line 11 skipping to change at page 11, line 5
Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
RFC 7810, DOI 10.17487/RFC7810, May 2016, RFC 7810, DOI 10.17487/RFC7810, May 2016,
<https://www.rfc-editor.org/info/rfc7810>. <https://www.rfc-editor.org/info/rfc7810>.
[RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
"Performance-Based Path Selection for Explicitly Routed "Performance-Based Path Selection for Explicitly Routed
Label Switched Paths (LSPs) Using TE Metric Extensions", Label Switched Paths (LSPs) Using TE Metric Extensions",
RFC 7823, DOI 10.17487/RFC7823, May 2016, RFC 7823, DOI 10.17487/RFC7823, May 2016,
<https://www.rfc-editor.org/info/rfc7823>. <https://www.rfc-editor.org/info/rfc7823>.
Appendix A. Multiplier value range Appendix A. Multiplier Value Range
The following is a suggestion for the range of values for M: The following is a suggestion for the range of values for M:
M is a per-node positive real number that ranges from 0 to 2 with a M is a per-node positive real number that ranges from 0 to 2 with a
default of 1 and may be expressed as a percentage. default of 1 and may be expressed as a percentage.
o If M < 1, then the SR traffic average is being understated, which o If M < 1, then the SR traffic average is being understated, which
can result in the link getting full even though Maximum- can result in the link getting full even though Maximum-
Reservable-Bandwidth does not reach zero. Reservable-Bandwidth does not reach zero.
o If M > 1, then the SR traffic average is overstated, thereby o If M > 1, then the SR traffic average is overstated, thereby
resulting in the Maximum-Reservable-Bandwidth reaching zero before resulting in the Maximum-Reservable-Bandwidth reaching zero before
the link gets full. If the reduction of Maximum-Reservable- the link gets full. If the reduction of Maximum-Reservable-
Bandwidth becomes a negative value, then a value of zero SHOULD be Bandwidth becomes a negative value, then a value of zero SHOULD be
used and advertised. used and advertised.
Acknowledgements
The authors would like to thank Steve Ulrich for his detailed review
and comments.
Contributors
Chandra Ramachandran
Juniper Networks
Email: csekar@juniper.net
Raveendra Torvi
Juniper Networks
Email: rtorvi@juniper.net
Sudharsana Venkataraman
Juniper Networks
Email: sudharsana@juniper.net
Martin Vigoureux
Nokia
Email: martin.vigoureux@nokia.com
Authors' Addresses Authors' Addresses
Harish Sitaraman (editor) Harish Sitaraman (editor)
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US United States of America
Email: hsitaraman@juniper.net Email: hsitaraman@juniper.net
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
US United States of America
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US United States of America
Email: inaminei@google.com Email: inaminei@google.com
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
 End of changes. 53 change blocks. 
175 lines changed or deleted 171 lines changed or added

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