L3VPN                                                            P. Jain
Internet-Draft                                                  K. Singh
Intended status: Standards Track                             J. Kotalwar
Expires: October 23, 2012                                        N. Bhau
                                                    Alcatel-Lucent, Inc.
                                                               C. Hassen
                                                             Bell Canada
                                                          April 21, 2012


        BGP Extensions for Multicast VPN Fast Upstream Failover
             draft-jain-mvpn-bfd-fast-upstream-failover-00

Abstract

   This document defines BGP extensions and procedures that allows use
   of BFD for Multi Point Networks for fast detection and failover for
   upstream faults in Multicast VPNs.  The upstream failures addressed
   in this proposal can be failure of any node between the Root PE and
   Leaf PE or failure between the Multicast Source and Root PE.

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 October 23, 2012.

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



Jain, et al.            Expires October 23, 2012                [Page 1]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Rapid Failure Detection  . . . . . . . . . . . . . . . . . . .  6

   4.  BGP-BFD Attribute  . . . . . . . . . . . . . . . . . . . . . .  7

   5.  Signaling procedures and usage considerations  . . . . . . . .  8
     5.1.  Tunnel Status Tracking for I-PMSI P-tunnel . . . . . . . .  8
       5.1.1.  Root PE Procedures . . . . . . . . . . . . . . . . . .  8
       5.1.2.  Leaf PE Procedures . . . . . . . . . . . . . . . . . .  8
     5.2.  Tunnel Status Tracking for S-PMSI P-tunnel . . . . . . . .  9
       5.2.1.  Root PE Procedures . . . . . . . . . . . . . . . . . .  9
       5.2.2.  Leaf PE Procedures . . . . . . . . . . . . . . . . . .  9
     5.3.  Multicast Source Status Tracking . . . . . . . . . . . . . 10
       5.3.1.  Root PE Procedures . . . . . . . . . . . . . . . . . . 10
       5.3.2.  Leaf PE Procedures . . . . . . . . . . . . . . . . . . 10

   6.  Management Considerations  . . . . . . . . . . . . . . . . . . 11

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13

   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16











Jain, et al.            Expires October 23, 2012                [Page 2]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


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

   When used in lower case, these words convey their typical use in
   common language, and are not to be interpreted as described in
   RFC2119 [RFC2119].












































Jain, et al.            Expires October 23, 2012                [Page 3]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


1.  Introduction

   In case of multicast in BGP/MPLS VPNs deployment, for purpose of
   redundancy the multicast source could be dual-homed to the Root
   PE(s).  The dual-homed Root PE(s) could individually originate
   P-Tunnel towards the Leaf PE.  This mechanism is described in
   [I-D.draft-morin-l3vpn-mvpn-fast-failover].  The Leaf PE can source
   the traffic from either of the upstream dual-homed Root PE node.  In
   such a deployment, there could be two types of failure scenarios:-

   1.  Failure of any network element in the provider network between
       Root PE and Leaf PE.

   2.  Failure of any network element between the Multicast Source and
       the Root PEs.

   It is desirable to achieve fast failure detection and switchover for
   any failure from above scenarios.

   This document addresses both the above failure scenarios by using BFD
   for Multipoint Networks [I-D.katz-ward-bfd-multipoint] and defining
   new BGP extensions for advertising the BFD parameters which will be
   used for fast failure detection of scenarios mentioned above.




























Jain, et al.            Expires October 23, 2012                [Page 4]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


2.  Terminology

   Terminology used in this document:

   Root PE: PE closest to the Multicast Source (This could be either
   directly connected to Multicast Source or via some network).
   P-Tunnel would be originating at this node.  This P-Tunnel could be
   Inclusive or Selective.

   Leaf PE: PE Node closest to the Multicast Receiver (This could be
   either directly connected to Multicast Source or via some network).
   P-Tunnel would be terminating at this node.

   BFD : Bidirectional Forwarding Detection.

   Other terminologies are as defined in [RFC6513] and [RFC6514].



































Jain, et al.            Expires October 23, 2012                [Page 5]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


