PIM Light
draft-ietf-pim-light-02

Network Working Group                                    H. Bidgoli, Ed.
Internet-Draft                                                     Nokia
Intended status: Standards Track                               S. Venaas
Expires: 29 August 2024                               Cisco System, Inc.
                                                               M. Mishra
                                                            Cisco System
                                                                Z. Zhang
                                                        Juniper Networks
                                                              M. McBride
                                             Futurewei Technologies Inc.
                                                        26 February 2024

                               PIM Light
                        draft-ietf-pim-light-02

Abstract

   This document specifies a new Protocol Independent Multicast
   interface which does not need PIM Hello to accept PIM Join/Prunes.

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 29 August 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
   and restrictions with respect to this document.  Code Components

Bidgoli, et al.          Expires 29 August 2024                 [Page 1]
Internet-Draft                  PIM Light                  February 2024

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

1.  Introduction

   It might be desirable to create a PIM interface between routers where
   only PIM Join/Prunes packets are signaled over it without having a
   full PIM neighbor discovery.  As an example, this type of PIM
   interface can be useful in some scenarios where the multicast state
   needs to be signaled over a network or medium which is not capable of
   or has no need for creating full PIM neighborship between its Peer
   Routers.  These type of PIM interfaces are called PIM Light
   Interfaces (PLI).

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.

Bidgoli, et al.          Expires 29 August 2024                 [Page 2]
Internet-Draft                  PIM Light                  February 2024

2.1.  Definitions

   This draft uses definitions used in [RFC7761]

3.  PIM Light Interface

   RFC [RFC7761] section 4.3.1 describes the PIM neighbor discovery via
   Hello messages.  It also describes that PIM Join/Prune are not
   accepted from a router unless a Hello message has been seen from that
   router.

   In some scenarios it is desirable to communicate and build multicast
   states between two L3 adjacent routers without establishing a PIM
   neighborship.  There could be many reasons for this desired, but one
   example is the desired to signal multicast states upstream, between
   two or more PIM Domains via a network or medium that is not optimized
   for PIM or does not require PIM Neighbor establishment.  An example
   is a BIER network connecting multiple PIM domains.  In these BIER
   networks PIM Join/prune messages are tunneled via bier as per
   [draft-ietf-bier-pim-signaling].

   A PIM Light Interface (PLI) ONLY accepts Join/Prune messages from an
   unknown PIM router and it accepts these messages without receiving a
   PIM Hello message form the router.  Lack of Hello Messages on a PLI
   means there is no mechanism to learn about the neighboring PIM
   routers on each interface and their capabilities or run some of the
   basic algorithms like DR Election between the routers.  As such the
   PIM light router doesn't create any General-Purpose state for
   neighboring PIM and it only process Join/Prune message from
   downstream routers in its multicast routing table.

   Because of this, a PLI needs to be created in very especial cases and
   the application that is using these PLIs should ensure there is no
   multicast duplication of packets.  As an example, multiple upstream
   routers sending the same multicast stream to a single downstream
   router.

3.1.  PLI supported Messages

   As per IANA [iana_pim-parameters] PIM supports more than 12 message
   types, PIM Light only supports message type 3 (Join/Prune) from the
   ALL-PIM-ROUTERS message types listed in RFC7761, other unicast
   destination message types are supported by PIM light.  All other
   message types are not supported for PIM Light and should not be
   process if received on a PLI.

Bidgoli, et al.          Expires 29 August 2024                 [Page 3]
Internet-Draft                  PIM Light                  February 2024

3.2.  Lack of Hello Message consideration

   The following should be considered on a PIM Light domain since hello
   messages are not processed.

3.2.1.  Join Attribute

   Since PLI does not process the pim hello message, processing of the
   join attributes option in pim hello as per [RFC5384] is also not
   supported, leaving PIM Light unaware of its neighbor capability of
   processing the join attribute.  A PIM Light Router that does not
   understand the type 1 Encoded-source Address and per [RFC7761] should
   not process a join message that contains it.  Otherwise the PLI can
   process the Join Attribute accordingly.

3.2.2.  DR Selection

   Since DR Election is not supported on PIM Light because of lack of
   hello messages, the network design should ensure that DR Election is
   achieve on the PIM domain, assuming the PIM Light domain is
   connecting PIM domains.

   As an example, in a BIER domain which is connecting 2 PIM networks, a
   PLI can be used between the BIER edge routers.  The PLI will be only
   used for multicast states communication, by transmitting ONLY PIM
   Join/prunes over the BIER domain.  In this case to ensure there is no
   multicast stream duplication the PIM routers attached on each side of
   the BIER domain might want to establish PIM Adjacency via [RFC7761]
   to ensure DR election on the edge of the BIER router, while PLI is
   used in the BIER domain, between BIER edge routers.  When the Join or
   Prune message arrives from a PIM domain to the down stream BIER edge
   router, it can be send over the BIER tunnel to the upstream BIER edge
   router only via the selected designated router.

