Internet DRAFT - draft-hc-mpls-mpoint-bfd-for-mpls

draft-hc-mpls-mpoint-bfd-for-mpls





Network Working Group                                           V. Hegde
Internet-Draft                                           R. Chandrasekar
Expires: March 11, 2013                                 Juniper Networks
                                                       September 7, 2012


                        Multipoint BFD for MPLS
                draft-hc-mpls-mpoint-bfd-for-mpls-00.txt

Abstract

   Recent proposals have extended the use of Bidirectional Forwarding
   Detection to detect data plane failures in multipoint networks.  One
   desirable application of Multipoint BFD [MP-BFD] is to detect data
   path failures in point-to-multipoint Label Switched Paths (P2MP
   LSPs).  The scope of this document is to discuss the applicability of
   multipoint BFD for fault detection in the data plane of P2MP LSPs.
   The document extends the techniques and mechanisms mentioned in
   [RFC5884] and applies them to MPLS P2MP environment.

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 11, 2013.

Copyright Notice

   Copyright (c) 2012 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



Hegde & Chandrasekar     Expires March 11, 2013                 [Page 1]

Internet-Draft           Multipoint BFD for MPLS          September 2012


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  BFD for P2MP LSPs: Motivation  . . . . . . . . . . . . . . . .  4
   3.  Notes on bootstrapping Multipoint BFD for P2MP LSPs  . . . . .  5
   4.  Proposed Solutions . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Periodic echo requests with "Do not reply" . . . . . . . .  6
     4.2.  Application driven Ping  . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12



















Hegde & Chandrasekar     Expires March 11, 2013                 [Page 2]

Internet-Draft           Multipoint BFD for MPLS          September 2012


1.  Introduction

   Application of BFD for fault detection in the data path of point-to-
   point MPLS LSPs is addressed in [RFC5884].  Since point-to-multipoint
   LSPs are not less vulnerable to data path failures than their point-
   to-point counterparts, this document extends the techniques used in
   [RFC5884] such that they can be applied to P2MP LSPs.  This document
   stresses the reuse of existing LSP ping mechanism to bootstrap the
   BFD sessions for point-to-point LSPs and its application to point-to-
   multipoint LSPs and multipoint BFD in order to simplify
   implementation and network operations.

1.1.  Terminology

   The terminology used in this document for MPLS OAM can be found in
   [RFC4379].

   The terminology for multipoint BFD can be found in [MP-BFD].

1.2.  Conventions

   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 [RFC5884].



























Hegde & Chandrasekar     Expires March 11, 2013                 [Page 3]

Internet-Draft           Multipoint BFD for MPLS          September 2012


2.  BFD for P2MP LSPs: Motivation

   As with P2P LSPs, there is a requirement for faster detection of data
   plane failures in P2MP LSPs.  Existing mechanisms like P2MP LSP ping
   and P2MP trace route are expensive in terms of the amount of control
   plane processing required and are catered towards fault isolation or
   on-demand fault detection at or by the ingress LSR.  Multipoint BFD
   offers a way for the egress LSR to detect a loss of connectivity to a
   particular ingress along the multicast data path.  Some of the
   advantages of BFD as listed in [RFC5884] which also apply to P2MP
   LSPs are:

   a) Support for fault detection for a greater number of LSPs.

   b) Fast detection.  Considering how BFD is most suitable to be
   implemented in the hardware or firmware due to its fixed packet
   format, BFD can be used to achieve fault detection with sub-second
   granularity.  There are several advantages of sub-second detection of
   data plane failures in any P2MP LSP at the the egress LSR, a couple
   of them being:

   1) Multicast Live-Live

   For applications that make use of multicast live-live where traffic
   is pulled from two different streams and merged at the egress, fast
   detection of failures on any one of the streams at the egress of the
   P2MP LSP might be desirable to provide seamless service by switching
   over to the backup stream to avoid traffic interruptions.  Multipoint
   BFD is a suitable choice to detect these kinds of data path failures
   and to notify the applications of these failures.

   2) LSPs with discontinuous traffic flow

   One way of doing OAM over a P2MP LSP today is for an application to
   monitor the data traffic coming over the P2MP LSP and correlate that
   with the health of the data path.  For applications that do not have
   continuous traffic flowing, it is desirable to monitor the
   connectivity of the data path by some other means.  Multipoint BFD
   can be used for this purpose and the detection can be done at the LHR
   instead of the receiver.











Hegde & Chandrasekar     Expires March 11, 2013                 [Page 4]

