Internet-Draft PIM Flooding Mechanism and Source Discov June 2024
Gopal, et al. Expires 15 December 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-gopal-pim-pfm-forwarding-enhancements-03
Published:
Intended Status:
Experimental
Expires:
Authors:
A. Gopal
Cisco Systems, Inc.
S. Venaas
Cisco Systems, Inc.
F. Meo

PIM Flooding Mechanism and Source Discovery Enhancements

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 for initial data registers, RPs or shared trees.

This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. This document also defines methodologies that enhance forwarding efficiency in PFM-SD deployments.

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 15 December 2024.

▲

Table of Contents

1. Introduction

PIM Flooding Mechanism [RFC8364] allows a PIM router in the network to originate a PFM message to distribute announcements of active sources 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.

First of all, PFM-SD does not allow the distribution of anything except for the announcements of active sources. However, it may be useful to provide additional information about flows in PFM [RFC8364] source announcements.

Secondly, 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 discusses two new improvements in PFM message exchanges between PIM routers.

  1. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used providing various types of information. This enhancement is discussed in detail in Section 2.

  2. Utilizing the PIM Router-IDs [RFC6395], PFM can limit the PFM messages exchanges to only on ONE link per router-pair, even though these PIM routers 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 Identifiers [RFC6395] that are announced via PIM hellos. This enhancement is discussed in detail in Section 3.

Any existing PFM deployment MAY choose to implement one or both enhancements, however it is RECOMMENDED to implement both.

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-SD:
PIM Flooding Mechanism and Source-Discovery

2. PIM PFM Sub-TLV

PFM-SD [RFC8364] defines a Group Source Holdtime (GSH) TLV for announcing active sources. However, it could be beneficial for PIM routers to exchange additional data about these sources.

2.1. Group Source Info TLV

This document defines a new Group Source Info (GSI) TLV that is used similarly to the GSH TLV except that it only provides info for a single source, and includes additional information about the flow in Sub-TLVs.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|         Type = TBD            |          Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Group Address (Encoded-Group format)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Source Address (Encoded-Unicast format)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Holdtime           |        Type Sub-TLV 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Length Sub-TLV 1        |       Value Sub-TLV 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   |        Type Sub-TLV n         |       Length Sub-TLV n        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Value Sub-TLV n                                        |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T:
If the Transitive bit is set to 0, a router MUST NOT forward the message unless it supports this TLV and all the Sub-TLVs that are present in the TLV in this message. If the transitive bit is set to 1, it is forwarded even if the router does not support the TLV or all the Sub-TLVs present.
Type:
This TLV has type TBD.
Length:
The length of the value in octets.
Group Address:
The group that sources are to be announced for. The format for this address is given in the Encoded-Group format in [RFC7761].
Source Address:
The source address for the corresponding group. The format for this address is given in the Encoded-Unicast address in [RFC7761].
Holdtime:
The Holdtime (in seconds).
Type Sub-TLV 1..n:
The TLV contains n Sub-TLVs, n MAY be 0. The total length of the TLV (the Length field) is used to derive how many octets are used for Sub-TLVs. It will be at least 4 * n octets if n Sub-TLVs are present. Type Sub-TLV indicates the type of the Sub-TLV. The allowed types are Sub-TLV types that are specifically defined for use in the Group Source Info TLV. This document defines one such Sub-TLV type.
Length Sub-TLV 1..n:
The length of the Sub-TLV Value field in octets.
Value Sub-TLV 1..n:
The value of the Sub-TLV associated with the type and of the specified length.

3. PIM PFM forwarding optimization

3.1. RFC 6395 Compliance

For this enhancement defined 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 the Router-Ids of its neighbors, when it receives Hellos from [RFC6395] 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.

3.2. PFM optimization Hello option

A PIM router indicates that it supports the first enhancement 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.

   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.

3.3. PFM message sending

Consider a topology where two PIM routers maintain PIM neighborships over more than one link 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 prevent 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 choose 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. The sender MUST do 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. The mechanism to choose a link is left to the implementation.

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

3.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 out on any links where there is only one neighbor and the neighbor has the same router ID as the sender.

4. Operational Considerations

With respect to PIM PFM forwarding optimization, the following considerations apply:

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

5. Security Considerations

When it comes to general PIM message security, see [RFC7761]. For PFM security see [RFC8364].

This document defines a new format allowing for additional flow information. One concern is what happens if wrong information is provided by accident, or intentionally in a spoofed message by an attacker. The impact depends on what information is provided.

6. IANA Considerations

This document requires the assignment of a new PIM Hello Option for indicating the PFM optimization Hello option in the PIM-Hello Options Registry.

This document requires the assignment of a new PFM TLV type in the "PIM Flooding Mechanism Message Types" registry. Also, a new registry "PFM Group Source Info Sub-Types" registry needs to be created. Assignments for the new registry are to be made according to the policy "IETF Review" as defined in [RFC8126]. The initial content of the registry should be:

 Sub-Type         Name                  Reference
------------------------------------------------------
     0        Reserved               [this document]
  2-32767     Unassigned

7. Acknowledgments

8. Normative References

[RFC6395]
Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) Hello Option for PIM", RFC 6395, DOI 10.17487/RFC6395, , <https://www.rfc-editor.org/info/rfc6395>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[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, , <https://www.rfc-editor.org/info/rfc7761>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8364]
Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM Flooding Mechanism (PFM) and Source Discovery (SD)", RFC 8364, DOI 10.17487/RFC8364, , <https://www.rfc-editor.org/info/rfc8364>.

Authors' Addresses

Ananya Gopal
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
United States of America
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
United States of America
Francesco Meo