[pim] [Shepherding AD review] Pre IETF Last-Call review of draft-ietf-pim-pfm-forwarding-enhancements-03

["Gunter van de Velde (Nokia)" <[e-mail]>]

Hi Authors, WG,

# Gunter Van de Velde, RTG AD, comments for draft-ietf-pim-pfm-forwarding-enhancements-03

# line numbers are rendered from the idnits tool found at https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-pfm-forwarding-enhancements-03.txt

# Many thanks for the shepherd writeup from Michael McBride and for confirming that the document is within PIM WG charter.

# To document Shepherd, can the motivation of making the intended document state 'experimental' be added to the shepherd write-up? Is it an experiment? If yes, can the experiment scope and context be explained?

# I believe that the document is close to ready to be progressed. In the following sections I have few questions and proposed a few revised text proposals to consider.

# COMMENTS
#=========

13       PIM Flooding Mechanism is a generic PIM message exchange mechanism
14       that allows multicast information to be exchanged between PIM routers

GV>s/mechanism/procedure/

11    Abstract
12
13       PIM Flooding Mechanism is a generic PIM message exchange mechanism
14       that allows multicast information to be exchanged between PIM routers
15       hop-by-hop.  One example is PIM Flooding Mechanism and Source
16       Discovery which allows last hop routers to learn about new sources
17       using PFM messages, without the need for initial data registers,
18       Rendezvous Points or shared trees.
19
20       This document defines a new TLV for announcing sources that allows
21       for Sub-TLVs that can be used to provide various types of
22       information.  This document also defines methodologies that enhance
23       forwarding efficiency in PFM deployments.

GV> What about the following alternatove abstract text:

"
The Protocol Independent Multicast (PIM) Flooding Mechanism (PFM) provides a generic hop-by-hop message exchange framework for distributing multicast information among PIM routers. Existing PFM procedures enable efficient source discovery without reliance on Rendezvous Points, shared trees, or initial data registers.

This document specifies enhancements to PFM forwarding behavior to improve efficiency and scalability. In particular, it introduces mechanisms to reduce redundant message transmission over multiple parallel links and extends the encoding of multicast information through additional Type-Length-Value (TLV) structures and sub-TLVs to convey richer flow-related data.

These enhancements optimize control-plane overhead while preserving interoperability with existing PFM procedures, enabling more efficient dissemination of multicast state in PIM networks.
"

80       to originate a PFM message to distribute announcements of active

GV> expand PFM at first usage. Note that RFC editor uses the following list https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list to check if the abreviation needs to be expanded or not.

84       Section 3.1 [RFC8364] is used for RPF checking at each router.  This

GV> Please expand RPF at first usage

85       RPF check is defined in Section 3.4.1 [RFC8364].  Periodic PFM
86       messages are triggered, see Section 3.4.2 [RFC8364] and exchanged to

GV> There seems a contradiction in this text. First it says periodic, which means to em that periodically something happens, and that is repetitive, and then it says triggered, which means that something is done outside pof the periodical windows. I suspect the phrase will need some restructiring to convey its intent