Internet-Draft           Multipoint BFD for MPLS          September 2012


3.  Notes on bootstrapping Multipoint BFD for P2MP LSPs

   The procedures of Multipoint BFD are described in [MP-BFD].  Although
   Multipoint BFD tries to be generic in nature regardless of the
   technology used to establish the multipoint tunnel, for P2MP LSPs
   there are certain scenarios where making the association of an
   incoming BFD packet with its corresponding P2MP LSP becomes a
   challenge at the egress.  For example in case of Penultimate Hop
   Popping (PHP) for a single label stack P2MP LSP, incoming BFD packets
   at the egress do not contain enough information to associate them
   with a particular P2MP LSP.

   A similar problem of bootstrapping was encountered when attempting to
   run BFD over P2P LSPs.  These problems have been resolved by
   following the procedures mentioned in [RFC5884].The procedures
   explained in [RFC5884] can be applied to P2MP LSP ping to bootstrap
   the multipoint BFD session.  Although the mechanisms of [RFC5884]
   when appliedto P2MP LSP Ping and Multipoint BFD would work, it may
   not necessarily be optimal for a P2MP environment, primarily because:

   a) Unidirectional Nature.

   Multipoint BFD by nature can be unidirectional.  Multipoint BFD in
   its primary form is designed for the egress LSR to detect a loss of
   connectivity to the ingress along the multipoint path along with
   providing the ingress with some optional mechanisms to track the
   connectivity to certain egress LSRs.  When running multipoint BFD in
   this form, the ingress does not have any need to learn the BFD
   discriminator of the egress to establish the BFD session.  Even if
   the ingress does wish to track the connectivity to certain egress
   LSRs, this would happen over the unicast path and if the procedures
   of [MP-BFD] are followed then the unicast BFD sessions can be
   established without any explicit out of band bootstrapping.

   b) Scalability

   The procedures of P2MP LSP ping are described in [RFC6425].  Although
   [RFC6425] talks about various mechanisms to rate limit the echo reply
   messages coming into the ingress, in a large deployment, it may not
   be optimal to solicit echo replies from all the egress LSRs.
   Soliciting replies from all the egress routers may lead to the
   ingress being flooded by a large number of messages in a short
   duration.








Hegde & Chandrasekar     Expires March 11, 2013                 [Page 5]

Internet-Draft           Multipoint BFD for MPLS          September 2012


4.  Proposed Solutions

4.1.  Periodic echo requests with "Do not reply"

   Applying the procedures of [RFC5884]to P2MP LSPs, periodic P2MP LSP
   Ping echo request messages MUST be sent by the ingress LSR to the
   egress LSR along the same data path as the P2MP LSP.  These echo
   messages SHOULD contain the local discriminator of the Multipoint BFD
   session established by the ingress LSR for the P2MP LSP.  The rate of
   generation of echo request messages must be considerably slower than
   the rate of generation of BFD packets at the ingress LSR.  If the
   primary purpose of running P2MP LSP Ping is to facilitate the
   establishment of the BFD session and its association with the
   corresponding P2MP LSP at the egress LSR, then an implementation MAY
   set the value of the Reply Mode field in the message to 1 (Do Not
   Reply) thus indicating the egress LSRs to suppress the generation of
   echo reply messages.  By doing so, an implementation avoids the
   possibility of congestion at the ingress LSR by not soliciting reply
   messages from all the egress LSRs.

   Note that even when P2MP LSP Ping is used for bootstrapping BFD
   sessions, periodic transmission of the echo request messages are
   required by the ingress LSR primarily because in a P2MP LSP
   environment, there are valid scenarios where the ingress LSR may not
   be aware of the existence of different egress LSRs.  In such a case,
   the ingress LSR may not have sufficient information to decide when to
   send out the LSP ping with the BFD discriminator to bootstrap the BFD
   session at the newly attached egress LSRs.  By periodically
   transmitting LSP Ping echo request messages, the ingress LSR ensures
   that any newly attached egress LSR will be able to bind the BFD
   session to the P2MP LSP when it receives the next periodic echo
   request message.

   It is highly possible that an egress LSR will start receiving the
   multipoint BFD packets befo \re the LSP ping from the ingress.  How
   an implementation chooses to handle these incoming BFD packets is
   outside the scope of this document and is left to the implementation.
   The egress LSR SHOULD follow the procedures mentioned in [RFC5884] to
   validate the PING packet and then use the discriminator in the P2MP
   echo request message to either bind an existing BFD session to the
   P2MP LSP or setup a new BFD session by accepting BFD packets with the
   discriminator value it has received in the echo request message from
   the ingress.

