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