Protocol Independent Multicast Light (PIM Light)
draft-ietf-pim-light-11

Network Working Group                                    H. Bidgoli, Ed.
Internet-Draft                                                     Nokia
Intended status: Standards Track                               S. Venaas
Expires: 8 June 2025                                  Cisco System, Inc.
                                                               M. Mishra
                                                            Cisco System
                                                                Z. Zhang
                                                        Juniper Networks
                                                              M. McBride
                                             Futurewei Technologies Inc.
                                                         5 December 2024

            Protocol Independent Multicast Light (PIM Light)
                        draft-ietf-pim-light-11

Abstract

   This document specifies Protocol Independent Multicast Light (PIM
   Light) and PIM Light Interface (PLI) which does not need PIM Hello
   message to accept PIM Join/Prune messages.  PLI can signal multicast
   states over networks that can not support full PIM neighbor
   discovery, as an example BIER networks that are connecting two or
   more PIM domains.  This document outlines the PIM Light protocol and
   procedures to ensure loop-free multicast traffic between two or more
   PIM Light routers.

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 8 June 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Bidgoli, et al.            Expires 8 June 2025                  [Page 1]
Internet-Draft                  PIM Light                  December 2024

   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 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.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  PIM Light Interface . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  PLI supported Messages  . . . . . . . . . . . . . . . . .   4
     3.2.  Absence of Hello Message consideration  . . . . . . . . .   4
       3.2.1.  Join Attribute  . . . . . . . . . . . . . . . . . . .   4
       3.2.2.  DR Election . . . . . . . . . . . . . . . . . . . . .   5
       3.2.3.  PIM Assert  . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  PLI Configuration . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Failures in PLR domain  . . . . . . . . . . . . . . . . .   6
     3.5.  Reliable Transport Mechanism for PIM LIGHT  . . . . . . .   7
     3.6.  PIM Variants not supported  . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   This document specifies the Protocol Independent Multicast Light (PIM
   Light) and PIM Light Interface (PLI) procedures.  PLI is a new type
   of PIM interface that allows signaling of PIM Join/Prune packets
   without full PIM neighbor discovery.  PLI is useful in scenarios
   where multicast states needs to be signalled over networks or media
   that cannot support full PIM neighborship between routers or
   alternatively full PIM neighborship is not desired.  These type of
   networks or medias are addressed as a PIM Light Domain within this
   document.  Lack of full PIM neighborship will remove some PIM
   functionality as explained in section 3.2 of this document.  PIM
   Light only supports Protocol Independent Multicast Sparse Mode (PIM-
   SM) protocol including PIM Source-Specific Multicast (PIM-SSM) as per
   [RFC7761].  The document details procedures and considerations needed
   for PIM Light and PLI to ensure efficient routing of multicast groups

Bidgoli, et al.            Expires 8 June 2025                  [Page 2]
Internet-Draft                  PIM Light                  December 2024

   for specific deployment environments.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.1.  Definitions

   This document uses definitions used in Protocol Independent Multicast
   - Sparse Mode (PIM-SM): Protocol Specification [RFC7761]

3.  PIM Light Interface

   RFC [RFC7761] section 4.3.1 describes the PIM neighbor discovery via
   Hello messages.  In section 4.5 it describes that if a router
   receives a Join/Prune message from a particular IP source address and
   it has not seen a PIM Hello message from that source address, then
   the Join/Prune message SHOULD be discarded without further
   processing.

   In certain scenarios, it is desirable to establish multicast states
   between two layer-3 adjacent routers without forming a PIM
   neighborship.  This can be necessary for various reasons, such as
   signaling multicast states upstream between multiple PIM domains over
   a network that is not optimized for PIM or does not necessitate PIM
   Neighbor establishment.  For example, in a Bit Index Explicit
   Replication (BIER) [RFC8279] networks connecting multiple PIM
   domains, where PIM Join/Prune messages are tunneled via BIER as
   specified in [draft-ietf-bier-pim-signaling].

   A PIM Light Interface (PLI) accepts Join/Prune messages from an
   unknown PIM router without requiring a PIM Hello message from the
   router.  The absence of Hello messages on a PLI means there is no
   mechanism to discover neighboring PIM routers or their capabilities,
   nor to execute basic algorithms such as Designated Router (DR)
   election [RFC7761].  Consequently, the PIM Light router does not
   create any general-purpose state for neighboring PIM routers and only
   processes Join/Prune messages from downstream routers in its
   multicast routing table.  Processing these Join/Prune messages will
   introduce multicast states in a PIM Light router.

   Due to these constraints, a PLI should be deployed in very specific
   scenarios where PIM-SM is not suitable.  The applications or the
   networks that PLIs are deployed on MUST ensure there is no multicast