89       Firstly, the TLV used by PFM [RFC8364] for source discovery only
90       specifies source and group information to announce an active source.
91       There is no convenient way to provide additional information about a
92       flow.
93
94       Secondly, a PIM router will flood a PFM message on all its PIM
95       enabled links.  It is the recipient's responsibility to perform RPF
96       checks on all received PFM messages and then decide whether to accept
97       or drop a particular message.  This means that if two routers have
98       PIM neighborships over more than one link, the same PFM messages are
99       exchanged or dropped over more than one link between the same two
100      routers.  This leads to extra processing at each PIM router,
101      periodically, or every time a new source is discovered (in case of a
102      PFM-SD implementation).  We can reduce the processing overhead for
103      the router-pair having PIM neighborships over multiple links.
104
105      This document discusses two new improvements in PFM message exchanges
106      between PIM routers.
107
108      1.  This document defines a new TLV for announcing sources that
109          allows for Sub-TLVs that can be used for providing various types
110          of information.  This enhancement is discussed in detail in
111          Section 2.
112
113      2.  By leveraging PIM Router-IDs [RFC6395], PIM routers can optimize
114          PFM message exchanges when they maintain multiple neighborships
115          with the same peer router.  This optimization is particularly
116          beneficial for router pairs connected via several links.  When
117          two routers are the sole neighbors on multiple Point-to-Point
118          links, they need not exchange identical PFM messages across all
119          these links.  Instead, PFM can achieve performance improvements
120          by utilizing Router Identifiers [RFC6395] (Router-IDs) announced
121          in PIM Hello messages to identify such scenarios and restrict
122          message exchanges to a subset of available links.  This
123          enhancement is detailed in Section 3.  Note that PFM message
124          behavior on shared LANs, where there are more than one neighbor
125          on the same link, remains unchanged.
126
127      These are independent enhancements and an implementation could
128      support one but not the other, however it is RECOMMENDED to implement
129      both.

"
The TLV defined in [RFC8364] for source discovery conveys only source and group information. It does not provide a mechanism to include additional attributes describing a multicast flow.

In addition, PFM messages are flooded on all PIM-enabled links. When two routers maintain multiple adjacencies, identical PFM messages are transmitted across each link. Receivers perform RPF checks and discard duplicates as needed. This behavior introduces unnecessary processing overhead, both periodically and upon source discovery.

This document defines two independent enhancements to PFM message exchange:

1) A new TLV that supports Sub-TLVs, enabling the inclusion of additional flow-related information. This enhancement is specified in Section 2.

2) An optimization for PFM message exchange across multiple adjacencies between the same pair of routers. By leveraging PIM Router-IDs [RFC6395], routers can identify such adjacencies and limit message transmission to a subset of links, reducing redundant processing. This optimization applies to point-to-point links and does not alter behavior on shared media. This enhancement is specified in Section 3.

Implementations MAY support these enhancements independently; however, support for both is RECOMMENDED.
"

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

GV>

"
PFM-SD [RFC8364] defines the Group Source Holdtime (GSH) TLV for announcing active sources. The GSH TLV conveys only source and group information. This document defines an extension that allows PIM routers to exchange additional information associated with multicast sources.
"

157      This document defines a new Group Source Info (GSI) TLV that is used
158      similarly to the GSH TLV except that it only provides info for a
159      single source, and includes additional information about the flow in
160      Sub-TLVs.  Note that the support for this TLV Type TBD1 is advertised
161      by PIM routers using the PIM Hello Option TBD2 and is discussed in
162      detail in Section 2.2

GV>

"
This document defines a new Group Source Info (GSI) TLV (Type TBD1). The GSI TLV is functionally similar to the GSH TLV but applies to a single (S,G) entry and supports the inclusion of Sub-TLVs to convey additional flow-specific information.

Support for the GSI TLV is advertised using a PIM Hello option (TBD2), as described in Section 2.2.
"

188      T:  If the Transitive bit is set to 0, a router MUST NOT forward the
189         message unless it supports this TLV and all the Sub-TLVs that are
190         present in the TLV in this message.  If the transitive bit is set
191         to 1, it is forwarded even if the router does not support the TLV
192         or all the Sub-TLVs present.
193
194      Type:  This TLV has type TBD1.
195
196      Length:  The length of the value in octets.
197
198      Group Address:  The multicast group for which the source is being
199         announced.  This address uses the Encoded-Group format specified
200         in [RFC7761].
201
202      Source Address:  The source address for the corresponding group.  The
203         format for this address is given in the Encoded-Unicast address in
204         [RFC7761].
205
206      Holdtime:  The Holdtime (in seconds).
207
208      Type Sub-TLV 1..n:  The TLV contains n Sub-TLVs, n MAY be 0.  The
209         total length of the TLV (the Length field) is used to derive how
210         many octets are used for Sub-TLVs.  It will be at least 4 * n
211         octets if n Sub-TLVs are present.  Type Sub-TLV indicates the type
212         of the Sub-TLV.  The allowed types are Sub-TLV types that are
213         specifically defined for use in the Group Source Info TLV.
214
215      Length Sub-TLV 1..n:  The length of the Sub-TLV Value field in
216         octets.
217
218      Value Sub-TLV 1..n:  The value of the Sub-TLV associated with the
219         type and of the specified length.

