Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence
RFC 8426

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04

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]