PIM Flooding Mechanism Enhancements
draft-gopal-pim-pfm-forwarding-enhancements-02

Network Working Group                                           A. Gopal
Internet-Draft                                                 S. Venaas
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: 5 September 2024                                   4 March 2024

                  PIM Flooding Mechanism Enhancements
             draft-gopal-pim-pfm-forwarding-enhancements-02

Abstract

   PIM Flooding Mechanism is a generic PIM message exchange mechanism
   that allows multicast information to be exchanged between PIM routers
   hop-by-hop.  One example is PIM Flooding Mechanism and Source
   Discovery which allows Last Hop Routers to learn about new sources
   using PFM messages, without the need of initial data registers, RPs
   or shared trees.

   This document defines a methodology that enhances forwarding
   efficiency in PFM deployments.  This enhancement can avoid extra
   processing at PIM routers when PFM messages are forwarded.

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 5 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

Gopal & Venaas          Expires 5 September 2024                [Page 1]
Internet-Draft     PIM Flooding Mechanism Enhancements        March 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Methodology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  RFC 6395 Compliance . . . . . . . . . . . . . . . . . . .   3
     2.2.  PFM optimization Hello option . . . . . . . . . . . . . .   3
     2.3.  PFM message sending . . . . . . . . . . . . . . . . . . .   4
     2.4.  PFM message receiving and RPF check relaxation  . . . . .   5
     2.5.  PFM message forwarding  . . . . . . . . . . . . . . . . .   5
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
   4.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   PIM Flooding Mechanism [RFC8364] allows a PIM router in the network
   to originate a PFM message to distribute multicast information to its
   PIM neighbors [RFC7761] . All PIM neighbors then process this PFM
   message and flood it further on their PIM-enabled links.  To prevent
   loops, the originator address as defined in Section 3.1 [RFC8364] is
   used for RPF checking at each router.  This RPF check is defined in
   Section 3.4.1 [RFC8364].  Periodic PFM messages are triggered, see
   Section 3.4.2 [RFC8364] and exchanged to keep the multicast
   information updated across the PIM domain.  At present, a PIM router
   will flood a PFM message on all its PIM enabled links.  It is the
   recipient's responsibility to perform RPF checks on all received PFM
   messages and then decide whether to accept or drop a particular
   message.  This means that if two routers have PIM neighborships over
   more than one link, the same PFM messages are exchanged or dropped
   over more than one link between the same two routers.  This leads to
   extra processing at each PIM router, periodically, or every time a
   new source is discovered (in case of a PFM-SD implementation).  This
   document defines a mechanism to exchange PFM messages only on one ONE
   link per router-pair, even though they may maintain PIM neighborships
   over multiple links.  In other words, when there are multiple links
   between two PIM routers, routers should not send the same message on
   all the links between them.  This is achieved by identifying the PIM
   routers in the network using Router Identifier that are announced via
   PIM hellos, as per RFC 6395.

Gopal & Venaas          Expires 5 September 2024                [Page 2]
Internet-Draft     PIM Flooding Mechanism Enhancements        March 2024

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

1.2.  Terminology

   RP:  Rendezvous Point

   RPF:  Reverse Path Forwarding

   PFM:  PIM Flooding Mechanism

2.  Methodology

2.1.  RFC 6395 Compliance

   For the PFM enhancement specified in this document to be adopted, all
   PIM routers MUST be compliant with RFC [RFC6395].  This means that
   PIM routers announce a unique domain-wide router ID in their PIM
   Hellos.  A PIM router announces the same 4-byte Router-ID in PIM
   Hellos that it sends to all neighbors on all links.  It also caches
   of the Router-Ids of its neighbors, when it receives Hellos from RFC
   6395 Compliant PIM neighbors.  This can be used to determine that
   different PIM neighbors are really the same router.  In a VRF
   context, if the router has multiple interfaces with only one neighbor
   per interface, the router SHOULD check if those neighbors announce an
   RFC 6395 router ID.  If the router can see the same router ID for
   multiple neighbors, PFM message exchange is optimized, as discussed
   in Section 2.

2.2.  PFM optimization Hello option

   A PIM router indicates that it supports the mechanism specified in
   this document by including the new PFM optimization Hello option.
   When this optimization is included in the PIM hello, the router MUST
   also include the router-ID Hello Option defined in [RFC6395] with a
   non-zero router-ID.

