| Internet-Draft | PIM Flooding Mechanism and Source Discov | November 2024 |
| Gopal, et al. | Expires 7 May 2025 | [Page] |
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, Rendezvous Points 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.¶
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 7 May 2025.¶
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 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.¶
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). We can reduce the processing overhead for the router-pair having PIM neighborships over multiple links.¶
This document discusses two new improvements in PFM message exchanges between PIM routers.¶
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. Section 3 discusses the PFM message forwarding mechanism when the network is heterogeneous in terms of PFM TLV support.¶
Utilizing the PIM Router-IDs [RFC6395], PIM routers can limit PFM message exchanges to only on ONE link per router-pair, even though these two PIM routers may maintain PIM neighborships over multiple links. Note that this is applicable in cases where there are only two routers on each of the links between them - either a Point-Point link, or exactly 2 PIM neighbors on a LAN. In such cases, PFM can improve in performance by first identifying the PIM routers in the network using Router Identifiers [RFC6395] (Router-IDs) that are announced via PIM hellos. This enhancement allows PFM to limit message exchanges to only those that are necessary and 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.¶
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.¶
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.¶
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. Note that the support for this TLV Type TBD1 is advertised by PIM routers using Flag bit TBD4 in PIM Hello Option TBD2 and is discussed in detail in Section 3.2¶
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 = TBD1 | 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 |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
For the enhancements 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.¶
A PIM router indicates that it supports enhancement mechanisms 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 = TBD2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PFM optimization Hello option
¶
The "Flags" field indicates the PFM optimizations that the router supports. When Flags has bit TBD4 set, it indicates that the router is capable of exchanging PFM TLVs of Type TBD1 [Section 2].¶
When Flags has bit TBD5 set, it indicates that the router is capable of Relaxed-RPF optimization, which means that it will be relaxing the RPF check for PFM messages under conditions discussed in [Section 4.2]. It is referred to as the Relaxed-RPF optimization throughout the document.¶
The remaining bits in the Flags field are reserved and MUST transmitted as zero and MUST be ignored on receipt. When a PIM hello with OptionType TBD1 is received from a PIM neighbor, the router MUST cache and/or update this information so that it can make forwarding and dropping decisions for PFM messages for that neighbor. When OptionType TBD1 is included, the router MUST also cache the non-zero Router-ID of this neighbor.¶
All PIM routers MUST track whether a specific optimization (e.g., TBD4, TBD5) is supported by all PIM neighbors on each PIM interface. This tracking is beneficial in heterogeneous networks where only certain routers support the new TLV Type TBD. Additionally, it is RECOMMENDED that only Type TBD1 be used if support is available, to avoid unnecessary processing. It is RECOMMENDED that routers use both optimizations defined in the document.¶
Consider a router that is advertising its capability to optimize PFM exchanges in the network with Hello Option TBD3 [Section 3.2] and Option Values TBD4 and TBD5 to all its PIM neighbors. It MUST simultaneously track whether a specific optimization (e.g., TBD4, TBD5) is advertised by all PIM neighbors on each PIM interface. This information, along with each neighbors' Router-IDs and optimization support on each interface will enable this router to make improved forwarding decisions for PFM messages. It is left to the implementation to track neighbors' optimization support. It is RECOMMENDED that routers use both optimizations defined in the document. However, different message handling scenarios are discussed below.¶
When a router sends a PIM Hello with OptionType TBD2 with Flag Bit TBD4 set, it is indicating to its PIM neighbor that it is capable of exchanging PFM TLVs of Type TBD1 which enables the router to send more information about each (S, G).¶
Consider a router capable of exchanging PFM Type TBD1 TLVs. It MUST do the following:¶
It MUST advertise its capability by sending PIM Hello with OptionType TBD2 with Flag Bit TBD4 set.¶
It MUST track whether all neighbors on each of its PIM interfaces support this new TLV. Scope of this tracking is left to the implementation. It MAY track this information even if the capability on itself is removed.¶
If this router is an FHR, while originating a PFM message, it MUST originate a Type TBD1 TLV if all neighbors on the PIM interface support Type TBD.¶
If this router is an FHR, while originating a PFM message, it MUST originate a Type 1 TLV [RFC8364] if at least 1 neighbor on the PIM interface does not support Type TBD.¶
On the receipt of a Type TBD1 TLV on a Type TBD1-capable intermediate router, this router MUST forward the PFM message as is on the PIM interfaces where all neighbors support this new type.¶
If there are PIM interfaces where at least one router does not support the new TLV, an intermediate router that supports Type TBD1 MUST convert the Type TBD1 TLV to Type 1 TLV [RFC8364] and forward it on those interfaces. The conversion mechanism is largely left to the implementation, however in a nutshell, the router MUST create and send TLV Type 1 with the source group and holdtime from the Type TBD1 and ignore the sub-tlvs. Also, if there are multiple sources for the same group, then they should be put together in one TLV and sent as Type 1.¶
When a router sends a PIM Hello with OptionType TBD2 and Flag Bit TBD5 set, it signals to its PIM neighbor that it can optimize forwarding between them if they are the only two neighbors on all connecting links between them.¶
Consider a topology where two PIM routers maintain multiple PIM neighborships over several links within the same PIM domain — and are the only two routers on these links - either a Point-to-Point link, or 2 PIM neighbors on a LAN. 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 Relaxed-RPF optimization is advertised by both routers, the sender MUST 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 Relaxed-RPF optimization. Otherwise, the messages may be dropped because of RPF failures. The mechanism to choose a link is left to the implementation.¶
When a router that supports the Relaxed-RPF optimization receives a PFM message, it MUST first verify if the sender supports Relaxed-RPF optimization. If true, the receiver MUST relax its RPF check and accept the message. Additionally, the receiver MUST record the sender's router ID to prevent forwarding the message back to the sender on any other link. However, if the sender does not advertise the Relaxed-RPF optimization specified in this document and the receiver has enabled Relaxed-RPF, the receiver SHOULD NOT relax its RPF check, as the sender will still transmit messages across all connecting links.¶
The optimization mechanism relies heavily on a router's insight into whether all neighbors on each PIM interface support the TLV Type TBD1 and/or Relaxed-RPF optimization. Therefore the following scenarios MUST be handled:¶
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.¶
TBD any security considerations for forwarding optimizations.¶
This document requires the assignment of a new PFM TLV Type TBD1 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]
1-65535 Unassigned
¶
This document requires the assignment of a new PIM Hello Option TBD2 with OptionLength 4, and a 32-bit OptionValue "Flags" for indicating the PFM optimization Hello options in the PIM-Hello Options Registry.¶
This document requires the assignment of the following new values for OptionValue "Flags" for the PIM Hello Option(TBD2).¶
Flags Name Reference
------------------------------------------------------
0 Reserved [this document]
TBD4 Type TBD1 TLV support
TBD5 Relaxed-RPF optimization
support
Remaining
bits Reserved
¶