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

[Ketan Talaulikar <[e-mail]>]

Hi Ananya,

All the comments below were non-blocking as I had cleared my DISCUSS
position; thank you for the responses and clarifications. Looks good to me.

Thanks,
Ketan


On Tue, Jul 7, 2026 at 6:41 AM Ananya Gopal (ananygop) <[e-mail]>
wrote:

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