[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-pfm-forwarding-enhancements-05: (with DISCUSS and COMMENT)

["Ananya Gopal (ananygop)" <[e-mail]>]

Hi Ketan,

Thank you for your valuable feedback.

Regarding your overall comment on RFC8364, this document is being advanced as a separate Experimental extension intended to improve operational efficiency. We agree it defines behavior that extends RFC8364 procedures. However, this extension is optional: implementations can continue to implement RFC8364 as-is, and no changes are required for existing RFC8364 implementations.

Made edits addressing your comments around:
1) tightening several normative text areas for consistency and readability.
2) updating GSI/GSH handling by clarifying coexistence, backward compatibility intent, support-versus-enablement behavior, and precedence when both TLVs appear for the same (S,G), and replacing Type 1 in the text.

Discussion:

3) We would still like to keep two separate hello options for ease-of-use.

4) After discussions with the AD, we have decided not to reserve value 0. We accept an TLV of Type 0, with a valid length and value, and the draft is already in accordance with that decision.

5) Regarding your point on empty GSI Sub-TLV registry, please note that this draft was earlier split into two: the forwarding enhancements and the Sub-TLVs (https://www.ietf.org/archive/id/draft-venaas-pim-pfm-sd-subtlv-01.html) where certain types are defined. However, it was the WG's opinion to have a single draft. We will be soon proposing another draft which will have use-cases defined for the Sub-Tlvs.

All changes will be reflected in version 6 of the document.

Thanks,
Ananya

From: Ketan Talaulikar via Datatracker <[e-mail]>
Date: Monday, June 15, 2026 at 12:03 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Ketan Talaulikar's Discuss on draft-ietf-pim-pfm-forwarding-enhancements-05: (with DISCUSS and COMMENT)

Ketan Talaulikar has entered the following ballot position for
draft-ietf-pim-pfm-forwarding-enhancements-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-pfm-forwarding-enhancements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors and the WG for this document.

I have one major point that I would like to discuss with the authors and the
WG. The impression that I get from reviewing this document and also looking at
RFC8364 is that this document updates RFC8364. I see that the document shepherd
also has similar impression. This view is coming from looking closer at the
following aspects: a) The GSI TLV is an upgrade for the GSH TLV for advertising
more info about the source. For anyone implementing this feature, the
recommendation is then to use the GSI in this doc when some additional info is
to be advertised and else use the GSH. Since, GSI carries the info in GSH and
then some more, seems like an update to me. b) There are optimization of the
flooding of PFM messages in general which is also an improvement for all use of
the PFM message and hence applicable to the base RFC8364. c) There are quite a
few text blobs with BCP14 language that either repeat things already specified
in RFC8364 or seem to contradict/conflict with it. All of these can be easily
addressed if this document relies more on the text in RFC8364 and does "delta"
updates on it for the changes that this document introduces.

I have tried to point some of these aspects in the comments. I hope this
discussion helps clarify.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also have several comments that I am sharing inline in the idnits output of
v05 of this document. Please look for the tag <EoRv05> at the end to ensure
that you have received the full review.

I support the DISCUSS position of Med since I share some of the concerns that
the has raised.

<major> Since the document is experimental, it would be good to provide some
context for why that is the case in the document. A few suggestions on this
regards to indicate that this extension as well as the base PFM is experimental

In the abstract:

s/The Protocol Independent Multicast (PIM) Flooding Mechanism (PFM) provides
a generic hop-by-hop message exchange framework for distributing multicast
information among PIM routers./The Protocol Independent Multicast (PIM)
Flooding Mechanism (PFM) is an experimental extension that provides a generic
hop-by-hop message exchange framework for distributing multicast information
among PIM routers.

s/This document specifies enhancements to PFM forwarding behavior to improve
efficiency and scalability./ This document specifies further experimental
enhancements to PFM forwarding behavior to improve efficiency and scalability.

In the introduction:

s/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]./PIM Flooding Mechanism [RFC8364] is an experimental
extension that allows a PIM router in the network to originate a PFM message
to distribute announcements of active sources to its PIM neighbors [RFC7761].

s/This document defines two independent enhancements to PFM message
exchange:/This document defines two further independent experimental
enhancements to PFM message exchange:

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

<minor> Suggest to remove this statement. The independent aspect is already
covered a few paragraphs before this and I am unable to understand the
relevance of the BCP14 keywords above.

181        T-bit (1 bit):  Indicates transitivity.  If set to 0, a router that
182           does not support the TLV or any contained Sub-TLV MUST NOT forward
183           the message.  If set to 1, the message MAY be forwarded even if
184           unsupported TLVs or Sub-TLVs are present.

<minor> I believe that "message" above means "PFM message"? If so, please
consider making that explicit.

