[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01

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 Reuse
               draft-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 2015


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 12, 2016.

Copyright Notice

   Copyright (c) 2015 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
   (http://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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Common LSP MBB triggers . . . . . . . . . . . . . . . . .   3
   2.  Recommended conditions for label reuse  . . . . . . . . . . .   3
   3.  Control of label-reuse behaviour  . . . . . . . . . . . . . .   4
     3.1.  Enable/Disable label-reuse capability . . . . . . . . . .   4
     3.2.  Prefer overlapping path to facilitate label-reuse . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5






Dai, et al.              Expires March 12, 2016                 [Page 2]


Internet-Draft        MPLS RSVP-TE MBB Label Reuse        September 2015


1.  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 behaviour

3.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]


Internet-Draft        MPLS RSVP-TE MBB Label Reuse        September 2015


   Ebben Aries
   Facebook
   1 Hacker Way
   Menlo Park, CA  94025
   US

   Email: exa@fb.com


   Muhammad Nauman Chaudhry
   Verizon Communications

   Email: muhammad.n.chaudhry@verizon.com


   Raveendra Torvi
   Juniper Networks

   Email: rtorvi@juniper.net


   Markus Jork
   Juniper Networks

   Email: mjork@juniper.net


   Yimin Shen
   Juniper Networks

   Email: yshen@juniper.net


   Natrajan Venkataraman
   Juniper Networks

   Email: natv@juniper.net


   Harish Sitaraman
   Juniper Networks

   Email: hsitaraman@juniper.net








Dai, et al.              Expires March 12, 2016                 [Page 6]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/