3.  Rapid Failure Detection

   Multiple Multicast Sources Dual-Homed to PE Nodes

                                +---+
                                |   |
           +--------------------|PE1|- +      .--. .--.
         /   +------------------|   |   \    (    '    '.--.     +-|-+
        /   /                   +---+    \.-.' IP-MPLS      '----|   |
     (S1)..(Sn)                          (     network      )    |PE3|--(Receiever)
        \  \                    +---+   / (             .'-' ----|   |
         \   +------------------|   |  /   '--'. .'.    )        +-|-+
           +--------------------|PE2|-+        '--''--'
                                |   |
                                +---+
      <--Source to Root Network--><---------MVPN Context------------>




   As seen in the above diagram, all the PEs would be part of same
   multicast VPN.  Multiple multicast sources (S1..Sn) could be dual-
   homed to two PEs (PE1 and PE2), referenced as Root PEs.  Both the
   Root PEs would originate P-tunnel, which would terminate at Leaf PE
   (PE3).

   As long as C-S is reachable via both Root PEs, the Leaf PE will
   select one of the PEs connected to C-S as its Upstream PE with
   respect to C-S, this PE would be referred as "Primary Upstream PE".
   We will refer to the other PE connected to C-S as the "Standby
   Upstream PE".  Note that if the connectivity to C-S through the
   Primary Upstream PE becomes unavailable, then the PE will select the
   Standby Upstream PE as its Upstream PE with respect to C-S.  This
   procedure is described in [I-D.draft-morin-l3vpn-mvpn-fast-failover].

   If it is desired to use BFD to monitor the status of the P-Tunnel,
   then there is a need to exchange the BFD discriminator between the
   Root PE node and Leaf PE.

   If it is desired to use BFD to monitor the status of individual
   Multicast Source and P-Tunnel pair, then there is also a need to
   exchange the BFD discriminator between the Root PE node and Leaf PE
   to track the Multicast-Source and P-Tunnel pair status.

   This document defines new BGP extensions for advertising the BFD
   parameters to bring up BFD for Multipoint Networks session
   [I-D.katz-ward-bfd-multipoint] which would be used to track and
   addresses both the above failure scenarios.



Jain, et al.            Expires October 23, 2012                [Page 6]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


4.  BGP-BFD Attribute

   This document defines and uses a new BGP attribute called the "BGP-
   BFD attribute".  This is an optional transitive BGP attribute.  The
   format of this attribute is defined as follows:

           +-------------------------------+
           |       Flags (1 octet)         |
           +-------------------------------+
           |  BFD Discriminator (2 octets) |
           +-------------------------------+

   The Flags field has the following format:

                 0 1 2 3 4 5 6 7
                 +-+-+-+-+-+-+-+-+
                 |   reserved    |
                 +-+-+-+-+-+-+-+-+

   BFD Discriminator: This is the local discriminator for this BFD
   session, and is used to uniquely identify it.  It MUST be unique
   across all BFD sessions on this system, and nonzero.  It SHOULD be
   set to a random (but still unique) value to improve security.  The
   value is otherwise outside the scope of this specification.



























Jain, et al.            Expires October 23, 2012                [Page 7]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


5.  Signaling procedures and usage considerations

   If it is desired to track the P-tunnel status or status of the
   Multicast Source connected to Root PE using BFD.  It could be
   explicitly configured under the MVPN Service.

5.1.  Tunnel Status Tracking for I-PMSI P-tunnel

5.1.1.  Root PE Procedures

   When it is desired to track the P-Tunnel status using BFD, the Root
   PE MUST include the BGP-BFD Attribute in the I-PMSI A-D Route
   specified in [RFC6514] Section 4.1.

   If a P-Tunnel is already signaled, and then it is desired to track
   the P-Tunnel status using BFD, I-PMSI A-D Route must be re-sent with
   the same attributes as before, but the BGP-BFD Attribute MUST be
   included.

   If P-Tunnel is already signaled, and P-Tunnel status tracked using
   BFD and it is desired to stop tracking P-Tunnel status using BFD,
   then I-PMSI A-D Route MUST be re-sent with the same attributes as
   before, but the BGP-BFD Attribute MUST be excluded.

5.1.2.  Leaf PE Procedures

   On receiving the BFD attribute in the I-PMSI A-D Route, the Leaf PE
   MUST associate the received discriminator with the P-Tunnel
   originating from the Root PE.  Once the Leaf PE start getting the BFD
   probes from the Root PE with the said discriminator, the BFD session
   will be declared up and will then be used to track the health of the
   P-Tunnel.

   If the Leaf PE does not receive BFD probes for a P-Tunnel from give
   Root PE for Detection Time, the BFD session would be brought down.
   And, it would declare the P-tunnel associated with the discriminator
   as down.

   Leaf PE then can then initiate a switchover of the traffic from the
   Primary Tunnel, to the Standby Tunnel.

   When Leaf PE's P-Tunnel is already up, it receives new I-PMSI A-D
   Route with BGP-BFD attribute, it must accept the I-PMSI A-D Route and
   associate the discriminator with the P-tunnel.  When the BFD probes
   are received with the said discriminator, the BFD session is declared
   up.

   When Leaf PE's P-Tunnel is already up, and is tracked with BFD, and



Jain, et al.            Expires October 23, 2012                [Page 8]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


   it receives new I-PMSI A-D Route without BGP-BFD attribute, it must
   accept the I-PMSI A-D Route the BFD session should be declared admin
   down.  Receiver node SHOULD not switch the traffic to the Standby
   P-tunnel.

5.2.  Tunnel Status Tracking for S-PMSI P-tunnel

   All procedures mentioned in this section are same as of tracking of
   I-PMSI P-Tunnel, except that the BGP-BFD Attribute would be sent in
   S-PMSI A-D Route.

5.2.1.  Root PE Procedures

   When is desired to track the P-Tunnel status using BFD, the Root PE
   MUST include the BGP-BFD Attribute in the S-PMSI A-D Route specified
   in [RFC6514] Section 4.4.

   If a P-Tunnel is already signaled, and then it is desired to track
   the P-Tunnel status using BFD, S-PMSI A-D Route must be re-sent with
   the same attributes as before, but the BGP-BFD Attribute MUST be
   included.

   If P-Tunnel is already signaled, and P-Tunnel status tracked using
   BFD and it is desired to stop tracking P-Tunnel status using BFD,
   then S-PMSI A-D Route MUST be re-sent with the same attributes as
   before, but the BGP-BFD Attribute MUST be excluded.

5.2.2.  Leaf PE Procedures

   On receiving the BFD attribute in the S-PMSI A-D Route, the Leaf PE
   MUST associate the received discriminator with the P-Tunnel
   originating from the Root PE.  Once the Leaf PE start getting the BFD
   probes from the Root PE with the said discriminator, the BFD session
   will be declared up and will then be used to track the health of the
   P-Tunnel.

   If the Leaf PE does not receive BFD probes from give Detection Time
   for a give P-Tunnel, it would declare the P-tunnel associated with
   the discriminator as down.

   Leaf PE then can then initiate a switchover of the traffic from the
   Primary Tunnel, to the Standby Tunnel.

   When Leaf PE's P-Tunnel is already up, it receives new S-PMSI A-D
   Route with BGP-BFD attribute, it must accept the S-PMSI A-D Route and
   associate the discriminator with the P-tunnel.  When the BFD probes
   are received with the said discriminator, the BFD session is declared
   up.



Jain, et al.            Expires October 23, 2012                [Page 9]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


   When Leaf PE's P-Tunnel is already up, and is tracked with BFD, and
   it receives new S-PMSI A-D Route without BGP-BFD attribute, it must
   accept the S-PMSI A-D Route the BFD session should be declared admin
   down.  Receiver node SHOULD not switch the traffic to the Standby
   P-tunnel.

5.3.  Multicast Source Status Tracking

5.3.1.  Root PE Procedures

   When is desired to track the connectivity status of Multicast-Source
   at the Root PE(s), the Root PE MUST include the BGP-BFD Attribute in
   the Source Active A-D Route specified in [RFC6514] Section 4.5.

   The discriminator advertised in BGP-BFD Attribute in the Source
   Active A-D Route, would be used track the Multicast Source and the
   P-Tunnel from the Root PE that originated the Source Active A-D
   Route.

   When the Root PE detects that Multicast Source is reachable, it will
   start BFD probes over the P-Tunnel, for P-Tunnel and Multicast Source
   combination.

   The procedure or techniques used for tracking the Multicast-Source
   reachibility at the Root PE(s) could be router reachibility,
   interface tracking for directly connected Multicast Source, BFD,
   traffic monitoring from a given Multicast Source etc.  The details of
   the above techniques is outside the scope of this document.

5.3.2.  Leaf PE Procedures

   On receiving the BFD attribute in the Source Active A-D Route, the
   Leaf PE MUST associate the received discriminator with the P-Tunnel
   and Multicast Source combination.  Once the Leaf PE start getting the
   BFD probes from the Root PE with the said discriminator, the BFD
   session will be declared up and will then be used to track the health
   of the P-Tunnel and Multicast Source combination.

   When the Root PE detects that Multicast Source is no longer
   reachable, it will advertise the BFD Status for P-Tunnel and
   Multicast Source combination to be down by signaling it in DIAG field
   of BFD.  Leaf PE on receipt of BFD status down for P-Tunnel and
   Multicast Source combination, SHOULD declare the source un-reachable
   through the given PMSI and can then initiate a switchover of the
   traffic from the Primary Tunnel, to the Standby Tunnel.






Jain, et al.            Expires October 23, 2012               [Page 10]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


6.  Management Considerations

   None
















































Jain, et al.            Expires October 23, 2012               [Page 11]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


7.  Security Considerations


















































Jain, et al.            Expires October 23, 2012               [Page 12]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


8.  Acknowledgements

   The authors want to thank Wim Henderickx, Sandeep Bishnoi and Tony
   Dilliott of Alcatel-Lucent, Inc for significant contribution and
   feedback.














































Jain, et al.            Expires October 23, 2012               [Page 13]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


9.  IANA Considerations


















































Jain, et al.            Expires October 23, 2012               [Page 14]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


10.  References

10.1.  Normative References

   [I-D.draft-morin-l3vpn-mvpn-fast-failover]
              Morin, T., Rekhter, Y., Aggarwal, R., Henderickx, W.,
              Muley, P., and R. Qiu, "Multicast VPN fast upstream
              failover", draft-morin-l3vpn-mvpn-fast-failover-05 (work
              in progress), September 2011.

   [I-D.katz-ward-bfd-multipoint]
              Katz, D. and D. Ward, "BFD for Multipoint Networks",
              draft-katz-ward-bfd-multipoint-02 (work in progress),
              February 2009.

   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", RFC 6513, February 2012.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, February 2012.

10.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
              "Extensions to Resource Reservation Protocol - Traffic
              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
              Switched Paths (LSPs)", RFC 4875, May 2007.
















Jain, et al.            Expires October 23, 2012               [Page 15]


Internet-Draft    BGP Extensions for MVPN Fast Failover       April 2012


Authors' Addresses

   Pradeep Jain
   Alcatel-Lucent, Inc.
   701 E Middlefield Rd
   Mountain View, CA  94043
   USA

   Email: pradeep.jain@alcatel-lucent.com


   Kanwar Singh
   Alcatel-Lucent, Inc.
   701 E Middlefield Rd
   Mountain View, CA  94043
   USA

   Email: kanwar.singh@alcatel-lucent.com


   Jayant Kotalwar
   Alcatel-Lucent, Inc.
   701 E Middlefield Rd
   Mountain View, CA  94043
   USA

   Email: Jayant.Kotalwar@alcatel-lucent.com


   Nehal Bhau
   Alcatel-Lucent, Inc.
   701 E Middlefield Rd
   Mountain View, CA  94043
   USA

   Email: Nehal.Bhau@alcatel-lucent.com


   Clayton Hassen
   Bell Canada
   2955 Virtual Way
   Vancouver
   CANADA

   Email: Clayton.Hassen@bell.ca






Jain, et al.            Expires October 23, 2012               [Page 16]