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

[Ketan Talaulikar <[e-mail]>]

Hi Ananya,

Thanks for your response and the updated version you posted.

We miss the benefit of discussing the individual review points since you
have not replied inline, but this is not an issue because all of those were
non-blocking comments. Appreciate you taking care of them.

Please check inline below for follow-up comments. I will also be clearing
my DISCUSS position shortly. Even if I believe this document should update
RFC8464, the updates address the technical problems, so I will go with the
WG consensus.


On Thu, Jun 18, 2026 at 4:25 AM Ananya Gopal (ananygop) <[e-mail]>
wrote:

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

KT> The use of the "update" tag is not very well defined (that is a
different story). However, the specifications in this document are not
merely an extension, but improvements/enhancements to the base. That, I
felt, deserved the "update" tag. This way an implementer looking at RFC8364
is also pointed to this specification that introduces improvements to it.
In any case, this is experimental work and I hope the authors/WG will
produce a single spec if/when this work matures to Standards Track.

KT> The other important bit, which was undone in the latest update is
changing the semantics of the T-bit to apply not just to a TLV but also to
its sub-TLVs. I thought that was a very good improvement over RFC8364. So,
please consider updating the base spec, even if only for the T-bit
semantics.


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

KT> OK. That is indeed a protocol design choice for the authors/WG.


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

KT> OK. Same as above.


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

KT> OK. I respect the WG's decision even if I feel otherwise. Right now, I
don't see any motivation for someone to implement the GSI TLV without any
sub-TLVs which makes the publication of most of this spec somewhat
unfruitful. On top of that, not considering the suggestion to reserve an
experimental range for the GSI TLV's sub-TLVs makes it harder for someone
to experiment with sub-TLVs. The only recourse left is Early Allocation via
RFC7120 but that will involve more process work for everyone. I leave this
to the authors/WG to consider.

Thanks,
Ketan


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