4.2.  Application driven Ping

   The rate of generation of periodic echo requests by the ingress LSR
   is considerably slower than the rate of generation of BFD packets



Hegde & Chandrasekar     Expires March 11, 2013                 [Page 6]

Internet-Draft           Multipoint BFD for MPLS          September 2012


   because the processing of PING packet is a control plane processing
   extensive operation.  For P2MP LSPs, if an implementation of P2MP
   ping which is used for bootstrapping the BFD session has chosen to
   solicit replies from all the egress LSRs, then it is crucial that
   these ping packets are rate limited to avoid congestion at the
   ingress LSR.  Slowing down the rate of generation of Ping packets
   also in turn slows down the bootstrapping of the BFD sessions at the
   egress LSRs who might have newly attached themselves to the P2MP LSP.
   This may not be desirable for certain applications which may want to
   leverage Multipoint BFD to fast detect failures on the data path of a
   P2MP LSP at the egress.

   Application driven expedited PING is one way to solve this problem.
   The decision as to when to send the expedited PING is left to the
   implementation and outside the scope of this document, one use of
   expedited ping is that if an application running on the ingress LSR
   can detect a new node attaching itself as the egress to its P2MP LSP,
   then an implementation MAY choose to send an expedited PING packet
   over the P2MP data path.  An implementation MAY also choose to
   solicit an echo reply from one or a subset of egress LSRs using the
   Egress Address P2MP Responder Sub-TLV(as described in [RFC6425]) in
   the expedited echo request messages, however if an implementation
   chooses to solicit replies from a subset of egress LSRs using the
   P2MP LSP Ping, then it MUST ensure to avoid congestion at or near the
   ingress when the replies arrive.

   Periodic echo requests as described in section 4.1 can be used in
   conjunction with application driven epedited ping to provide an
   optimal solution to bootstrap BFD sessions.Periodic messages ensures
   that in a dynamic P2MP LSP environment, where the egress LSRs are
   constantly attaching or detaching themselves from the P2MP LSPs, the
   association of BFD packets to a P2MP LSP is possible at the egress
   LSR.  For applications running in the ingress that do track the
   egress LSRs of a P2MP LSP, expedited PING could be used to quickly
   bootstrap the BFD session at the egress without having to wait for
   the next periodic PING, while doing so the application MAY also
   choose to solicit replies from a subset of the egress LSRs.














Hegde & Chandrasekar     Expires March 11, 2013                 [Page 7]

Internet-Draft           Multipoint BFD for MPLS          September 2012


5.  Security Considerations

   No new security issues are introduced beyond those that are described
   in [RFC6425] and [MP-BFD].















































Hegde & Chandrasekar     Expires March 11, 2013                 [Page 8]

Internet-Draft           Multipoint BFD for MPLS          September 2012


6.  IANA Considerations

   This draft does not have any request for IANA.
















































Hegde & Chandrasekar     Expires March 11, 2013                 [Page 9]

Internet-Draft           Multipoint BFD for MPLS          September 2012


7.  Acknowledgments

   The authors would like to acknowledge the authors of [RFC6425] and
   the authors of [RFC5884] for their work, which is substantially re-
   used in this document.  The authors would like to thank Santosh PK,
   Shivakumar Channalli and Harish Sitaraman for their reviews and
   feedback on this material.












































Hegde & Chandrasekar     Expires March 11, 2013                [Page 10]

Internet-Draft           Multipoint BFD for MPLS          September 2012


8.  Normative References

   [MP-BFD]   Katz, D. and D. Ward, "BFD for Multipoint Networks",
              draft-ietf-bfd-multipoint-00 (work in progress),
              October 2011.

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, June 2010.

   [RFC6425]  Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa,
              S., and T. Nadeau, "Detecting Data-Plane Failures in
              Point-to-Multipoint MPLS - Extensions to LSP Ping",
              RFC 6425, November 2011.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

































Hegde & Chandrasekar     Expires March 11, 2013                [Page 11]

Internet-Draft           Multipoint BFD for MPLS          September 2012


Authors' Addresses

   Vikas Hegde
   Juniper Networks
   Embassy Business Park
   Bangalore, KA  560093
   India

   Email: vikashegde@juniper.net


   Chandrasekar R
   Juniper Networks
   Embassy Business Park
   Bangalore  560093
   India

   Email: csekar@juniper.net

































Hegde & Chandrasekar     Expires March 11, 2013                [Page 12]