draft-ietf-teas-sr-rsvp-coexistence-rec-00.txt   draft-ietf-teas-sr-rsvp-coexistence-rec-01.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: November 24, 2017 I. Minei Expires: December 30, 2017 I. Minei
Google, Inc. Google, Inc.
S. Sivabalan S. Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
May 23, 2017 June 28, 2017
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-00.txt draft-ietf-teas-sr-rsvp-coexistence-rec-01.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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2017. This Internet-Draft will expire on December 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 7 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Multiplier value range . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
skipping to change at page 5, line 34 skipping to change at page 5, line 34
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. The following methodology can be used may be in the same QoS class.
at every TE node for this solution:
Reducing the bandwidth allowed for use by RSVP-TE can be explored
using the three parameters available in IGP-TE ([RFC5305],[RFC3630]),
namely Maximum-Link-Bandwidth, Maximum-Reservable-Bandwidth and
Unreserved-Bandwidth.
o Maximum-Link-Bandwidth: This parameter can be adjusted to
accommodate the bandwidth required for SR traffic with cascading
impacts on Maximum-Reservable-Bandwidth and Unreserved-Bandwidth.
However, changing the maximum bandwidth for the TE link will
prevent any compute engine for SR or RSVP to decipher the real
static bandwidth of the TE link. Further, when the Maximum-
Reservable-Bandwidth is derived from the Maximum-Link-Bandwidth,
its definition changes since Maximum-Link-Bandwidth will account
for the SR traffic.
o Unreserved-Bandwidth: SR traffic could directly adjust the
Unreserved-Bandwidth, without impacting Maximum-Link-Bandwidth or
Maximum-Reservable-Bandwidth. This model is equivalent to the
option described in Section 3.4. Furthermore this would result in
overloading IGP-TE advertisements to directly reflect both RSVP-TE
bandwidth bookings and SR bandwidth measurements.
o Maximum-Reservable-Bandwidth: As the preferred option, SR traffic
could adjust the Maximum-Reservable-Bandwidth, with cascading
impact on the Unreserved-Bandwidth.
The following methodology can be used at every TE node for this
solution:
o T: Traffic statistics collection time interval o T: Traffic statistics collection time interval
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, where k is a constant integer multiplier greater or equal
to 1. Its purpose is to provide a smoothing function to the to 1. Its purpose is to provide a smoothing function to the
statistics collection. statistics collection.
o Maximum-Reservable-Bandwidth: The maximum available bandwidth for o Maximum-Reservable-Bandwidth: The maximum available bandwidth for
TE (this is the maximum available bandwidth on the interface, RSVP-TE.
before any LSP reservations).
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.
o Initial Maximum-Reservable-Bandwidth: The Maximum-reservable-
bandwidth for TE when no SR traffic or RSVP-TE reservations exist
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 the bandwidth used by SR. Appendix A offers further guidance on
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. Further, at every interval
N, given a configured SR traffic threshold percentage and a set of N, given a configured SR traffic threshold percentage and a set of
collected SR traffic statistics samples across the interval N, the SR collected SR traffic statistics samples across the interval N, the SR
traffic average (or any other traffic metric depending on the traffic average (or any other traffic metric depending on the
algorithm used) over this period is calculated. algorithm used) over this period is calculated.
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 = Current Maximum-Reservable- o New Maximum-Reservable-Bandwidth = Initial Maximum-Reservable-
Bandwidth - (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 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 BCs may be updated equally such
skipping to change at page 8, line 5 skipping to change at page 8, line 37
Email: csekar@juniper.net Email: csekar@juniper.net
Raveendra Torvi Raveendra Torvi
Juniper Networks Juniper Networks
Email: rtorvi@juniper.net Email: rtorvi@juniper.net
Sudharsana Venkataraman Sudharsana Venkataraman
Juniper Networks Juniper Networks
Email: sudharsana@juniper.net Email: sudharsana@juniper.net
Martin Vigoureux
Nokia
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 No new security issues are introduced in this document beyond is
already part of RSVP-TE and Segment routing architectures. already part of RSVP-TE and Segment routing architectures.
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., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-11 (work in progress), February spring-segment-routing-12 (work in progress), June 2017.
2017.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://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,
<http://www.rfc-editor.org/info/rfc3209>. <http://www.rfc-editor.org/info/rfc3209>.
8.2. Informative References 8.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<http://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,
<http://www.rfc-editor.org/info/rfc4124>. <http://www.rfc-editor.org/info/rfc4124>.
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic Constraints Model for Diffserv-aware MPLS Traffic
Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005, Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005,
<http://www.rfc-editor.org/info/rfc4125>. <http://www.rfc-editor.org/info/rfc4125>.
[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,
<http://www.rfc-editor.org/info/rfc4127>. <http://www.rfc-editor.org/info/rfc4127>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[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>.
[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,
<http://www.rfc-editor.org/info/rfc7752>. <http://www.rfc-editor.org/info/rfc7752>.
skipping to change at page 9, line 27 skipping to change at page 10, line 27
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,
<http://www.rfc-editor.org/info/rfc7810>. <http://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,
<http://www.rfc-editor.org/info/rfc7823>. <http://www.rfc-editor.org/info/rfc7823>.
Appendix A. Multiplier value range
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
default of 1 and may be expressed as a percentage.
o If M < 1, then the SR traffic average is being understated, which
can result in the link getting full even though Maximum-
Reservable-Bandwidth does not reach zero.
o If M > 1, then the SR traffic average is overstated, thereby
resulting in the Maximum-Reservable-Bandwidth reaching zero before
the link gets full. If the reduction of Maximum-Reservable-
Bandwidth becomes a negative value, then a value of zero SHOULD be
used and advertised.
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 US
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 US
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 US
Email: inaminei@google.com Email: inaminei@google.com
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 18 change blocks. 
20 lines changed or deleted 82 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/