MPLS RSVP-TE MBB Label Reuse
draft-dai-mpls-rsvp-te-mbb-label-reuse-01

Document Type Expired Internet-Draft (individual)
Last updated 2016-03-12 (latest revision 2015-09-09)
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-dai-mpls-rsvp-te-mbb-label-reuse-01.txt

Abstract

The concept of "make-before-break (MBB)" while rerouting MPLS RSVP-TE tunnels is discussed in [RFC3209]. In the procedure that is outlined, the behaviour of downstream label assignment for the new LSP (new tunnel instance) is not well defined. As a general practice, a different label is assigned by each downstream router and advertised to the upstream router in the RESV message for the new LSP; this results in a separate end-to-end data-plane path for the new LSP (with the exception of PHP LSPs or UHP LSP with explicit label on the last hop). The consequence of this practice is that the label entry gets added/deleted in the LFIB at every non-ingress router along the LSP path during MBB. Also, the ingress router would need to update all the applications using this LSP when switching to the new tunnel instance, as the new tunnel instance uses different outgoing label. This in turn may also cause other elements of the network which are dependant on the LSP to do the update. Such network churn can be avoided or reduced if the same label can be re-used (kept intact) wherever it is affecting neither the routing functionalities nor the data path verification of each instance. This document proposes a set of procedures to facilitate label reuse when there is a total or partial path overlap between the two tunnel instances during MBB.

Authors

Minjie Dai (mdai@juniper.net)
Ebben Aries (exa@fb.com)
Muhammad Chaudhry (muhammad.n.chaudhry@verizon.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)