draft-ietf-teas-sr-rsvp-coexistence-rec-02.txt   draft-ietf-teas-sr-rsvp-coexistence-rec-03.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: September 6, 2018 I. Minei Expires: October 27, 2018 I. Minei
Google, Inc. Google, Inc.
S. Sivabalan S. Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
March 5, 2018 April 25, 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-02.txt draft-ietf-teas-sr-rsvp-coexistence-rec-03.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. In other cases, services running
on RSVP-TE might be migrated to run over SR. Such introduction or on RSVP-TE might be migrated to run over SR. Such introduction or
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 September 6, 2018. This Internet-Draft will expire on October 27, 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 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 9
Appendix A. Multiplier value range . . . . . . . . . . . . . . . 10 Appendix A. Multiplier value range . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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. The general problem is the available and reserved values in the TED. In most practical
management of dark bandwidth pools and can be generalized to cases
where any other service exists in the network that runs in parallel
across common links and whose bandwidth is not reflected in the
available and reserved values in the TED. In most practical
instances given the static nature of the traffic demands, limiting instances given the static nature of the traffic demands, limiting
the available reservable bandwidth available to RSVP-TE has been an the available reservable bandwidth available to RSVP-TE has been an
acceptable solution. However, in the case of SR traffic, there is acceptable solution. However, in the case of SR traffic, there is
assumed to be very dynamic traffic demands and there is considerable assumed to be very dynamic traffic demands and there is considerable
risk associated with stranding capacity or overbooking service risk associated with stranding capacity or overbooking service
traffic resulting in traffic drops. traffic resulting in traffic drops.
The high level requirements or assumptions to consider are: The high level requirements or assumptions 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Solution options 3. Solution options
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
skipping to change at page 5, line 45 skipping to change at page 5, line 45
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 to decipher the real prevent any compute engine for SR or RSVP from determining the
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
for the SR traffic. for the SR traffic.
o Unreserved-Bandwidth: SR traffic could directly adjust the o Unreserved-Bandwidth: SR traffic could directly adjust the
Unreserved-Bandwidth, without impacting Maximum-Link-Bandwidth or Unreserved-Bandwidth, without impacting Maximum-Link-Bandwidth or
Maximum-Reservable-Bandwidth. This model is equivalent to the Maximum-Reservable-Bandwidth. This model is equivalent to the
option described in Section 3.4. Furthermore this would result in option described in Section 3.4. Furthermore this would result in
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: 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
smoothing function to the statistics collection. The value of k
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, where k is a constant integer multiplier greater or equal = k * T
to 1. Its purpose is to provide a smoothing function to the
statistics collection.
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 If Differentiated-Service (Diffserv)-aware MPLS Traffic
Engineering (DS-TE) [RFC4124] is enabled, the Maximum-Reservable- Engineering (DS-TE) [RFC4124] is enabled, the Maximum-Reservable-
Bandwidth SHOULD be interpreted as the aggregate bandwidth Bandwidth SHOULD be interpreted as the aggregate bandwidth
constraint across all Class-Types independent of the Bandwidth constraint across all Class-Types independent of the Bandwidth
Constraints model. Constraints model.
skipping to change at page 7, line 6 skipping to change at page 7, line 8
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. Further, at every interval statistics for each of its TE interfaces. The measured SR traffic
N, given a configured SR traffic threshold percentage and a set of includes all labelled SR traffic and any traffic entering the SR
collected SR traffic statistics samples across the interval N, the SR network over that TE interface. Further, at every interval N, given
traffic average (or any other traffic metric depending on the a configured SR traffic threshold percentage and a set of collected
algorithm used) over this period is calculated. SR traffic statistics samples across the interval N, the SR traffic
average (or any other traffic metric depending on the algorithm used)
over this period is calculated. This method of sampling traffic
statistics and adjusting bandwidth reservation accordingly is similar
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-
skipping to change at page 8, line 47 skipping to change at page 9, line 11
Martin Vigoureux Martin Vigoureux
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
No new security issues are introduced in this document beyond is This document describes solution options for the co-existence of
already part of RSVP-TE and Segment routing architectures. RSVP-TE and SR LSPs in the same administrative domain. These
solution options do not require any new security considerations
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
pertaining to RSVP-TE are described in [RFC5920].
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.
skipping to change at page 9, line 25 skipping to change at page 9, line 44
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.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,
skipping to change at page 10, line 5 skipping to change at page 10, line 29
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering", Model for Diffserv-aware MPLS Traffic Engineering",
RFC 4127, DOI 10.17487/RFC4127, June 2005, RFC 4127, DOI 10.17487/RFC4127, June 2005,
<https://www.rfc-editor.org/info/rfc4127>. <https://www.rfc-editor.org/info/rfc4127>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[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,
<https://www.rfc-editor.org/info/rfc7471>. <https://www.rfc-editor.org/info/rfc7471>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
 End of changes. 17 change blocks. 
29 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/