Network Working Group M. Dai, Ed.
Internet-Draft Juniper Networks
Intended status: Best Current Practice E. Aries
Expires: March 12, 2016 Facebook
M. Chaudhry
Verizon Communications
September 9, 2015
MPLS RSVP-TE MBB Label Reusedraft-dai-mpls-rsvp-te-mbb-label-reuse-01
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Dai, et al. Expires March 12, 2016 [Page 1]

Internet-Draft MPLS RSVP-TE MBB Label Reuse September 20151. Introduction
MPLS RSVP-TE make-before-break (MBB) procedure is defined in
[RFC3209]. The behaviour of downstream label assignment for the new
LSP (new tunnel instance) is not well-defined in this procedure. In
most MBB implementations, a different label is assigned by each
downstream router and advertised to upstream router in the RESV
message for the new Label Switched Path (LSP). This means a separate
end-to-end data-plane path for the new tunnel instance (with the
exception of PHP LSPs or UHP LSPs with explicit NULL label at the
last hop). Although this allows for independent end-to-end path
verification for each tunnel instance, it requires an LFIB entry add/
delete at every non-ingress router along the path of the LSP during
MBB even if the paths for the new tunnel instance and the old tunnel
instance might be partially or totally overlapping. Label reuse
under partial or total overlap condition reduces unnecessary LFIB
update, reduces the possibility of errors and improves network
convergence latency. In addition, whenever label is reused, the
setup time for the new tunnel instance would be faster because there
is no need for the transit routers along the path of the new LSP to
wait for the new LFIB entry to be added.
1.1. Common LSP MBB triggers
The MBB procedure can be triggered because of a change to any
property of the RSVP-TE tunnel. The most common case is a change to
the bandwidth requirement, especially with the widely implemented
auto-bandwidth feature, which dynamically adjusts the LSP bandwidth
based on traffic-monitoring feedback. With CSPF commonly used to
compute path to meet the new bandwidth requirements, it is possible
that the existing path is still one of the best paths which can
satisfy the new requirements. This provides the opportunity to reuse
labels to achieve the benefits described. If given the choice and
the goal of selecting the best path is not the highest priority, CSPF
can also prefer the existing path to other possible paths to take
full advantage of the label reuse as long as the requirements are
still met by the existing path.
2. Recommended conditions for label reuse
The notion of "Label reuse" can be applied for both point-to-point
(P2P) LSP and point-to-multipoint (P2MP) LSP, but due to the
complexity of P2MP and many possible variations of the solutions,
this document will only focus on the recommendations for P2P LSPs.
Labels can be reused when the primary paths of the two tunnel
instances have complete overlap starting from a certain point in the
paths and going all the way to the egress router of the LSP. The
Dai, et al. Expires March 12, 2016 [Page 3]

Internet-Draft MPLS RSVP-TE MBB Label Reuse September 2015
best case scenario is complete overlap of the two paths end to end;
in which case there is no need for any label changes and LFIB
updates, both in the transit as well as in the ingress routers.
Existing data plane verification method can be used to verify new
tunnel instance as before. Data traversing on either instance will
take a different label path from the ingress to this transit router
and from then on the traffic will merge into the shared label
switched path towards the egress router.
The conditions under which label reuse can be applied are as
following:
o Egress router of LSP: Reuse-label functionality can always be
applied.
o Transit routers of the LSP: For any given transit router of P2P
LSP, label can be reused if the following conditions are met:
(a) Downstream label received is the same
(b) NHOP is the same
o Ingress router of the LSP: When the same conditions as listed
under transit router are met, instead of no label change, there is
no need for ingress route update for LSP to applications depending
on it.
The label reuse procedure starts from the egress of the LSP as RESV
traverses upstream towards the ingress of the LSP; it terminates at
the first transit router where paths of the two tunnel instances
diverge towards the ingress of the LSP or at the transit router which
doesn't support label reuse.
3. Control of label-reuse behaviour3.1. Enable/Disable label-reuse capability
This document recommends enabling "label-reuse" capability by
default. Allow it to be disabled if needed by changing
configuration.
3.2. Prefer overlapping path to facilitate label-reuse
In order to take full advantage of the label-reuse capability, path
computation for the new tunnel instance may seek to maximize path
overlap. This can be achieved through two approaches.
Dai, et al. Expires March 12, 2016 [Page 4]

Internet-Draft MPLS RSVP-TE MBB Label Reuse September 2015
o The first approach is to select from the best paths available the
path which has the most path overlap with the existing path
starting from the egress router.
o The second approach is to prefer the existing path if it still
satisfies the new requirement, even though it might not be the
best path.
The choice between the approaches is a matter of local computation
policy and can be different for different types of MBB trigger.
4. IANA Considerations
This document makes no request for IANA action.
5. Security Considerations
This document does not introduce new security issues.
6. Acknowledgements
None.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
Authors' Addresses
Minjie Dai (editor)
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
US
Email: mdai@juniper.net
Dai, et al. Expires March 12, 2016 [Page 5]