Gopal & Venaas          Expires 5 September 2024                [Page 3]
Internet-Draft     PIM Flooding Mechanism Enhancements        March 2024

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        OptionType             |       OptionLength = 0        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 1: PFM optimization Hello option

   OptionType = TBD

   OptionLength = 0

   Note that there is no option value included.  When a PIM hello with
   OptionType TBD is received from a PIM neighbor, the router MUST cache
   this information so that it can make forwarding and dropping
   decisions for PFM messages for that neighbor.  When this option is
   included, the router MUST also cache the non-zero router-ID of this
   neighbor.

2.3.  PFM message sending

   Consider a topology where two PIM routers maintain PIM neighborships
   over more than one links in the same PIM domain.  From each router's
   point of view, there is a single neighbor on each link.
   Traditionally, each of the routers will send out PFM messages out
   over all the links to its neighbor.  RPF checks are one of the
   commonly used ways to prevents loops, hence the recipient router
   performs an RPF check and accepts only on one link, thereby dropping
   packets from all the others.  Since, the sender does not know which
   link will be chosen as the RPF-source on the neighbor, it cannot make
   the decision of choosing one of the links, without knowing its
   neighbor's decision.

   If the optimization specified in this document is advertised by both
   routers, the sender should choose one of the links and send and
   forward PFM messages to its neighbor using only that link.  It is
   imperative that the sender does this only when the receiver is
   capable of the optimization and is advertising the same.  Otherwise,
   the messages may be dropped because of RPF failures.  Mechanism to
   choose a link is left to the implementation.

Gopal & Venaas          Expires 5 September 2024                [Page 4]
Internet-Draft     PIM Flooding Mechanism Enhancements        March 2024

2.4.  PFM message receiving and RPF check relaxation

   Consider a router that is advertising its capability to optimize PFM
   exchanges in the network.  Upon receiving a PFM message, this router
   MUST first check whether this message is sent by a PFM optimization
   enabled router.  If the check returns true, the receiver should relax
   its RPF check and accept the message.  When a PFM message is
   received, the receiver SHOULD keep track of the router ID of the
   sender, so that the receiver does not forward the message back to the
   sender on any other link, as explained in the next section.  If it
   receives this message from a router that is not advertising the PFM
   optimization specified in this document, however the optimization is
   enabled on the receiver, the receiver SHOULD NOT relax its RPF check.
   This is because the sender will be still sending out messages on all
   the links between them.

2.5.  PFM message forwarding

   Traditionally, a PIM router forwards a PFM message on all its PIM
   enabled links.  However, this is now optimized.  Consider a router
   that is advertising its capability to optimize PFM exchanges in the
   network.  When this router receives a PFM message from a router that
   also has the PFM optimization enabled, the forwarding mechanism is as
   follows.  The receiver MUST NOT send the PFM message on out on any
   links where there is only one neighbor and the neighbor has the same
   router ID as the sender.

3.  Operational Considerations

   Existing neighbor on a new link:  When a new neighbor is detected
      announcing support for the optimization and announcing a non-zero
      router ID, and it is the only neighbor on the link, a PIM router
      needs to check if there is an existing neighbor on another link
      with the same router ID (it does not need to be the sole neighbor
      on the other link).  A mechanism SHOULD be implemented to prevent
      PFM messages being sent on this link.

   New neighbor on a new link:  Appropriate logic SHOULD be implemented
      to handle new neighbor additions so that extra messages are not
      forwarded to same neighbor, as well as ensuring that a new
      neighbor quickly gets the correct state.

   Removal of a neighbor:  Appropriate logic SHOULD also be implemented
      to handle neighbor removals.

Gopal & Venaas          Expires 5 September 2024                [Page 5]
Internet-Draft     PIM Flooding Mechanism Enhancements        March 2024

4.  Acknowledgments

5.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

   [RFC8364]  Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM
              Flooding Mechanism (PFM) and Source Discovery (SD)",
              RFC 8364, DOI 10.17487/RFC8364, March 2018,
              <https://www.rfc-editor.org/info/rfc8364>.

   [RFC6395]  Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
              Hello Option for PIM", RFC 6395, DOI 10.17487/RFC6395,
              October 2011, <https://www.rfc-editor.org/info/rfc6395>.

Authors' Addresses

   Ananya Gopal
   Cisco Systems, Inc.
   Tasman Drive
   San Jose,  CA 95134
   United States of America
   Email: ananygop@cisco.com

   Stig Venaas
   Cisco Systems, Inc.
   Tasman Drive
   San Jose,  CA 95134
   United States of America
   Email: svenaas@cisco.com

Gopal & Venaas          Expires 5 September 2024                [Page 6]