GV> please

"
The format of the GSI TLV is as follows:

T-bit (1 bit): Indicates transitivity. If set to 0, a router that does not support the TLV or any contained Sub-TLV MUST NOT forward the message. If set to 1, the message MAY be forwarded even if unsupported elements are present.
Type (15 bits): Set to TBD1.
Length (16 bits): The length, in octets, of the TLV value.
Group Address (32 bits): The multicast group address encoded as specified in [RFC7761].
Source Address (32 bits): The unicast source address encoded as specified in [RFC7761].
Holdtime (16 bits): The lifetime, in seconds, for the advertised (S,G) information.
Sub-TLVs: Zero or more Sub-TLVs MAY be included. Each Sub-TLV consists of:
Type (16 bits): Identifies the Sub-TLV. Only types defined for use within the GSI TLV are valid.
Length (16 bits): The length, in octets, of the Value field.
Value: The content associated with the Sub-TLV type.

The total length of the GSI TLV determines the number and size of included Sub-TLVs.
"

GV> note that the type for Group Source Info is 15 bits while the Type Sub-TLV is 16 bits

GV> I see source and group address to be 32 bits. Is this IPv4 only? if yes, better spell it out that this is situation or add context around IPv6

221   2.2.  Group Source Info TLV Hello option
222
223      A PIM router indicates that it supports the Group Source Info TLV
224      specified in this document by including the new Group Source Info TLV
225      Hello option in PIM hellos.
226
227          0                   1                   2                   3
228          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
229         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
230         |       OptionType = TBD2       |           Length = 0          |
231         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
232
233      OptionType = TBD2
234
235      OptionLength = 0

"
A PIM router indicates support for the GSI TLV defined in this document by including the Group Source Info TLV Hello option in PIM Hello messages.

The format of the Hello option is as follows:

             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 = 0          |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OptionType (16 bits): TBD2
OptionLength (16 bits): 0

The presence of this option signifies that the router supports the GSI TLV.
"

237   2.3.  Considerations for using the Group Source Info TLV
138
239      All PIM routers MUST track which neighbors announce this option.
240      This tracking is beneficial in heterogeneous networks where only
241      certain routers support the new TLV Type TBD1.  Additionally, it is
242      RECOMMENDED that only Type TBD1 be used if support is available.
243
244      Consider a router capable of exchanging PFM Type TBD1 TLVs.  It MUST
245      do the following:
246
247      *  It MUST advertise its capability by sending PIM Hello with
248         OptionType TBD2.
249
250      *  It MUST track whether all neighbors on each of its PIM interfaces
251         support this new TLV.  Scope of this tracking is left to the
252         implementation.  It MAY track this information even if the
253         capability on itself is removed.
254
255      *  If this router is a First Hop Router (FHR), while originating a
256         PFM message, it MUST originate a Type TBD1 TLV if all neighbors on
257         the PIM interface support Type TBD1.
258
259      *  If this router is an FHR, while originating a PFM message, it MUST
260         originate a Type 1 TLV [RFC8364] if at least one neighbor on the
261         PIM interface does not support Type TBD1.
262
263      *  On the receipt of a Type TBD1 TLV on a Type TBD1-capable
264         intermediate router, this router MUST forward the PFM message as
265         is on the PIM interfaces where all neighbors support this new
266         type.
267
268      *  If there are PIM interfaces where at least one router does not
269         support the new TLV, an intermediate router that supports Type
270         TBD1 MUST convert the Type TBD1 TLV to Type 1 TLV [RFC8364] and
271         forward it on only on those unsupported interfaces.  The
272         conversion mechanism is largely left to the implementation,
273         however, in a nutshell router MUST create and send TLV Type 1 with
274         the source group and holdtime from the Type TBD1 and ignore the
275         sub-TLV.  Also, if there are multiple sources for the same group,
276         then they SHOULD be put together in one TLV, and sent as Type 1.
277         However, it MUST still send Type TBD1 TLV on all interfaces where
278         the neighbors do support it.
279
280      *  A single PFM message MAY contain both Type 1 and Type TBD1 TLVs.
281         If so, when forwarding to neighbors that do not support Type TBD1,
282         the intermediate router MUST convert the PFM message to Type 1 TLV
283         if it has at least one TBD1 TLV, and all instances of TBD1 TLVs
284         MUST be converted to Type 1 TLVs.

