PIM Working Group Y. Liu Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: 02 January 2026 New H3C Technologies 01 July 2025 PIM Reverse Path Forwarding (RPF) Vetor Conflict Resolution draft-liu-pim-rpf-vector-conflict-resolution-00 Abstract [RFC7891] Section 7 defines the handling principles for PIM Join attributes with same type of RFF Vector and Explicit RFP Vector, but with different contents are received. However, it does not address scenarios where one downstream router includes a RFF Vector in its message while another does not. This leaves the handling of such conflicts unspecified. This document supplements the existing specifications by defining the processing rules for this specific conflict scenario. 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 02 January 2026. Copyright Notice Copyright (c) 2025 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 and restrictions with respect to this document. Code Components extracted from this Liu, et al. Expires 02 January 2026 [Page 1] Internet-Draft PIM RPF Vector conflict resolution July 2025 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. Introduction...................................................2 2. Terminology....................................................3 3. Problem........................................................3 4. Conflicting Resolution Principle...............................4 5. Conflicting Resolution Process.................................4 6. IANA Considerations............................................5 7. Security Considerations........................................5 8. Normative References...........................................5 9. Informative References.........................................6 Authors' Addresses................................................6 1. Introduction In the Protocol Independent Multicast - Sparse Mode (PIM-SM) specification [RFC4601], a Join message sent by a node may identify one or more multicast distribution trees that the node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address may be a wildcard). [RFC5384] describes the inclusion of PIM Join Attributes in Join messages, associating them with specific multicast trees to be joined. [RFC5496] describes the scenario where core routers do not maintain external routes, the edge router send PIM join messages to core routers, utilizing PIM Join Attributes to carry RPF Vector TLVs to specify the path for the core routers to send the joins. Core routers select the path for the join based on the addresses carried in the RPF Vector TLV through local unicast routing, hence it is also referred to as "loose" RPF Vector. [RFC7891] describes the use of PIM Join Attributes to carry Explicit RPF Vector TLVs to strictly specify the join path, in scenarios when network administrators do not want to rely on unicast reachability to the RPF vector address but instead want to build a strict path based on the RPF vector, A router may receive conflicting RPF vector from different downstream routers. Section 7 of [RFC7891] describes the handling of conflicts when the RPF Vector TLV attributes or Explicit RPF Vector TLV attributes in the received join attributes are of the same type but have different contents. Liu, et al. Expires 02 January 2026 [Page 2] Internet-Draft PIM RPF Vector conflict resolution July 2025 However, there are cases where one downstream router includes a RPF Vector in its Join message while another does not. [RFC7891] does not specify how to handle such conflicts. This document supplements the existing specifications by defining the processing rules for this specific conflict scenario. 2. Terminology 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]. 3. Problem The Scenario PIM Join Attribute conflicts occurring when One downstream neighbor includes the Join Attributes in its Join message while Another neighbor sends Join message without the Join Attributes. [RFC7891] presents a scenario involving PIM with RPF Vector, as depicted in Figure 1. The cost of the links between R5-R6 and R7-R8 is 100, while the cost of all other links is 10. The multicast join path is R4->R3->R6->R5->R2->R1, where the multicast join is routed to the source using the RPF Vector list. This scenario can be used to join along a multicast backup path, allowing multicast traffic forwarding through a backup path in the event of a failure in the primary path (R4->R3->R2->R1). In this scenario, R8 is connected to Receiver2 and sends a join message to R6 without carrying the join attribute. Intermediate node R6 receives a PIM join with RPF Vector attributes from R3 and another PIM join without RPF Vector attributes from R8. According to the attribute conflict handling principle outlined in [RFC5384], when both join messages carry RPF Vector attributes, the one with higher priority will be selected. However, in the scenario where one join message carries the RPF Vector attribute and the other does not, there is no specified handling, resulting in uncertain join outcomes. [S]---(R1)---(R2)-----(R3)-----(R4)---[Receive1] | |if2 --- <--- | | ^ | | | if1 | | |(1) | (R5)----(R6)| | --(1)(S,G) Join)-- | if3| |(2)(S,G) Join Liu, et al. Expires 02 January 2026 [Page 3] Internet-Draft PIM RPF Vector conflict resolution July 2025 | | | (R7)-----(R8)--[Receive2] (1): Receive1 PIM Join with RPF Vector (2): Receive2 PIM Join without RPF Vector Figure 1 On R6, the PIM forwarding entries are: [R6] (S,G) Entry 1: Incoming interface: if1(R5-R6), Outgoing interface: R6-R3 (Join with RPF Vector) [R6] (S,G) Entry 2: Incoming interface: if2(R3-R6), Outgoing interface: R6-R8 (Join without RPF Vector) Given these two joins, a priority selection is required. However, the current specifications do not provide guidelines for handling such conflicts, leading to uncertainty in the join status. 4. Conflicting Resolution Principle When two join messages are received: If one with an RPF Vector and the other without, the join message without the RPF Vector is given priority. If one join message only contains a type 0 RPF Vector (RPF Vector) and the other contains a type 4 RPF Vector (Explicit RPF Vector), the join message with only the type 0 RPF Vector is given priority. This procedure ensures deterministic resolution of attribute conflicts while maintaining backward compatibility with routers that do not support preference attributes. 5. Conflicting Resolution Process For the scenario in Figure 1, R4 is connected to a local receiver, Receiver1. Enable FRR on R3, the primary path is [R4]->[R3]->[R2]->[R1], while the backup path is [R4]->[R3]->[R6]->[R5]->[R2]->[R1]. R8 is connected to another local receiver, Receiver2. The multicast join path is [R8]->[R6]->[R3]->[R2]->[R1]. To prevent conflicts, the PIM Join without the RPF Vector is prioritized. Thus, R6 retains only the entry with if1(R5-R6) as the incoming interface and R6-R8 as the outgoing interface, stopping R3 from receiving multicast traffic via the backup path. Liu, et al. Expires 02 January 2026 [Page 4] Internet-Draft PIM RPF Vector conflict resolution July 2025 The entry on R6 is: [R6] (S,G) Entry 2: Incoming interface: if2(R3-R6), Outgoing interface: if3(R6-R8) When R8's local receiver departs, R8 sends its prune, prompting R6 to revert to the backup path established by R3, allowing R3 to receive multicast traffic through both paths again. The final entry on R6 is: [R6] (S,G) Entry: Incoming interface: if1(R5-R6), Outgoing interface: if2(R3-R6) 6. IANA Considerations This document has no IANA actions. 7. Security Considerations TBD 8. Normative References [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, DOI 10.17487/RFC5384, November 2008, . [RFC5496] IJ. Wijnands, A. Boers, E. Rosen, Cisco Systems, Inc., "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, . [RFC7761] Fenner, B., Handley, M., UCL, Holbrook, H., and I. Kouvelas, Arista Networks, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC7761, March 2016. [RFC7891] J. Asghar, IJ. Wijnands, Ed., S. Krishnaswamy, A. Karan, Cisco Systems, V. Arya, DIRECTV Inc., "Explicit Reverse Path Forwarding (RPF) Vector", RFC 7891, DOI 10.17487/RFC7891, June 2016, . Liu, et al. Expires 02 January 2026 [Page 5] Internet-Draft PIM RPF Vector conflict resolution July 2025 9. Informative References TBD Authors' Addresses Yisong Liu China Mobile China Email: liuyisong@chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Liu, et al. Expires 02 January 2026 [Page 6]