Furthermore, this handling is essentially specified in the base RFC8364 and
what this document is doing is also extending it to sub-TLVs. Please consider
rephrasing it to avoid restating what is already specified in RFC8364 by simply
reminding that and then add that the T-bit also applies to sub-TLV for this
specific TLV. Please consider if you would like to generically apply this to
all future TLVs of the PFM message (possible if doing an update to it).

188        Length (16 bits):  The length, in octets, of the Value field.

<minor> Perhaps "... of the Value field including all the sub-TLVs"?

209           Length (16 bits):  The length, in octets, of the Value field.  The
210              length may be 0 if no value is present.

<minor> Perhaps ... The length MAY be 0 for sub-TLVs without any value field.

215     2.2.  Group Source Info TLV Hello option

217        A PIM router indicates support for the GSI TLV defined in this
218        document by including the Group Source Info TLV Hello option in PIM
219        Hello messages.  The format of the Hello option is as follows:

<major> There was no option for PFM in RFC8364. Now for just the GSI TLV alone
a hello option is being introduced. Why not introduce a generic PFM hello option
which can carry a variable length flags field where each flag can indicate a
capability within the PFM feature? We already have two hello options in this
document itself. Just a suggestion for your consideration.

239        support the new TLV Type TBD1.  If GSI TLV is supported, use of the
240        GSI TLV (Type TBD1) is RECOMMENDED.

<major> What does the above mean? Seems redundant since I assume feature is
optional. I would assume whether to use/enable it would be up to the operator,
is it not? Please clarify what is the required behavior from a router that
supports this extension vs. what is required behavior when this
extension/feature is enabled. There is an important difference between the two
and the document is lacking specification of feature enablement and its
operational implications.

252        *  If acting as a First Hop Router (FHR), originate a Type TBD1 TLV
253           when all neighbors on the outgoing interface support Type TBD1.

<editorial> The document uses "Type TBD1 TLV" or "Type 1 TLV" in many places.
Please consider using names (e.g., GSI TLV or GSH TLV or PFM Optimization Hello
Option Type) as opposed to code point TLV numbers to make it more reader
friendly. At least RFC8364 seems to use names instead of numbers for the TLVs.

261        *  For interfaces with at least one neighbor that does not support
262           Type TBD1, convert each Type TBD1 TLV to a Type 1 TLV [RFC8364]
263           and forward only on those interfaces.  The conversion MUST
264           preserve the group, source, and holdtime fields, and MUST ignore
265           Sub-TLVs.  Multiple (S,G) entries for the same group SHOULD be
266           aggregated into a single Type 1 TLV.  However, it MUST still send
267           Type TBD1 TLV on all interfaces where the neighbors do support it.

269        *  A PFM message MAY contain both Type 1 and Type TBD1 TLVs.  When
270           forwarding to neighbors that do not support Type TBD1, all Type
271           TBD1 TLVs MUST be converted to Type 1 TLVs.

<major> The above two bullets seem to indicate a level of backwards
compatibility from the GSI to GSH TLVs. If so, it would be good to lay that out
in the TLV description. Does that mean that GSH may be deprecated? Or that GSH
is recommended to be used unless there are some sub-TLVs to signal in which
case GSI is recommended to be used? I think it is the latter and if so it helps
specify this as an improvement update for RFC8364?

284        Router-IDs are assumed to be unique within the PIM domain.  If this
285        assumption is violated, the optimization defined in this document
286        MUST NOT be applied.

<minor> Would it be right to say that the optimization is simply not possible?
I don't understand the use of the BCP14 "MUST NOT" here as that gives an
impression that there is a choice to be made here.

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

<major> The normative behavior defined earlier in this section should be
sufficient to describe the working. Since this is an example, please don't use
BCP14 keywords in its description.

391        *  Neighbor Removal: If exactly one neighbor remains and it
392           advertises both a Router-ID and the optimization option, the
393           interface MUST be added to the PFM_OPT_IF set for that Router-ID.
394           If no set exists, it MUST be created.

<major> I am missing how this is "Neighbor Removal".

434     5.  IANA Considerations

<major> Please specify that all the registries here are under the "Protocol
Independent Multicast (PIM) Parameters" registry group.

450                PIM Flooding Mechanism
451              Group Source Info Sub-TLV Types

453              Type            Name           Reference
454            -----------------------------------------------
455                0-32767      Unassigned

<major> Is it not normal to reserve the value 0 so that it is not used by any
sub-TLV? Also, given the large range, and that this document does not define
any sub-TLVs, do you want to keep a range for local experimentation? I also
found it very strange that the WG is asking for publication of this document
without defining a single usable sub-TLV for the GSI TLV; without that what is
the point of having a GSI TLV?

<EoRv05>