Bidgoli, et al.            Expires 8 June 2025                  [Page 3]
Internet-Draft                  PIM Light                  December 2024

   packet duplication, such as multiple upstream routers sending the
   same multicast stream to a single downstream router.  As an example
   the implementation should ensure that DR election is done on upstream
   Redundant PIM routers that are at the edge of the PIM Light Domain to
   ensure a single Designated Router to forward the PIM Join message
   from reviver to the Source.

3.1.  PLI supported Messages

   IANA [iana_pim-parameters_message-types], lists the PIM supported
   message types.  PIM Light only supports the following message types
   from the table "PIM Message Types"

   1.  type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed
       in [RFC7761].

   2.  type 1 (Register)

   3.  type 2 (Register Stop)

   4.  type 8 (Candidate RP Advertisement)

   5.  type 13 (PIM Packed Null-Register)

   6.  type 13.1 (PIM Packed Register-Stop)

   7.  Any future PIM message types that use unicast destination IP.

   No other message types are supported for PIM Light and MUST NOT be
   process if received on a PLI.

3.2.  Absence of Hello Message consideration

   In a PIM Light domain, the following considerations should be taken
   into account due to the lack of processing Hello messages.

3.2.1.  Join Attribute

   Since a PLI does not process PIM Hello messages, it also does not
   support the join attributes option in PIM Hello as specified in
   [RFC5384].  As such, PIM Light is unaware of its neighbor's
   capability to process join attributes and it SHOULD NOT process a
   join message containing it.

   For a PLI to send and process a join attributes there can be two
   cases:

Bidgoli, et al.            Expires 8 June 2025                  [Page 4]
Internet-Draft                  PIM Light                  December 2024

   1.  It must be configured with appropriate join attribute type that
       the PLI is capable of processing as per
       [iana_pim-parameters_join-attribute-types] table.

   2.  Separate IETF drafts or RFCs may dictate that certain join
       attributes are allowed to be used without explicit configuration
       of the PLI in certain scenarios.  The details are left to those
       drafts or RFCs.

3.2.2.  DR Election

   Due to the absence of Hello messages, DR Election is not supported on
   a PIM Light router.  The network design must ensure DR Election
   occurs within the PIM domain, assuming the PIM Light domain
   interconnects PIM domains.

                    Bier edge router       Bier edge router (BER)
           |--PIM Domain--|--BIER domain (PLI)--|--PIM domain--|
 Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host
           |       PIM Adj|         | |         |PIM Adj       |
           |------------( E )-------| |-------( F )------------|
                                          (DR Election)

   For instance, in a BIER domain connecting two PIM networks, a PLI can
   be used between BIER edge routers solely for multicast state
   communication and transmit only PIM Join/Prune messages.  If there
   are redundant PIM routers at the edge of the BIER domain, to prevent
   multicast stream duplication, they MUST establish PIM adjacency as
   per [RFC7761] to ensure DR election at the edge of BIER domain.  An
   example DR election could be DR election between router D and F in
   above figure.  When the Join or Prune message arrives from a PIM
   domain to the down stream BIER edge router, it can be forwarded over
   the BIER tunnel to the upstream BIER edge router only via the
   designated router.

3.2.3.  PIM Assert

   In scenarios where multiple PIM routers peer over a shared LAN or a
   Point-to-Multipoint medium, more than one upstream router may have
   valid forwarding state for a packet, potentially causing packet
   duplication.  PIM Assert is used to select a single transmitter when
   such duplication is detected.  According to [RFC7761] section 4.6,
   PIM Assert should only be accepted from a known PIM neighbor.

   In PIM Light implementations, care must be taken to avoid duplicate
   streams arriving from multiple upstream PIM Light routers to a single
   downstream PIM Light router.  If network design constraints prevent
   this, the implemented network architecture must take measures to