GV>

"
2.3. Considerations for Using the Group Source Info TLV

All PIM routers MUST track which neighbors advertise support for the GSI TLV via the Hello option (Section 2.2). This tracking enables correct operation in heterogeneous deployments. If GSI TLV is supported, use of the GSI TLV (Type TBD1) is RECOMMENDED.

A router that supports the GSI TLV MUST:

* Advertise its capability by including the Hello option (OptionType TBD2) in PIM Hello messages.
* Track, per PIM interface, whether all neighbors support the GSI TLV. The scope and persistence of this state are implementation-specific. An implementation MAY retain this state even if local capability is disabled.
* If acting as a FHR, originate a Type TBD1 TLV when all neighbors on the outgoing interface support Type TBD1.
* If acting as an FHR, originate a Type 1 TLV [RFC8364] when any neighbor on the outgoing interface does not support Type TBD1.
* Upon receipt of a Type TBD1 TLV, MUST forward the PFM message unchanged on interfaces where all neighbors support Type TBD1.
* For interfaces with at least one neighbor that does not support Type TBD1, convert each Type TBD1 TLV to a Type 1 TLV [RFC8364] and forward only on those interfaces. The conversion MUST preserve the group, source, and holdtime fields, and MUST ignore Sub-TLVs. Multiple (S,G) entries for the same group SHOULD be aggregated into a single Type 1 TLV.
* A PFM message MAY contain both Type 1 and Type TBD1 TLVs. When forwarding to neighbors that do not support Type TBD1, all Type TBD1 TLVs MUST be converted to Type 1 TLVs.
"

288   3.1.  RFC 6395 Compliance
289
290      For the forwarding optimization in this document to be used, PIM
291      routers MUST announce a Router-ID as specified in [RFC6395].  A PIM
292      router announces the same 4-byte Router-ID in PIM hellos that it
293      sends to all neighbors on all links.  It also caches the Router-IDs
294      of its neighbors, when it receives Hellos from [RFC6395] Compliant
295      PIM neighbors.  This can be used to determine that different PIM
296      neighbors are really the same router.  In a PIM VRF context, if the
297      router has multiple interfaces with only one neighbor per interface,
298      the router SHOULD check if those neighbors announce an [RFC6395]
299      Router-ID.  Note that the assumption is that Router-IDs are unique
300      per router in a PIM domain, and each device is advertising its own
301      unique Router-ID in PIM hellos on each of its interfaces, otherwise
302      applying this optimization can cause PFM to break.

GV>

"
To apply the forwarding optimization defined in this document, PIM routers MUST advertise a Router-ID as specified in [RFC6395]. A router MUST use the same 4-octet Router-ID in PIM Hello messages on all interfaces and MUST cache Router-IDs learned from neighbors. This enables identification of multiple adjacencies to the same router.

Within a PIM VRF, when multiple interfaces each have a single neighbor, the router SHOULD verify whether those neighbors advertise the same Router-ID. Router-IDs are assumed to be unique within the PIM domain. If this assumption is violated, the optimization defined in this document MUST NOT be applied.
"