3.2.3.  PIM Assert

   Where multiple PIM routers peer over a shared LAN or a Point-to-
   Multipoint medium, it is possible for more than one upstream router
   to have valid forwarding state for a packet, which can lead to packet
   duplication.  When this is detected PIM Assert is used to select one
   transmitter.  That said as per [RFC7761] PIM Assert should only be
   accepted if it comes from a known PIM neighbor.  With PIM LIGHT the
   implementation SHOULD ensure there is no duplicate streams arriving
   from upstream PIM Light routers to a single downstream PIM LIGHT
   router.  If this condition is not possible to be met because of
   network design, the implementation should ensure there is no
   duplication of stream.  As an example in PIM LIGHT over a BIER domain
   implementation, for IBBR (Down stream PIM LIGHT router) in a BIER

Bidgoli, et al.          Expires 29 August 2024                 [Page 4]
Internet-Draft                  PIM Light                  February 2024

   domain to find the EBBRs closes to the source (upstream PIM LIGHT
   routes), SPF can be use with a post processing as per
   [draft-ietf-bier-pim-signaling] Appendix A.1.  With this post
   processing if 2 EBBRs are found by the downstream IBBR, then this
   down stream IBBR router can choose one of the EBBRs with a unique IP
   selection algorithm.  As an example the EBBR with lowest IP address
   or largest IP address can be the EBBR that the downstream PIM LIGHT
   (IBBR) router sends the join/prune message to.  When this EBBR goes
   offline the downstream router can send the join to the next EBBR
   based on the IP selection algorithm.  This IP selection algorithm is
   outside of scope of this draft.

3.3.  PLI Configuration

   Since a PLI doesn't require PIM Hello Messages and PIM neighbor
   adjacency is not checked for join/prune messages, there needs to be a
   mechanism to enable PLI on interfaces for security purpose, while on
   some other interfaces this may be enabled automatically.  An example
   of the latter is the logical interface for a BIER sub-domain
   [draft-ietf-bier-pim-signaling].

   If a system explicitly needs a PLI to be configured, then this system
   should not accepts the Join/Prune messages on interfaces that the PLI
   is not configured on, and it should drop these messages on a non PLI
   interface.  If the system automatically enables PLI on some special
   interfaces, as an example interfaces facing a BIER domain, then it
   should accept Join/Prune messages on these interfaces only.

3.4.  Failures in PLR domain

   Because the hello messages are not processed on the PLI, some
   failures may not be discovered in PLI domain and multicast routes
   will not be pruned toward the source on the PIM domain, leaving the
   upstream routers continuously sending multicast streams until the out
   going 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 BFD or
   similar technology.  If BFD to the far-end PLI goes down, and the Pim
   Light Router is upstream and is an OIF for a multicast route <S,G>,
   PIM should remove that PLI from its OIF list.  In addition if
   upstream PLI is configured automatically, as an example in BIER case,
   when the downstream BFR is no longer reachable, the upstream PIM
   Light Router can prune the <S,G> advertised by that BFR, toward the
   source to stop the transmission of the multicast stream.

Bidgoli, et al.          Expires 29 August 2024                 [Page 5]
Internet-Draft                  PIM Light                  February 2024

3.5.  Reliable Transport Mechanism for PIM LIGHT

   [RFC6559] defines a reliable transport mechanism for PIM transmission
   of Join/Prune messages.  PIM over reliable transport (PORT) uses TCP
   port 8471 which is assigned by IANA.  [RFC6559] mandates that if a
   router is configured to use PIM over TCP or SCTP on a given interface
   it must include the PIM-over-TCP-Capable or PIM-over-SCTP-Capable
   hello option in its Hello messages for that interface.  These options
   also communicate the connection ID of TCP for the appropriate address
   family.  PIM light lacking Hello messages, can be configured to use
   PORT under a PLI.  That said the TCP connection ID of local router
   and peer router has to be configured manually under each side of the
   PLI.  The PLI uses these local and peer connection ID to setup a TCP
   connection.  As per [RFC6559] section 4 the routers use the
   connection IDs to figure out which side will do a passive transport
   open and which side of the PLI with do a active open.  If TCP
   connection failed to open then PLI will revert back to Datagram mode.

4.  IANA Considerations

5.  Security Considerations

   Since PIM Light can be used for signaling Source-Specific and Sparse
   Mode Join/Prune messages, security considerations of [RFC7761] and
   [RFC4607] SHOULD be considered.

   It should be noted a PIM Light can also use [RFC5796] as indicated in
   [RFC7761] for authentication.

6.  Acknowledgments

   Would like to thank Sandy <Zhang Zheng> for her suggestions and
   contribution to this draft.

7.  References

7.1.  Normative 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.

   [iana_pim-parameters]
              "", January 2022.

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

Bidgoli, et al.          Expires 29 August 2024                 [Page 6]
Internet-Draft                  PIM Light                  February 2024

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

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

7.2.  Informative References

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

Authors' Addresses

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

   Stig
   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

Bidgoli, et al.          Expires 29 August 2024                 [Page 7]
Internet-Draft                  PIM Light                  February 2024

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

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

Bidgoli, et al.          Expires 29 August 2024                 [Page 8]