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

Thanks for your feedback, please find responses inline.

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


AG:
Apologies for not replying inline earlier. I am relatively new to this forum and still learning how to track overlapping WG comments and reviews effectively. Thank you for your patience and understanding. Regarding update tag, we fully echo the thought that the sub-TLVs should be part of the base standard.

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

AG:
We considered adding a T-bit to each Sub-TLV, but concluded that this would introduce additional complexity and processing overhead with limited practical benefit. If a router does not support Type TBD1 TLV, it is unlikely to support any of its contained Sub-TLVs. As now specified in Section 2.1 (in version 7) , when a router encounters an unrecognized Sub-TLV type, it MUST ignore that Sub-TLV and continue processing the enclosing GSI TLV and any remaining Sub-TLVs; an unrecognized Sub-TLV MUST NOT cause the router to discard the enclosing GSI TLV or the PFM message.
https://datatracker.ietf.org/doc/draft-ietf-pim-pfm-forwarding-enhancements/07/


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

We agree that without defined Sub-TLV use cases, the immediate implementation value of GSI may appear limited. As noted earlier, Sub-TLV work was initially being developed in a separate draft, but the WG reached consensus to consolidate the work into a single document.

So far the WG has not seen the need for experimental TLVs, and hence this document may not need to specify an experimental Sub-TLV range. If experimental TLVs are considered later, then Sub-TLVs should also be considered.


Thank you,
Ananya


From: Ketan Talaulikar <[e-mail]>
Date: Friday, June 26, 2026 at 9:08 AM
To: Ananya Gopal (ananygop) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-pim-pfm-forwarding-enhancements-05: (with DISCUSS and COMMENT)

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