304   3.2.  PFM optimization Hello option
305
306      A PIM router indicates that it supports enhancement mechanisms
307      specified in this document by including the new PFM optimization
308      Hello option (Option TBD3).
309
310          0                   1                   2                   3
311          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
312         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
313         |       OptionType = TBD3       |           Length = 0          |
314         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
315
316      OptionType = TBD3
317
318      OptionLength = 0
319
320      All PIM routers supporting forwarding optimization MUST track whether
321      it is supported by all PIM neighbors on each PIM interface.  This
322      tracking is beneficial in heterogeneous networks where only certain
323      routers support the optimization.
324
325      Additionally, for each unique Router-ID received by a PIM router in a
326      PIM domain, the router MUST maintain a set of interfaces where the
327      following two conditions are met: 1.  The neighbor with this Router-
328      ID is the only PIM neighbor on this interface and, 2. the neighbor is
329      advertising the PFM optimization option TBD3 on this interface.  This
330      set is referred to as the PFM_OPT_IF set for each Router-ID.  PFM
331      message exchange is optimized on the interfaces belonging to
332      PFM_OPT_IF for each Router-ID and is discussed in Section 3.4.


GV>

"
3.2. PFM Optimization Hello Option

A PIM router indicates support for the forwarding optimization by including the PFM Optimization Hello option (OptionType TBD3) in PIM Hello messages.

             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 = TBD3       |           Length = 0          |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OptionType (16 bits): TBD3
OptionLength (16 bits): 0

A router that supports this optimization MUST track, per interface, whether all neighbors support the option.

For each learned Router-ID, the router MUST maintain a set of interfaces, denoted PFM_OPT_IF, that satisfy both of the following conditions:

* The neighbor with this Router-ID is the sole PIM neighbor on the interface.
* The neighbor advertises the PFM Optimization option (TBD3) on that interface.

PFM message exchange MAY be optimized on interfaces in the PFM_OPT_IF set.
"