Bidgoli, et al.            Expires 8 June 2025                  [Page 5]
Internet-Draft                  PIM Light                  December 2024

   avoid traffic duplication.  For example, in a PIM Light over a BIER
   domain scenario, downstream IBBR (Ingress BIER Border Router) in a
   BIER domain can identify the nearest EBBRs (Egress BIER Border
   Routers) to the source using the Shortest Path First (SPF) algorithm
   with a post-processing as described in
   [draft-ietf-bier-pim-signaling] Appendix A.1.  If the downstream IBBR
   identifies two EBBRs, it can select one using a unique IP selection
   algorithm, such as choosing the EBBR with the lowest or highest IP
   address.  If the selected EBBR goes offline, the downstream router
   can use the next EBBR based on the IP selection algorithm, which is
   beyond the scope of this document.

3.3.  PLI Configuration

   Since a PLI doesn't require PIM Hello Messages and PIM neighbor
   adjacency is not checked for arriving Join/Prune messages, there
   needs to be a mechanism to enable PLI on interfaces.  If a router
   supports PIM Light, only when PLI is enabled on an interface,
   arriving Join/Prune messages MUST be processed, otherwise they MUST
   be dropped.  While on some logical interfaces PLI maybe enabled
   automatically or via an underlying mechanism, as an example the
   logical interface connecting two or more BIER edge routers in a BIER
   subdomain [draft-ietf-bier-pim-signaling].

3.4.  Failures in PLR domain

   Because the Hello messages are not processed on the PLI, PIM Light
   Interface failures may not be discovered in a PIM Light domain and
   multicast routes will not be pruned toward the source on the PIM
   Light domain, leaving the upstream routers continuously sending
   multicast streams until the outgoing interface (OIF) expires.

   Other protocols can be used to detect these failures in the PIM Light
   domain and they can be implementation specific.  As an example, the
   interface that PIM Light is configured on can be protected via
   Bidirectional Forwarding Detection (BFD) or similar technology.  If
   BFD to the far-end PLI goes down, and the PIM Light Router is
   upstream and has an OIF for a multicast route <S,G>, PIM must remove
   that PLI from its OIF list.

                         UBER                 DBER
           |--PIM Domain--|--BIER domain (PLI)--|--PIM domain--|
 Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host
                  <--Prune <S,G>          <failure on D>

   In another example, where the PLI is configured automatically between
   the BIER Edge Routers (BER), when the downstream BIER Edge Router
   (DBER) is no longer reachable on the upstream BIER Edge Router

Bidgoli, et al.            Expires 8 June 2025                  [Page 6]
Internet-Draft                  PIM Light                  December 2024

   (UBER), the UBER which is also a PIM Light Router can prune the <S,G>
   advertised toward the source on the PIM domain to stop the
   transmission of the multicast stream.

3.5.  Reliable Transport Mechanism for PIM LIGHT

   [RFC6559] defines a reliable transport mechanism for PIM transmission
   of Join/Prune messages, using either TCP or SCTP as transport
   protocol.  For TCP, PIM over reliable transport (PORT) uses port 8471
   which is assigned by IANA.  SCTP is explained in [RFC9260], and it is
   used as a second option for PORT.  [RFC6559] mentions that when a
   router is configured to use PIM over TCP on a given interface, it
   MUST include the PIM-over-TCP-Capable Hello Option in its Hello
   messages for that interface.  The same is true for SCTP and the
   router must include PIM-over-SCTP-Capable Hello Option in its Hello
   messsage on that interface.

   These Hello options contain a Connection ID which is an IPv4 or IPv6
   address used to establish the SCTP or TCP connection.  For PORT using
   TCP, the connection ID is used for determining which peer is doing an
   active transport open to the neighbor and which peer is doing passive
   transport open, as per section 4 of [RFC6559]

   When the router is using SCTP, the Connection ID IP address
   comparison need not be done since the SCTP protocol can handle call
   collision.

   PIM Light lacks Hello messages, the PLI can be configured with the
   Connection ID IPv4 or IPv6 addresses used to establish the SCTP or
   TCP connection.  For PIM Light using TCP PORT option each end of the
   PLI must be explicitly and correct configured as being active
   transport open or passive transport open to ensure handle call
   collision is avoided.

3.6.  PIM Variants not supported

   The following PIM variants are not supported with PIM Light and not
   covered by this document:

   1.  Protocol Independent Multicast - Dense Mode (PIM-DM)[RFC3973]

   2.  Bidirectional Protocol Independent Multicast (BIDIR-PIM)
       [RFC5015]

4.  IANA Considerations

   There are no new IANA considerations for this document.

Bidgoli, et al.            Expires 8 June 2025                  [Page 7]
Internet-Draft                  PIM Light                  December 2024

