draft-ietf-teas-sr-rsvp-coexistence-rec-03.txt   draft-ietf-teas-sr-rsvp-coexistence-rec-04.txt 
TEAS Working Group H. Sitaraman, Ed. TEAS Working Group H. Sitaraman, Ed.
Internet-Draft V. Beeram Internet-Draft V. Beeram
Intended status: Informational Juniper Networks Intended status: Informational Juniper Networks
Expires: October 27, 2018 I. Minei Expires: November 17, 2018 I. Minei
Google, Inc. Google, Inc.
S. Sivabalan S. Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
April 25, 2018 May 16, 2018
Recommendations for RSVP-TE and Segment Routing LSP co-existence Recommendations for RSVP-TE and Segment Routing LSP co-existence
draft-ietf-teas-sr-rsvp-coexistence-rec-03.txt draft-ietf-teas-sr-rsvp-coexistence-rec-04.txt
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) LSPs in networks running Resource Reservation Protocol (RSVP-TE)
LSPs. In some instances, operators are also migrating existing LSPs. In some instances, operators are also migrating existing
services from RSVP-TE to SR LSPs. For example, there might be services from RSVP-TE to SR LSPs. For example, there might be
certain services that are well suited for SR and need to co-exist certain services that are well suited for SR and need to co-exist
with RSVP-TE in the same network. In other cases, services running with RSVP-TE in the same network. Such introduction or migration of
on RSVP-TE might be migrated to run over SR. Such introduction or traffic to SR might require co-existence with RSVP-TE in the same
migration of traffic to SR might require co-existence with RSVP-TE in network for an extended period of time depending on the operator's
the same network for an extended period of time depending on the intent. The following document provides solution options for keeping
operator's intent. The following document provides solution options the traffic engineering database consistent across the network,
for keeping the traffic engineering database (TED) consistent across accounting for the different bandwidth utilization between SR and
the network, accounting for the different bandwidth utilization RSVP-TE.
between SR and RSVP-TE.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 October 27, 2018. This Internet-Draft will expire on November 17, 2018.
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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . 4
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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Multiplier value range . . . . . . . . . . . . . . . 11 Appendix A. Multiplier value range . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Introduction of SR [I-D.ietf-spring-segment-routing] in the same Introduction of SR [I-D.ietf-spring-segment-routing] in the same
network domain as RSVP-TE [RFC3209] presents the problem of network domain as RSVP-TE [RFC3209] presents the problem of
accounting for SR traffic and making RSVP-TE aware of the actual accounting for SR traffic and making RSVP-TE aware of the actual
available bandwidth on the network links. RSVP-TE is not aware of available bandwidth on the network links. RSVP-TE is not aware of
how much bandwidth is being consumed by SR services on the network how much bandwidth is being consumed by SR services on the network
links and hence both at computation time (for a distributed links and hence both at computation time (for a distributed
computation) and at signaling time RSVP-TE LSPs will incorrectly computation) and at signaling time RSVP-TE LSPs will incorrectly
place loads. This is true where RSVP-TE paths are distributed or place loads. This is true where RSVP-TE paths are distributed or
centrally computed without a common entity managing both SR and RSVP- centrally computed without a common entity managing 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 TED. In most practical the available and reserved values in the traffic engineering database
instances given the static nature of the traffic demands, limiting (TED). In most practical instances given the static nature of the
the available reservable bandwidth available to RSVP-TE has been an traffic demands, limiting the available reservable bandwidth
acceptable solution. However, in the case of SR traffic, there is available to RSVP-TE has been an acceptable solution. However, in
assumed to be very dynamic traffic demands and there is considerable the case of SR traffic, there is assumed to be very dynamic traffic
risk associated with stranding capacity or overbooking service demands and there is considerable risk associated with stranding
traffic resulting in traffic drops. capacity or overbooking service traffic resulting in traffic drops.
The high level requirements or assumptions 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 co-existence 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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
options. A specific solution is not recommended as all solutions are
valid even though some may not satisfy all the requirements. If a
solution is acceptable for an operator based on their deployment
model then 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 and each can operate
within that bandwidth allocation and SHOULD NOT preempt each other. within that bandwidth allocation and SHOULD NOT preempt each 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
skipping to change at page 4, line 36 skipping to change at page 4, line 42
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. This does not fit with assumption 2 are not reflected in the TED.
mentioned earlier.
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 path
computation engine (CSPF) can be changed to consider this computation engine (CSPF) can be changed to consider this
information. This requires changes to the RSVP-TE path computation information. This requires changes to the RSVP-TE path computation
logic and would require upgrades in deployments where distributed logic and would require upgrades in deployments where distributed
computation is done across the network. computation is done across the network.
skipping to change at page 7, line 41 skipping to change at page 7, line 44
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 BCs may be updated equally such
that the total value updated is equal to the newly calculated SR that the total value updated is equal to the newly calculated SR
traffic average. 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 high)
between RSVP-TE LSPs. It is RECOMMENDED that the IGP-TE update between RSVP-TE LSPs. The IGP-TE update threshold SHOULD allow for
threshold SHOULD be lower in order to flood unreserved bandwidth more frequent flooding of unreserved bandwidth. From an operational
updates often. From an operational point of view, an implementation point of view, an implementation SHOULD be able to expose both the
SHOULD be able to expose both the configured and the actual values of configured and the actual values of the Maximum-Reservable-Bandwidth.
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
skipping to change at page 9, line 12 skipping to change at page 9, line 12
Nokia Nokia
Email: martin.vigoureux@nokia.com Email: martin.vigoureux@nokia.com
6. IANA Considerations 6. IANA Considerations
This draft does not have any request for IANA. This draft does not have any request for IANA.
7. Security Considerations 7. Security Considerations
This document describes solution options for the co-existence of This document describes solution options for the co-existence of
RSVP-TE and SR LSPs in the same administrative domain. These RSVP-TE and SR LSPs in the same administrative domain. The security
solution options do not require any new security considerations considerations for SR are described in
beyond those that are already part of RSVP-TE and SR architectures.
With the solution specified in Section 3.5, a malicious party might
be able to use a hijacked SR traffic stream to cause disruption to
RSVP-TE LSPs. The defensive mechanisms described in the base RSVP-TE
and SR security frameworks could be employed to guard against
situations that result in traffic hijacking or denial of service.
The security requirements and mechanisms for SR are described in
[I-D.ietf-spring-segment-routing]. The security considerations [I-D.ietf-spring-segment-routing]. The security considerations
pertaining to RSVP-TE are described in [RFC5920]. 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 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. in progress), January 2018.
 End of changes. 18 change blocks. 
44 lines changed or deleted 51 lines changed or added

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