[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-pfm -forwarding-enhancements-05: (with DISCUSS and COMMENT)
Ketan Talaulikar <[email protected]> Wed, 8 Jul 2026 13:25:01 +0530
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <CAH6gdPyvQ51XezZfki6Jq36A89SiCAP7EbybcgmJ=5jhvc1qXg@mail.gmail.com> |
--===============0044290144689421799== Content-Type: multipart/alternative; boundary="000000000000d2d4a1065614d37f" --000000000000d2d4a1065614d37f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Ananya Gopal (ananygop) <ananygop@ci= sco.com> wrote: > Hi Ketan, > > Thanks for your feedback, please find responses inline. > > > > > We miss the benefit of discussing the individual review points since yo= u > > 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 i= s > > 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 limite= d > 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 MUS= T > NOT cause the router to discard the enclosing GSI TLV or the PFM message. > > https://datatracker.ietf.org/doc/draft-ietf-pim-pfm-forwarding-enhancemen= ts/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 a= n > > 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 reache= d > 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 <[email protected]> > *Date: *Friday, June 26, 2026 at 9:08=E2=80=AFAM > *To: *Ananya Gopal (ananygop) <[email protected]> > *Cc: *The IESG <[email protected]>; > [email protected] < > [email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]> > *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 we= re > 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 updat= e > RFC8464, the updates address the technical problems, so I will go with th= e > WG consensus. > > > On Thu, Jun 18, 2026 at 4:25=E2=80=AFAM Ananya Gopal (ananygop) < > [email protected]> > 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 procedure= s. > > However, this extension is optional: implementations can continue to > > implement RFC8364 as-is, and no changes are required for existing RFC83= 64 > > 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 RFC83= 64 > 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 t= o > 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 precedenc= e > > 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-u= se > --000000000000d2d4a1065614d37f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Ananya,<div><br></div><div>All the comments below were = non-blocking as I had cleared my DISCUSS position; thank you for the respon= ses and clarifications. Looks good to me.</div><div><br></div><div>Thanks,<= /div><div>Ketan</div><div><br></div></div><br><div class=3D"gmail_quote gma= il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 7, 20= 26 at 6:41=E2=80=AFAM Ananya Gopal (ananygop) <<a href=3D"mailto:ananygo= [email protected]">[email protected]</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> <div> <div style=3D"direction:ltr;font-family:"Helvetica Neue",Arial,He= lvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"> Hi Ketan,=C2=A0</div> <div style=3D"direction:ltr;font-family:"Helvetica Neue",Arial,He= lvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"direction:ltr;font-family:"Helvetica Neue",Arial,He= lvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"> Thanks for your feedback, please find responses inline.=C2=A0</div> <div style=3D"direction:ltr;font-family:"Helvetica Neue",Arial,He= lvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"background-color:rgb(255,255,255)"> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(4,81,165)"> ></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0We miss the benefit of discussing the individual review points s= ince you</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0have not replied inline, but this is not an issue because all of= those were</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0non-blocking comments. Appreciate you taking care of them.</span= ></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(4,81,165)"> ></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0Please check inline below for follow-up comments. I will also be= clearing</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0my DISCUSS position shortly. Even if I believe this document sho= uld update</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0RFC8464, the updates address the technical problems, so I will g= o with the</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0WG consensus.</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(4,81,165)"> ></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(4,81,165)"> ></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0The use of the "update" tag is not very well defined (= that is a different</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0story). However, the specifications in this document are not mer= ely an</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0extension, but improvements/enhancements to the base. That, I fe= lt,</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0deserved the "update" tag. This way an implementer loo= king at RFC8364 is</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0also pointed to this specification that introduces improvements = to it.</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0In any case, this is experimental work and I hope the authors/WG= will</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0produce a single spec if/when this work matures to Standards Tra= ck.</span></div> <div style=3D"direction:ltr;text-align:left;line-height:18px;text-transform= :none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;fon= t-size:11pt;color:rgb(0,0,0)"> <br> <br> </div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(0,0,0)"> AG:</div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(0,0,0)"> Apologies for not replying inline earlier. I am relatively new to this foru= m and still learning how to track overlapping WG comments and reviews effec= tively. 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.</div> <div style=3D"direction:ltr;text-align:left;line-height:18px;text-transform= :none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;fon= t-size:11pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(4,81,165)"> ></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0The other important bit, which was undone in the latest update i= s changing</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0the semantics of the T-bit to apply not just to a TLV but also t= o its</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0sub-TLVs. I thought that was a very good improvement over RFC836= 4. So,</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0please consider updating the base spec, even if only for the T-b= it</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0semantics.</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(4,81,165)"> ></div> <div style=3D"direction:ltr;text-align:left;line-height:18px;text-transform= :none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;fon= t-size:11pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(0,0,0)"> AG:</div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(0,0,0)"> We considered adding a T-bit to each Sub-TLV, but concluded that this would= introduce additional complexity and processing overhead with limited pract= ical 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 proc= essing the enclosing GSI TLV and any remaining Sub-TLVs; an unrecognized Su= b-TLV MUST NOT cause the router to discard the enclosing GSI TLV or the PFM message.</div> <div style=3D"direction:ltr;text-align:left;text-indent:0px;line-height:18p= x;text-transform:none;background-color:rgb(255,255,255);font-family:Menlo,M= onaco,"Courier New",monospace;font-size:12px;color:rgb(0,0,0)"> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-pim-pfm-forwarding-e= nhancements/07/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-i= etf-pim-pfm-forwarding-enhancements/07/</a></div> <div style=3D"direction:ltr;text-align:left;line-height:18px;text-transform= :none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;fon= t-size:11pt;color:rgb(0,0,0)"> <br> <br> </div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0KT:</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0OK. I respect the WG's decision even if I feel otherwise. Ri= ght now, I</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0don't see any motivation for someone to implement the GSI TL= V without any</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0sub-TLVs which makes the publication of most of this spec somewh= at</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0unfruitful. On top of that, not considering the suggestion to re= serve an</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0experimental range for the GSI TLV's sub-TLVs makes it harde= r for someone</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0to experiment with sub-TLVs. The only recourse left is Early All= ocation via</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0RFC7120 but that will involve more process work for everyone. I = leave this</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt"> <span style=3D"color:rgb(4,81,165)">></span><span style=3D"color:rgb(0,0= ,0)">=C2=A0to the authors/WG to consider.</span></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(4,81,165)"> ></div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(0,0,0)"> AG:</div> <div style=3D"direction:ltr;text-align:left;line-height:18px;text-transform= :none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;fon= t-size:11pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"text-align:left;text-indent:0px;line-height:18px;text-transfo= rm:none;font-family:"Helvetica Neue",Arial,Helvetica,sans-serif;f= ont-size:11pt;color:rgb(0,0,0)"> We agree that without defined Sub-TLV use cases, the immediate implementati= on value of GSI may appear limited. As noted earlier, Sub-TLV work was init= ially being developed in a separate draft, but the WG reached consensus to = consolidate the work into a single document.</div> </div> <p style=3D"direction:ltr;text-align:left;text-indent:0px;line-height:18px;= text-transform:none;background-color:rgb(255,255,255);margin:0px"> <span style=3D"font-family:"Helvetica Neue",Arial,Helvetica,sans-= serif;font-size:11pt;color:rgb(0,0,0)">So far the WG has not seen the need = for experimental TLVs, and hence this document may not need to specify an e= xperimental Sub-TLV range. If experimental TLVs are considered later, then Sub-TLVs should also be considered.</span>= </p> <div style=3D"direction:ltr;line-height:normal;margin:0px;font-family:"= ;Helvetica Neue",Arial,Helvetica,sans-serif;font-size:11pt;color:rgb(0= ,0,0)"> <br> </div> <div style=3D"direction:ltr;font-family:"Helvetica Neue",Arial,He= lvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"direction:ltr;font-family:"Helvetica Neue",Arial,He= lvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"> Thank you,=C2=A0</div> <div style=3D"direction:ltr;font-family:"Helvetica Neue",Arial,He= lvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"> Ananya</div> <div style=3D"direction:ltr;font-family:"Helvetica Neue",Arial,He= lvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"direction:ltr;font-family:"Helvetica Neue",Arial,He= lvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"> <br> </div> <div id=3D"m_-7832887092487079796mail-editor-reference-message-container" s= tyle=3D"color:inherit;background-color:inherit"> <div> </div> <div style=3D"padding:3pt 0in 0in;border-width:1pt medium medium;border-sty= le:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor"= > <div style=3D"text-align:left;font-family:Aptos;font-size:12pt;color:black"= > <b>From: </b>Ketan Talaulikar <<a href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a>><br> <b>Date: </b>Friday, June 26, 2026 at 9:08=E2=80=AFAM<br> <b>To: </b>Ananya Gopal (ananygop) <<a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a>><br> <b>Cc: </b>The IESG <<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a>>; <a href=3D"mailto:draft-ietf-pim-pfm-forwarding-enha= [email protected]" target=3D"_blank">draft-ietf-pim-pfm-forwarding-enhancem= [email protected]</a> <<a href=3D"mailto:draft-ietf-pim-pfm-forwarding-enhan= [email protected]" target=3D"_blank">draft-ietf-pim-pfm-forwarding-enhanceme= [email protected]</a>>; <a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a> <<a href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a>>; <a href=3D"mailto:pim-chairs@iet= f.org" target=3D"_blank">[email protected]</a> <<a href=3D"mailto:pim-= [email protected]" target=3D"_blank">[email protected]</a>>; <a href=3D"= mailto:[email protected]" target=3D"_blank">[email protected]</a> <<a href=3D"mail= to:[email protected]" target=3D"_blank">[email protected]</a>><br> <b>Subject: </b>Re: Ketan Talaulikar's Discuss on draft-ietf-pim-pfm-fo= rwarding-enhancements-05: (with DISCUSS and COMMENT)<br> <br> </div> </div> <div style=3D"font-size:11pt">Hi Ananya,<br> <br> Thanks for your response and the updated version you posted.<br> <br> We miss the benefit of discussing the individual review points since you<br= > have not replied inline, but this is not an issue because all of those were= <br> non-blocking comments. Appreciate you taking care of them.<br> <br> Please check inline below for follow-up comments. I will also be clearing<b= r> my DISCUSS position shortly. Even if I believe this document should update<= br> RFC8464, the updates address the technical problems, so I will go with the<= br> WG consensus.<br> <br> <br> On Thu, Jun 18, 2026 at 4:25=E2=80=AFAM Ananya Gopal (ananygop) <<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>>= <br> wrote:<br> <br> > Hi Ketan,<br> ><br> > Thank you for your valuable feedback.<br> ><br> > Regarding your overall comment on RFC8364, this document is being adva= nced<br> > as a separate Experimental extension intended to improve operational<b= r> > efficiency. We agree it defines behavior that extends RFC8364 procedur= es.<br> > However, this extension is optional: implementations can continue to<b= r> > implement RFC8364 as-is, and no changes are required for existing RFC8= 364<br> > implementations.<br> ><br> <br> KT> The use of the "update" tag is not very well defined (that= is a<br> different story). However, the specifications in this document are not<br> merely an extension, but improvements/enhancements to the base. That, I<br> felt, deserved the "update" tag. This way an implementer looking = at RFC8364<br> is also pointed to this specification that introduces improvements to it.<b= r> In any case, this is experimental work and I hope the authors/WG will<br> produce a single spec if/when this work matures to Standards Track.<br> <br> KT> The other important bit, which was undone in the latest update is<br= > changing the semantics of the T-bit to apply not just to a TLV but also to<= br> its sub-TLVs. I thought that was a very good improvement over RFC8364. So,<= br> please consider updating the base spec, even if only for the T-bit<br> semantics.<br> <br> <br> ><br> > Made edits addressing your comments around:<br> > 1) tightening several normative text areas for consistency and<br> > readability.<br> > 2) updating GSI/GSH handling by clarifying coexistence, backward<br> > compatibility intent, support-versus-enablement behavior, and preceden= ce<br> > when both TLVs appear for the same (S,G), and replacing Type 1 in the = text.<br> ><br> > Discussion:<br> ><br> > 3) We would still like to keep two separate hello options for ease-of-= use</div> </div> </div> </blockquote></div> --000000000000d2d4a1065614d37f-- --===============0044290144689421799== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGltIG1haWxp bmcgbGlzdCAtLSBwaW1AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBw aW0tbGVhdmVAaWV0Zi5vcmcK --===============0044290144689421799==--