BGP-MVPN Source Active Route Enhancement
draft-zzhang-bess-bgp-mvpn-source-active-route-00

bess                                                            Z. Zhang
Internet-Draft                                          Juniper Networks
Updates: 6514 (if approved)                                    R. Parekh
Intended status: Standards Track                                   Cisco
Expires: 1 September 2024                               29 February 2024

                BGP-MVPN Source Active Route Enhancement
           draft-zzhang-bess-bgp-mvpn-source-active-route-00

Abstract

   RFC6514 specifies the protocol and procedures for multicast in MPLS/
   BGP IP VPNs.  In the Any-Source Multicast (ASM) case, the section
   "14.  Supporting PIM-SM without Inter-Site Shared C-Trees" specifies
   that the Provider Edge that serves as a customer Rendezvous Point or
   runs Multicast Source Discovery Protocol advertises Source Active
   (SA) routes for ASM flows when it discovers those flows.  This
   document describes a situation where an optional enhancement to the
   advertisement of SA routes is desired and specifies the procedures.
   It updates RFC6514.

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 https://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 1 September 2024.

Copyright Notice

   Copyright (c) 2024 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 (https://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

Zhang & Parekh          Expires 1 September 2024                [Page 1]
Internet-Draft  BGP-MVPN Source Active Route Enhancement   February 2024

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   4.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Background

   Section "14.  Supporting PIM-SM without Inter-Site Shared C-Trees" of
   [RFC6514] specifies one way of supporting Any-Source Multicast (ASM)
   for Multicast Virtual Private VPN (MVPN), referred to as SPT-only
   mode in this document.

   Consider the following topology:

     source
       |
      CE1
       |
      PE1-------PE2 (c-rp)
        \       /
         \     /
           PE3
            |
           CE3
            |
         receiver

   When a receiver connected to the Last Hop Router (LHR) CE3 joins an
   ASM group, CE3 sends a (*, G) Protocol Independent Multicast (PIM)
   [RFC7611] Join Messages to PE3, which is the upstream router towards
   the Customer-Rendezvous-Point (C-RP) on PE2.  PE3 does not originate
   a (C-*, C-G) C-Multicast BGP route (an equivalent of the PIM (*, G)
   join message).  Rather, it only originates (C-S, C-G) C-multicast BGP
   routes (equivalent of PIM (S, G) join messages) when different
   sources for the group G are discovered.

   When the source starts sending multicast traffic for the ASM group G,
   the First Hop Router (FHR) CE1 sends a PIM Register message to the
   C-RP.  PE2 then originates a (C-S, C-G) Source Active (SA) BGP route
   to be imported by all PEs for the VPN.  As a result, PE3 originates a

Zhang & Parekh          Expires 1 September 2024                [Page 2]
Internet-Draft  BGP-MVPN Source Active Route Enhancement   February 2024

   (C-S, C-G) C-multicast route targeted at PE1 - the Upstream Multicast
   Hop (UMH) for the C-S.  PE1 then sends a corresponding (S, G) PIM
   join message towards CE1.

   [RFC6514] specifies the following situations where a PE originates SA
   routes:

  "A PE can obtain information about active multicast sources within a
   given MVPN in a variety of ways.  One way is for the PE to act as a
   fully functional customer RP (C-RP) for that MVPN.  Another way is to
   use PIM Anycast RP procedures [PIM-ANYCAST-RP] to convey information
   about active multicast sources from one or more of the MVPN C-RPs to
   the PE.  Yet another way is to use MSDP [MSDP] to convey information
   about active multicast sources from the MVPN C-RPs to the PE."

   In the above example, only PE2 will originate the SA routes.  After
   the signaling is done and traffic starts flowing, the LHR CE3 has the
   option of sending a PIM (S, G) join message but it may choose not to.

   If PE3 does not have the (S, G) join from CE3, and the SA route from
   PE2 is withdrawn/invalidated for whatever reason (e.g. the BGP
   session with PE2 goes down), PE3 will withdraw its (C-S, C-G)
   C-Multicast route and PE1 will stop sending traffic.  This
   PE2-related failure should not have caused traffic loss since it is
   not in the path at all.

   This can be avoided if PE1 also originates the (C-S, C-G) SA route
   when it receives the (C-S, C-G) C-multicast route.  When PE1 does not
   receive the (C-S, C-G) traffic for a while, it withdraws its
   corresponding SA route, even though it still has the (C-S, C-G)
   C-multicast route (otherwise the SA route and C-multicast route will
   stay forever).

   As long as there is any (C-S, C-G) SA route from any PE, PE3 will
   originate its (C-S, C-G) C-Multicast Route targeting at the UMH PE of
   its own choice.  In the above example, while PE2 first originates the
   SA route, PE3 still targets its C-Multicast route at PE1.  When PE2's
   SA route is invalidated/withdrawn, PE3 will keep its (C-S, C-G)
   C-Multicast route if the SA route from PE1 is present.

2.  Specification

   This section specifies an optional enhancement to the origination of
   SA routes in the SPT-only mode for supporting ASM.

   Any PE that discovers a (C-S, C-G) flow on its PE-CE interfaces MUST
   originate a corresponding (C-S, C-G) SA route, and MUST withdraw the
   route when the flow is deemed no longer active.

Zhang & Parekh          Expires 1 September 2024                [Page 3]
Internet-Draft  BGP-MVPN Source Active Route Enhancement   February 2024

   Besides the methods of discovering a flow described in the section 14
   of [RFC6514] (as quoted earlier), a PE MAY use the its (C-S, C-G)
   state for this purpose if the Reverse Path Forwarding (RPF) interface
   is a PE-CE interface.  The state may have been triggered by the
   arrival of traffic on the PE-CE interface or by a corresponding (C-S,
   C-G) C-Multicast route. when the (C-S, C-G) state is first created,
   the PE MAY immediately originate a corresponding Source Active route
   without waiting for the arrival of the traffic.  When it stops
   receiving traffic for over the PIM Keepalive_Period [RFC7761] or if
   the (C-S, C-G) state is deleted, it MUST withdraws the SA route.

   Note that while the Keepalive_Period value is used here, it does not
   require the Keepalive Timer mechanism in [RFC7761].

3.  Security Considerations

   This document does not introduce any security issues.

4.  Normative References

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

   [RFC7611]  Uttaro, J., Mohapatra, P., Smith, D., Raszuk, R., and J.
              Scudder, "BGP ACCEPT_OWN Community Attribute", RFC 7611,
              DOI 10.17487/RFC7611, August 2015,
              <https://www.rfc-editor.org/info/rfc7611>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net

   Rishabh Parekh
   Cisco
   Email: riparekh@cisco.com

Zhang & Parekh          Expires 1 September 2024                [Page 4]