354   3.4.  PFM message handling with Relaxed-RPF enabled
355
356      Consider a topology where two PIM routers maintain multiple PIM
357      neighborships over several links within the same PIM domain, and are
358      the only two routers on these links, either a P2P link, or 2 PIM
359      neighbors on a LAN.  On P2P links, each router sees only one
360      neighbor, but on shared LANs, routers may see multiple neighbors.  An
361      example of such a topology is illustrated in Figure 1.  Between
362      Router A and Router B, there are multiple links - 3 P2P links and 2
363      shared LANs.  Traditionally, each of the routers in Figure 1 will
364      send out PFM messages out over all the links to its neighbor.  RPF
365      checks are one of the commonly used ways to prevent loops, hence the
366      recipient router performs an RPF check and accepts only on one link,
367      thereby dropping packets from all the others.  Since the sender does
368      not know which link will be chosen as the RPF-source on the neighbor,
369      it cannot choose one of the links, without knowing its neighbor's
370      decision.  But this can be optimized as follows.
371
372      Assume both routers A and B are advertising their respective Router-
373      IDs on all links.  When the optimizations specified in
374      Section Section 3.2 are in effect, On both routers A and B,
375      PFM_OPT_IF = {L1, L2, L3}.
356
377      If the Relaxed-RPF optimization is advertised by both routers, the
378      sender MUST choose one link from their PFM_OPT_IF set and send and
379      forward PFM messages to its neighbor using only that link.  On shared
380      LANs, the sender MUST send PFM messages as normal since optimization
381      cannot be applied when there are more than two routers on the network
382      segment.  In other words, the scope of optimization is limited to
383      links present in the PFM_OPT_IF set for each Router-ID.
384
385      For example, referring to Figure 1, if Router A is forwarding or
386      originating a PFM message, it MUST send the message on one link out
387      of Links L1, L2, or L3.  Router A also MUST send the message on both
388      LAN 1 and LAN 2 to ensure Routers C and D receive the message.  This
389      selective behavior reduces PFM message processing overhead on the
390      Point-to-Point links.  The mechanism to choose a link from the
391      PFM_OPT_IF set is left to the implementation.
392
393      When a router that supports the Relaxed-RPF optimization receives a
394      PFM message, it MUST first determine the expected RPF interface for
395      the message using standard RPF calculations.  If the message was
396      received on a link belonging to the PFM_OPT_IF set AND both the
397      sender and receiver support Relaxed-RPF optimization, the receiver
398      MUST accept the message regardless of the RPF check result.  In all
399      other cases, the receiver MUST perform normal RPF validation and only
400      accept the message if it arrives on the correct RPF interface.
401
402      The optimization mechanism relies heavily on a router's insight into
403      whether all neighbors on each PIM interface support the TLV Type TBD3
404      and/or Relaxed-RPF optimization.  All checks can be done at the time
405      when a PFM message is forwarded, but it is possible to perform most
406      checks when there are neighbor changes, so that the processing at
407      forwarding time can be minimized.  The following scenarios MUST be
408      handled:
409
410      Adding a new neighbor on any link:  If the neighbor being added is
411         the first neighbor on this link, the router MUST check whether
412         this neighbor supports the optimization and announces a Router-ID.
413         If both conditions hold TRUE, this router MUST check whether
414         PFM_OPT_IF exists for this Router-ID.  This means that the newly
415         added neighbor is also the sole neighbor on at least one other
416         link.  Therefore, forwarding optimization MUST be enabled on this
417         link by adding it to the existing PFM_OPT_IF set for that Router-
418         ID.  If PFM_OPT_IF does not exist for this Router-ID, it MUST be
419         created, and this link MUST be added to the set.  If the neighbor
420         being added is the second neighbor on this link, and forwarding
421         optimization was previously enabled for the first neighbor, it
422         MUST now be disabled for that Router-ID on this link.  Hence this
423         link MUST be removed from the PFM_OPT_IF set for the first
424         neighbor's Router-ID.
425
426      Neighbor removal on a link:  When a PIM neighbor is removed on a
427         link, and there is exactly one remaining neighbor, it MUST be
428         checked whether the remaining neighbor supports the forwarding
429         optimization and is advertising a Router-ID.  If all three
430         conditions hold TRUE ((i) sole remaining neighbor that (ii)
431         supports forwarding optimization, and (iii) is advertising a
432         Router-ID), this router must check whether PFM_OPT_IF exists for
433         this Router-ID.  If the PFM_OPT_IF set for this Router-ID does not
434         exist, it MUST be created; otherwise, the link MUST be added to
435         the existing set.
436
437      Neighbor starts/stops advertising Router-ID:  When a PIM neighbor
438         starts advertising a Router-ID on this link, it MUST be checked
439         whether this neighbor also supports the forwarding optimization
440         (TBD3) on this link and whether it is the sole neighbor on this
441         link.  If both conditions hold TRUE, this router MUST check
442         whether PFM_OPT_IF exists for this Router-ID.  If it does not
443         exist, create PFM_OPT_IF for this Router-ID and this link MUST be
444         added to the set.  If PFM_OPT_IF already exists, add this link to
445         the existing set.  When a PIM neighbor stops advertising a Router-
446         ID on this link and is still forwarding optimization capable while
447         being the sole neighbor on this link, this link MUST be removed
448         from the PFM_OPT_IF set for this Router-ID.  If the PFM_OPT_IF set
449         for this Router-ID becomes empty, it MUST be deleted.
450
451      Neighbor starts/stops advertising forwarding optimization:  When a
452         PIM neighbor starts advertising the forwarding optimization (TBD3)
453         on this link, it MUST be checked whether this neighbor is the sole
454         neighbor on this link and whether it is advertising its Router-ID
455         on this link.  If both conditions hold TRUE, this router MUST
456         check whether PFM_OPT_IF exists for this Router-ID.  If it does
457         not exist, create PFM_OPT_IF for this Router-ID and this link MUST
458         be added to the set.  If PFM_OPT_IF already exists, add this link
459         to the existing set.  When a PIM neighbor stops advertising the
460         forwarding optimization (TBD3) on this link, while it is still
461         advertising a non-zero Router-ID and is the sole neighbor on this
462         link, this link MUST be removed from the PFM_OPT_IF set for this
463         Router-ID.  If the PFM_OPT_IF set for this Router-ID becomes
464         empty, it MUST be deleted.
465
466         The scenarios described above apply during network and
467         configurations changes as well as software upgrades or downgrades,
468         that could lead to changes in neighbor capabilities.  These
469         changes will be reflected in Hello messages with the relevant
470         options.  It is essential to consistently maintain the PFM_OPT_IF
471         set for each non-zero Router-ID with any such changes.

