Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence
RFC 8426
Internet Engineering Task Force (IETF) H. Sitaraman, Ed.
Request for Comments: 8426 V. Beeram
Category: Informational Juniper Networks
ISSN: 2070-1721 I. Minei
Google, Inc.
S. Sivabalan
Cisco Systems, Inc.
July 2018
Recommendations for RSVP-TE and Segment Routing (SR)
Label Switched Path (LSP) Coexistence
Abstract
Operators are looking to introduce services over Segment Routing (SR)
Label Switched Paths (LSPs) in networks running Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances,
operators are also migrating existing services from RSVP-TE to SR
LSPs. For example, there might be certain services that are well
suited for SR and need to coexist with RSVP-TE in the same network.
Such introduction or migration of traffic to SR might require
coexistence with RSVP-TE in the same network for an extended period
of time, depending on the operator's intent. The following document
provides solution options for keeping the traffic engineering
database consistent across the network, accounting for the different
bandwidth utilization between SR and RSVP-TE.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
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.
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.
Sitaraman, et al. Informational [Page 1]
RFC 8426 RSVP-TE and SR LSP Coexistence July 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Solution Options . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Static Partitioning of Bandwidth . . . . . . . . . . . . 4
3.2. Centralized Management of Available Capacity . . . . . . 4
3.3. Flooding SR Utilization in IGP . . . . . . . . . . . . . 5
3.4. Running SR over RSVP-TE . . . . . . . . . . . . . . . . . 5
3.5. TED Consistency by Reflecting SR Traffic . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Multiplier Value Range . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Introduction of SR [RFC8402] in the same network domain as RSVP-TE
[RFC3209] presents the problem of accounting for SR traffic and
making RSVP-TE aware of the actual available bandwidth on the network
links. RSVP-TE is not aware of how much bandwidth is being consumed
by SR services on the network links; hence, both at computation time
(for a distributed computation) and at signaling time, RSVP-TE LSPs
will incorrectly place loads. This is true where RSVP-TE paths are
distributed or centrally computed without a common entity managing
both SR and RSVP-TE computation for the entire network domain.
Sitaraman, et al. Informational [Page 2]
Show full document text