5.  Security Considerations

   Since PIM Light does not require PIM Hello messages and does not
   verify PIM neighbor adjacency for incoming Join/Prune messages, it is
   crucial for security reasons, that the implementation ensures only
   Join/Prune messages arriving at a configured PLI are processed.  Any
   Join/Prune messages received on an interface that is not configured
   as a PLI MUST be discarded and not processed.  Additionally, as a
   secondary line of defense, route policies SHOULD be implemented to
   process only the Join/Prune messages associated with the desired
   (S,G) pairs, while all other (S,G) pairs MUST be discarded and not
   processed.

   Furthermore, because PIM Light can be used for signaling Source-
   Specific and Sparse Mode Join/Prune messages, the security
   considerations outlined in [RFC7761] and [RFC4607] SHOULD be
   considered where appropriate.

   In section 6.1.1 of [RFC7761], only forged join/prune message should
   be considered as a potential attack vector, as PIM Light does not
   process Hello or Assert messages.  In addition, as detailed in
   Section 6.3, the authentication mechanisms described in [RFC5796] can
   be applied to PIM Light via IPsec Encapsulating Security Payload
   (ESP) or, optionally, the Authentication Header (AH).

6.  Acknowledgments

   Would like to thank Sandy <Zhang Zheng> and Tanmoy Kundu for their
   suggestions and contribution to this document.

7.  References

7.1.  Normative References

   [iana_pim-parameters_join-attribute-types]
              "", January 2022, <https://www.iana.org/assignments/pim-
              parameters/pim-parameters.xhtml#pim-parameters-2>.

   [iana_pim-parameters_message-types]
              "", January 2022, <https://www.iana.org/assignments/pim-
              parameters/pim-parameters.xhtml#message-types>.

   [RFC2119]  "S. Brandner, "Key words for use in RFCs to Indicate
              Requirement Levels"", March 1997.

   [RFC4607]  "H. Holbrook, B. Cain "Source-Specific Multicast for IP"".

Bidgoli, et al.            Expires 8 June 2025                  [Page 8]
Internet-Draft                  PIM Light                  December 2024

   [RFC5015]  "M. Handley, I. Kouvelas, T. Speakman, L. Vicisano
              "Bidirectional Protocol Independent Multicast"".

   [RFC5384]  "A. Boers, I. Wijnands, E. Rosen "PIM Join Attribute
              Format"", March 2016.

   [RFC5796]  "W. Atwood, S. Islam, M. Siami "Authentication and
              Confidentiality in PIM-SM"".

   [RFC6559]  "D. Farinacci, I. Wijnands, S. Venaas, M. Napierala "A
              reliable Transport Mechanism for PIM"".

   [RFC7761]  "B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh,
              Z.Zhang "PIM Sparse Mode"", March 2016.

   [RFC8174]  "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words"", May 2017.

   [RFC8279]  "Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T.
              and S.  Aldrin, "Multicast using Bit Index Explicit
              Replication"", October 2016.

   [RFC9260]  "R. Stewart, M. Tuxen, K. Nielsen, "Stream Control
              Transmission Protocol"", June 2022.

7.2.  Informative References

   [draft-ietf-bier-pim-signaling]
              "H.Bidgoli, F.XU, J. Kotalwar, I. Wijnands, M.Mishra, Z.
              Zhang, "PIM Signaling Through BIER Core"", July 2021.

   [RFC3973]  "A. Adams, J. Nicholas, W. Siadak, "Protocol Independent
              Multicast - Dense Mode"".

Authors' Addresses

   Hooman Bidgoli (editor)
   Nokia
   March Road
   Ottawa Ontario K2K 2T6
   Canada
   Email: hooman.bidgoli@nokia.com

Bidgoli, et al.            Expires 8 June 2025                  [Page 9]
Internet-Draft                  PIM Light                  December 2024

   Stig Venaas
   Cisco System, Inc.
   Tasman Drive
   San Jose, California 95134
   United States of America
   Email: stig@cisco.com

   Mankamana Mishra
   Cisco System
   Tasman Drive
   San Jose, California 95134
   United States of America
   Email: mankamis@cisco.com

   Zhaohui Zhang
   Juniper Networks
   Boston,
   United States of America
   Email: zzhang@juniper.com

   Mike McBride
   Futurewei Technologies Inc.
   Santa Clara,
   United States of America
   Email: michael.mcbride@futurewei.com

Bidgoli, et al.            Expires 8 June 2025                 [Page 10]