GV>

"
3.4. PFM Message Handling with Relaxed-RPF

When two routers maintain multiple adjacencies and are the only neighbors on those links, PFM messages are typically transmitted on all links and filtered by RPF checks at the receiver. This results in redundant processing.

If both routers advertise Router-IDs and support the optimization, each router forms a PFM_OPT_IF set containing eligible interfaces.

When Relaxed-RPF is enabled:
* A sender MUST select a single interface from its PFM_OPT_IF set for PFM transmission to that neighbor. The selection method is implementation-specific.
* On shared media with more than two neighbors, the sender MUST transmit PFM messages on all interfaces.
* A receiver that supports Relaxed-RPF MUST:
** Determine the expected RPF interface using standard procedures.
** Accept a PFM message received on any interface in the PFM_OPT_IF set if both sender and receiver support the optimization.
** Otherwise, perform standard RPF validation.

Referring to Figure 1, when Router A originates or forwards a PFM message, it MUST transmit the message on exactly one of links L1, L2, or L3. Router A MUST also transmit the message on LAN 1 and LAN 2 to ensure delivery to Routers C and D.
This behavior reduces processing overhead on point-to-point links. The selection of the interface from the PFM_OPT_IF set is implementation-specific.

3.5. Maintenance of PFM_OPT_IF

Routers MUST update the PFM_OPT_IF set upon neighbor or capability changes:

* Neighbor Addition:
** If the new neighbor is the sole neighbor on the interface and advertises both a Router-ID and the optimization option, the interface MUST be added to the corresponding PFM_OPT_IF set. If no set exists, it MUST be created.
** If a second neighbor appears on the interface, the interface MUST be removed from the PFM_OPT_IF set.

* Neighbor Removal:
** If one neighbor remains and it advertises both a Router-ID and the optimization option, the interface MUST be added to the PFM_OPT_IF set.

* Router-ID Changes:
** If a neighbor starts advertising a Router-ID and satisfies all conditions, the interface MUST be added to the PFM_OPT_IF set.
** If a neighbor stops advertising a Router-ID, the interface MUST be removed. If the set becomes empty, it MUST be deleted.

* Optimization Capability Changes:
** If a neighbor starts advertising the optimization option and satisfies all conditions, the interface MUST be added to the PFM_OPT_IF set.
** If a neighbor stops advertising the option, the interface MUST be removed. If the set becomes empty, it MUST be deleted.

These procedures apply during topology changes, configuration updates, and software upgrades or downgrades. Routers MUST maintain accurate PFM_OPT_IF state for each Router-ID.
"

510      PIM Flooding Mechanism Group Source Info Message Types

512      Type         Name                  Reference
513      ------------------------------------------------------
514        0          Reserved              [This document]
515      1-32767      Unassigned

GV> Do you want to give the name "Reserved" to this message type? There may be a better more intuitive/descriptive name.


Kind Regards,
Gunter Van de Velde
Routing Area Director