[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-pfm -forwarding-enhancements-05: (with DISCUSS and COMMENT)
Ketan Talaulikar <[email protected]> Fri, 26 Jun 2026 21:38:06 +0530
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <CAH6gdPx0ASN_kCToHKoUasDOq-UDbUDjRLiFq74dnBfUajfgXA@mail.gmail.com> |
--===============8037456602753800562== Content-Type: multipart/alternative; boundary="0000000000002019b406552a51cd" --0000000000002019b406552a51cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Ananya Gopal (ananygop) <ananygop@c= isco.com> wrote: > Hi Ketan, > > Thank you for your valuable feedback. > > Regarding your overall comment on RFC8364, this document is being advance= d > 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 tex= t. > > 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 th= e > 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 <[email protected]> > *Date: *Monday, June 15, 2026 at 12:03=E2=80=AFAM > *To: *The IESG <[email protected]> > *Cc: *[email protected] < > [email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]> > *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-positio= ns/ > 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-enhancemen= ts/ > > > > ---------------------------------------------------------------------- > 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 t= he > 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 outpu= t > of > v05 of this document. Please look for the tag <EoRv05> at the end to ensu= re > 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 th= is > 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 multicas= t > 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 alrea= dy > 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 eve= n > 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 a= nd > 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 th= is > 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 i= n > 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 indicat= e > 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 o= f > 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 tha= t > supports this extension vs. what is required behavior when this > extension/feature is enabled. There is an important difference between th= e > 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 TBD= 1 > 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 stil= l > 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 tha= t > GSH > is recommended to be used unless there are some sub-TLVs to signal in whi= ch > 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, th= e > 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 "Protoc= ol > 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 al= so > 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> > > > > --0000000000002019b406552a51cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Hi Ananya,<div><br></div><div>Thanks for = your response and the updated version you posted.</div><div><br></div><div>= We miss the benefit of discussing the individual review points since you ha= ve not replied inline, but this is not an issue because all of those were n= on-blocking comments. Appreciate you taking care of them.</div><div><br></d= iv><div>Please check inline below for follow-up comments. I will also be cl= earing my DISCUSS position shortly. Even if I believe this document should = update RFC8464, the updates address the technical problems, so I will go wi= th the WG consensus.</div><div><br></div></div><br><div class=3D"gmail_quot= e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun = 18, 2026 at 4:25=E2=80=AFAM Ananya Gopal (ananygop) <<a href=3D"mailto:a= [email protected]">[email protected]</a>> wrote:<br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli= d rgb(204,204,204);padding-left:1ex"> <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(0,0,0)"> Hi Ketan,<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)"> Thank you for your valuable feedback.</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> Regarding your overall comment on RFC8364, this document is being advanced = as a separate Experimental extension intended to improve operational effici= ency. 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 e= xisting RFC8364 implementations.</div></div></div></blockquote><div><br></d= iv><div>KT> The use of the "update" tag is not very well defin= ed (that is a different story). However, the specifications in this documen= t are not merely an extension, but improvements/enhancements to the base. T= hat, I felt, deserved the "update" tag. This way an implementer l= ooking at RFC8364 is also pointed to this specification that introduces imp= rovements to it. In any case, this is experimental work and I hope the auth= ors/WG will produce a single spec if/when this work matures to Standards Tr= ack.</div><div><br></div><div>KT> The other important bit, which was und= one in the latest update is changing the semantics of the T-bit to apply no= t just to a TLV but also to its sub-TLVs. I thought that was a very good im= provement over RFC8364. So, please consider updating the base spec, even if= only for the T-bit semantics.</div><div>=C2=A0</div><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex"><div><div style=3D"background-color:rgb(255,255= ,255)"> <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)"> Made edits addressing your comments around:</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)">1)</span><span style=3D"color:rgb(0,0,0= )">=C2=A0tightening several normative text areas for consistency and readab= ility.</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)">2)</span><span style=3D"color:rgb(0,0,0= )">=C2=A0updating GSI/GSH handling by clarifying coexistence, backward comp= atibility intent, support-versus-enablement behavior, and precedence when b= oth TLVs appear for the same (S,G), and replacing Type 1 in the text.</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> </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)"> Discussion:</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"> <span style=3D"color:rgb(4,81,165)">3)</span><span style=3D"color:rgb(0,0,0= )">=C2=A0We would still like to keep two separate hello options for ease-of= -use.</span></div></div></div></blockquote><div><br></div><div>KT> OK. T= hat is indeed a protocol design choice for the authors/WG.</div><div>=C2=A0= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style=3D"= background-color:rgb(255,255,255)"> <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"> <span style=3D"color:rgb(4,81,165)">4)</span><span style=3D"color:rgb(0,0,0= )">=C2=A0After discussions with the AD, we have decided not to reserve valu= e 0. We accept an TLV of Type 0, with a valid length and value, and the dra= ft is already in accordance with that decision.</span></div></div></div></blockquote><div><br></div><div>KT= > OK. Same as above.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex"><div><div style=3D"background-color:rgb(255,255,255)"> <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"> <span style=3D"color:rgb(4,81,165)">5)</span><span style=3D"color:rgb(0,0,0= )">=C2=A0Regarding your point on empty GSI Sub-TLV registry, please note th= at this draft was earlier split into two: the forwarding enhancements and t= he Sub-TLVs (<a href=3D"https://www.ietf.org/archive/id/draft-venaas-pim-pf= m-sd-subtlv-01.html" target=3D"_blank">https://www.ietf.org/archive/id/draf= t-venaas-pim-pfm-sd-subtlv-01.html</a>), where certain types are defined. However, it was the WG's opinion to h= ave a single draft. We will be soon proposing another draft which will have= use-cases defined for the Sub-Tlvs.</span></div></div></div></blockquote><= div><br></div><div>KT> OK. I respect the WG's decision even if I fee= l otherwise. Right now, I don't see any motivation for someone to imple= ment the GSI TLV without any sub-TLVs which makes the publication of most o= f this spec somewhat unfruitful. On top of that, not considering the sugges= tion 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 i= s Early Allocation via RFC7120 but that will involve more process work for = everyone. I leave this to the authors/WG to consider.</div><div><br></div><= div>Thanks,</div><div>Ketan</div><div>=C2=A0</div><blockquote class=3D"gmai= l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20= 4,204);padding-left:1ex"><div><div style=3D"background-color:rgb(255,255,25= 5)"> </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)"> All changes will be reflected in version 6 of the document.</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,=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 id=3D"m_4782008060938723193mail-editor-reference-message-container" st= yle=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 via Datatracker <<a href=3D"mailto:noreply= @ietf.org" target=3D"_blank">[email protected]</a>><br> <b>Date: </b>Monday, June 15, 2026 at 12:03=E2=80=AFAM<br> <b>To: </b>The IESG <<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a>><br> <b>Cc: </b><a href=3D"mailto:draft-ietf-pim-pfm-forwarding-enhancements@iet= f.org" target=3D"_blank">[email protected]= g</a> <<a href=3D"mailto:draft-ietf-pim-pfm-forwarding-enhancements@ietf= .org" target=3D"_blank">[email protected]= </a>>; <a href=3D"mailto:[email protected]" target=3D"_blank">mmcbride= [email protected]</a> <<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>>; <a href=3D"mailto:[email protected]" targe= t=3D"_blank">[email protected]</a> <<a href=3D"mailto:pim-chairs@ietf.= org" target=3D"_blank">[email protected]</a>>; <a href=3D"mailto:pim@i= etf.org" target=3D"_blank">[email protected]</a> <<a href=3D"mailto:pim@ietf.= org" target=3D"_blank">[email protected]</a>><br> <b>Subject: </b>Ketan Talaulikar's Discuss on draft-ietf-pim-pfm-forwar= ding-enhancements-05: (with DISCUSS and COMMENT)<br> <br> </div> </div> <div style=3D"font-size:11pt">Ketan Talaulikar has entered the following ba= llot position for<br> draft-ietf-pim-pfm-forwarding-enhancements-05: Discuss<br> <br> When responding, please keep the subject line intact and reply to all<br> email addresses included in the To and CC lines. (Feel free to cut this<br> introductory paragraph, however.)<br> <br> <br> Please refer to <a href=3D"https://www.ietf.org/about/groups/iesg/statement= s/handling-ballot-positions/" target=3D"_blank"> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions= /</a><br> for more information about how to handle DISCUSS and COMMENT positions.<br> <br> <br> The document, along with other ballot positions, can be found here:<br> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-pim-pfm-forwarding-e= nhancements/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf= -pim-pfm-forwarding-enhancements/</a><br> <br> <br> <br> ----------------------------------------------------------------------<br> DISCUSS:<br> ----------------------------------------------------------------------<br> <br> Thanks to the authors and the WG for this document.<br> <br> I have one major point that I would like to discuss with the authors and th= e<br> WG. The impression that I get from reviewing this document and also looking= at<br> RFC8364 is that this document updates RFC8364. I see that the document shep= herd<br> also has similar impression. This view is coming from looking closer at the= <br> following aspects: a) The GSI TLV is an upgrade for the GSH TLV for adverti= sing<br> more info about the source. For anyone implementing this feature, the<br> recommendation is then to use the GSI in this doc when some additional info= is<br> to be advertised and else use the GSH. Since, GSI carries the info in GSH a= nd<br> then some more, seems like an update to me. b) There are optimization of th= e<br> flooding of PFM messages in general which is also an improvement for all us= e of<br> the PFM message and hence applicable to the base RFC8364. c) There are quit= e a<br> few text blobs with BCP14 language that either repeat things already specif= ied<br> in RFC8364 or seem to contradict/conflict with it. All of these can be easi= ly<br> addressed if this document relies more on the text in RFC8364 and does &quo= t;delta"<br> updates on it for the changes that this document introduces.<br> <br> I have tried to point some of these aspects in the comments. I hope this<br= > discussion helps clarify.<br> <br> <br> ----------------------------------------------------------------------<br> COMMENT:<br> ----------------------------------------------------------------------<br> <br> I also have several comments that I am sharing inline in the idnits output = of<br> v05 of this document. Please look for the tag <EoRv05> at the end to = ensure<br> that you have received the full review.<br> <br> I support the DISCUSS position of Med since I share some of the concerns th= at<br> the has raised.<br> <br> <major> Since the document is experimental, it would be good to provi= de some<br> context for why that is the case in the document. A few suggestions on this= <br> regards to indicate that this extension as well as the base PFM is experime= ntal<br> <br> In the abstract:<br> <br> s/The Protocol Independent Multicast (PIM) Flooding Mechanism (PFM) provide= s<br> a generic hop-by-hop message exchange framework for distributing multicast<= br> information among PIM routers./The Protocol Independent Multicast (PIM)<br> Flooding Mechanism (PFM) is an experimental extension that provides a gener= ic<br> hop-by-hop message exchange framework for distributing multicast informatio= n<br> among PIM routers.<br> <br> s/This document specifies enhancements to PFM forwarding behavior to improv= e<br> efficiency and scalability./ This document specifies further experimental<b= r> enhancements to PFM forwarding behavior to improve efficiency and scalabili= ty.<br> <br> In the introduction:<br> <br> s/PIM Flooding Mechanism [RFC8364] allows a PIM router in the network to<br= > originate a PFM message to distribute announcements of active sources to it= s<br> PIM neighbors [RFC7761]./PIM Flooding Mechanism [RFC8364] is an experimenta= l<br> extension that allows a PIM router in the network to originate a PFM messag= e<br> to distribute announcements of active sources to its PIM neighbors [RFC7761= ].<br> <br> s/This document defines two independent enhancements to PFM message<br> exchange:/This document defines two further independent experimental<br> enhancements to PFM message exchange:<br> <br> 118=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Implementations MAY support t= hese enhancements independently;<br> 119=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 however, support for both is = RECOMMENDED.<br> <br> <minor> Suggest to remove this statement. The independent aspect is a= lready<br> covered a few paragraphs before this and I am unable to understand the<br> relevance of the BCP14 keywords above.<br> <br> 181=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T-bit (1 bit):=C2=A0 Indicate= s transitivity.=C2=A0 If set to 0, a router that<br> 182=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 does not su= pport the TLV or any contained Sub-TLV MUST NOT forward<br> 183=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the message= .=C2=A0 If set to 1, the message MAY be forwarded even if<br> 184=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsupported= TLVs or Sub-TLVs are present.<br> <br> <minor> I believe that "message" above means "PFM mess= age"? If so, please<br> consider making that explicit.<br> <br> Furthermore, this handling is essentially specified in the base RFC8364 and= <br> what this document is doing is also extending it to sub-TLVs. Please consid= er<br> rephrasing it to avoid restating what is already specified in RFC8364 by si= mply<br> reminding that and then add that the T-bit also applies to sub-TLV for this= <br> specific TLV. Please consider if you would like to generically apply this t= o<br> all future TLVs of the PFM message (possible if doing an update to it).<br> <br> 188=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Length (16 bits):=C2=A0 The l= ength, in octets, of the Value field.<br> <br> <minor> Perhaps "... of the Value field including all the sub-TL= Vs"?<br> <br> 209=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Length (16 = bits):=C2=A0 The length, in octets, of the Value field.=C2=A0 The<br> 210=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 length may be 0 if no value is present.<br> <br> <minor> Perhaps ... The length MAY be 0 for sub-TLVs without any valu= e field.<br> <br> 215=C2=A0=C2=A0=C2=A0=C2=A0 2.2.=C2=A0 Group Source Info TLV Hello option<b= r> <br> 217=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A PIM router indicates suppor= t for the GSI TLV defined in this<br> 218=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document by including the Gro= up Source Info TLV Hello option in PIM<br> 219=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hello messages.=C2=A0 The for= mat of the Hello option is as follows:<br> <br> <major> There was no option for PFM in RFC8364. Now for just the GSI = TLV alone<br> a hello option is being introduced. Why not introduce a generic PFM hello o= ption<br> which can carry a variable length flags field where each flag can indicate = a<br> capability within the PFM feature? We already have two hello options in thi= s<br> document itself. Just a suggestion for your consideration.<br> <br> 239=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 support the new TLV Type TBD1= .=C2=A0 If GSI TLV is supported, use of the<br> 240=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GSI TLV (Type TBD1) is RECOMM= ENDED.<br> <br> <major> What does the above mean? Seems redundant since I assume feat= ure is<br> optional. I would assume whether to use/enable it would be up to the operat= or,<br> is it not? Please clarify what is the required behavior from a router that<= br> supports this extension vs. what is required behavior when this<br> extension/feature is enabled. There is an important difference between the = two<br> and the document is lacking specification of feature enablement and its<br> operational implications.<br> <br> 252=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 If acting as a First = Hop Router (FHR), originate a Type TBD1 TLV<br> 253=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when all ne= ighbors on the outgoing interface support Type TBD1.<br> <br> <editorial> The document uses "Type TBD1 TLV" or "Type= 1 TLV" in many places.<br> Please consider using names (e.g., GSI TLV or GSH TLV or PFM Optimization H= ello<br> Option Type) as opposed to code point TLV numbers to make it more reader<br= > friendly. At least RFC8364 seems to use names instead of numbers for the TL= Vs.<br> <br> 261=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 For interfaces with a= t least one neighbor that does not support<br> 262=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Type TBD1, = convert each Type TBD1 TLV to a Type 1 TLV [RFC8364]<br> 263=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and forward= only on those interfaces.=C2=A0 The conversion MUST<br> 264=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 preserve th= e group, source, and holdtime fields, and MUST ignore<br> 265=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sub-TLVs.= =C2=A0 Multiple (S,G) entries for the same group SHOULD be<br> 266=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 aggregated = into a single Type 1 TLV.=C2=A0 However, it MUST still send<br> 267=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Type TBD1 T= LV on all interfaces where the neighbors do support it.<br> <br> 269=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 A PFM message MAY con= tain both Type 1 and Type TBD1 TLVs.=C2=A0 When<br> 270=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 forwarding = to neighbors that do not support Type TBD1, all Type<br> 271=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TBD1 TLVs M= UST be converted to Type 1 TLVs.<br> <br> <major> The above two bullets seem to indicate a level of backwards<b= r> compatibility from the GSI to GSH TLVs. If so, it would be good to lay that= out<br> in the TLV description. Does that mean that GSH may be deprecated? Or that = GSH<br> is recommended to be used unless there are some sub-TLVs to signal in which= <br> case GSI is recommended to be used? I think it is the latter and if so it h= elps<br> specify this as an improvement update for RFC8364?<br> <br> 284=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Router-IDs are assumed to be = unique within the PIM domain.=C2=A0 If this<br> 285=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 assumption is violated, the o= ptimization defined in this document<br> 286=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST NOT be applied.<br> <br> <minor> Would it be right to say that the optimization is simply not = possible?<br> I don't understand the use of the BCP14 "MUST NOT" here as th= at gives an<br> impression that there is a choice to be made here.<br> <br> 372=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Referring to Figure 1, when R= outer A originates or forwards a PFM<br> 373=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 message, it MUST transmit the= message on exactly one of links L1, L2,<br> 374=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or L3.=C2=A0 This behavior re= duces processing overhead on point-to-point<br> 375=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 links.=C2=A0 The selection of= the interface from the PFM_OPT_IF set is<br> 376=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 implementation-specific.=C2= =A0 Router A also MUST send the message on both<br> 377=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LAN 1 and LAN 2 to ensure Rou= ters C and D receive the message.<br> <br> <major> The normative behavior defined earlier in this section should= be<br> sufficient to describe the working. Since this is an example, please don= 9;t use<br> BCP14 keywords in its description.<br> <br> 391=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 Neighbor Removal: If = exactly one neighbor remains and it<br> 392=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 advertises = both a Router-ID and the optimization option, the<br> 393=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interface M= UST be added to the PFM_OPT_IF set for that Router-ID.<br> 394=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If no set e= xists, it MUST be created.<br> <br> <major> I am missing how this is "Neighbor Removal".<br> <br> 434=C2=A0=C2=A0=C2=A0=C2=A0 5.=C2=A0 IANA Considerations<br> <br> <major> Please specify that all the registries here are under the &qu= ot;Protocol<br> Independent Multicast (PIM) Parameters" registry group.<br> <br> 450=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 PIM Flooding Mechanism<br> 451=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Group Source Info Sub-TLV Types<br> <br> 453=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Type=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Refere= nce<br> 454=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----= ------------------------------------------<br> 455=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 0-32767=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Unassigned<br> <br> <major> Is it not normal to reserve the value 0 so that it is not use= d by any<br> sub-TLV? Also, given the large range, and that this document does not defin= e<br> any sub-TLVs, do you want to keep a range for local experimentation? I also= <br> found it very strange that the WG is asking for publication of this documen= t<br> without defining a single usable sub-TLV for the GSI TLV; without that what= is<br> the point of having a GSI TLV?<br> <br> <EoRv05><br> <br> <br> <br> </div> </div> </div> </blockquote></div></div> --0000000000002019b406552a51cd-- --===============8037456602753800562== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGltIG1haWxp bmcgbGlzdCAtLSBwaW1AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBw aW0tbGVhdmVAaWV0Zi5vcmcK --===============8037456602753800562==--