[pim] Re: draft-ietf-pim-pfm-forwarding-enhancements-05 tele chat Rtgdir review
Carlos Pignataro <[email protected]> Thu, 18 Jun 2026 16:15:27 +0200
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <[email protected]> |
--===============8133603232678486294== Content-Type: multipart/alternative; boundary="Apple-Mail=_55560D76-BD91-4217-8C5C-63F5D513491C" --Apple-Mail=_55560D76-BD91-4217-8C5C-63F5D513491C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for closing the loop, Ananya! > On Jun 18, 2026, at 12:32=E2=80=AFAM, Ananya Gopal (ananygop) = <[email protected]> wrote: >=20 >=20 > Hi Carlos,=20 >=20 > Thank you for your valuable feedback, specially pointing out the = erroneous text describing the T-bit. >=20 > 1. The T-bit was an oversight on my part. Removed the conflicting text = to reflect that there are no changes to the functionality of this bit as = defined in the base RFC RFC8364. >=20 > 2. Regarding the Group Source Info TLV Figure confusion, added text to = reflect that the figure is for IPv4 only. I would like to note that the = encoded format is depicted the same way in base RFCs RFC8364 and = RFC7761. >=20 > 3. Added Relaxed-RPF to the Terminology section as the name for the = forwarding optimization described in Section 3. >=20 > 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. >=20 > The changes are reflected in version 6 of the document.=20 >=20 > Thank you, > Ananya >=20 >=20 > From: Carlos Pignataro via Datatracker <[email protected]> > Date: Sunday, June 7, 2026 at 3:13=E2=80=AFAM > To: [email protected] <[email protected]> > Cc: [email protected] = <[email protected]>; = [email protected] <[email protected]>; [email protected] <[email protected]> > Subject: draft-ietf-pim-pfm-forwarding-enhancements-05 telechat Rtgdir = review >=20 > Document: draft-ietf-pim-pfm-forwarding-enhancements > Title: PIM Flooding Mechanism and Source Discovery Enhancements > Reviewer: Carlos Pignataro > Review result: Has Issues >=20 > Hello, > I have been selected as the Routing Directorate reviewer for this = draft. The > Routing Directorate seeks to review all routing or routing-related = drafts as > they pass through IETF last call and IESG review, and sometimes on = special > request. The purpose of the review is to provide assistance to the = Routing ADs. > For more information about the Routing Directorate, please see > https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are = primarily > for the use of the Routing ADs, it would be helpful if you could = consider them > along with any other IETF Last Call comments that you receive, and = strive to > resolve them through discussion or by updating the draft. >=20 > Document: draft-ietf-pim-pfm-forwarding-enhancements-05 > Reviewer: Carlos Pignataro > Intended Status: Experimental >=20 > Summary: I have some minor concerns about this document that I think = should be > resolved before publication. >=20 > 1. T-bit semantics potential conflict with RFC 8364 =E2=80=94 = message-drop vs. TLV-drop > (Section 2.1) >=20 > The draft states: "If set to 0, a router that does not support the TLV = or any > contained Sub-TLV MUST NOT forward the message." This seems to = conflict with > RFC 8364 Section 3.4.2, which defines T-bit behavior at the TLV level, = not the > message level. In RFC 8364, a non-transitive unsupported TLV is = dropped from > the forwarded message =E2=80=94 the message itself continues = forwarding. Which one is > it? >=20 > 2. Group Source Info TLV Figure confusing >=20 > The diagram shows Group Address and Source Address as single 32-bit = rows, but > the text correctly notes these are variable-length (64 or 160 bits for > IPv4/IPv6 respectively). Could the Figure be updated to show variable = length? >=20 > 3. Could 'Relaxed-RPF' be added to the Terminology section? >=20 > 4. On the IANA Section, for "PIM Flooding Mechanism Group Source Info = Message > Types", could an experimental range and the value of 0 be defined? >=20 > I hope these are clear and useful. >=20 > Best, >=20 > Carlos Pignataro >=20 >=20 --Apple-Mail=_55560D76-BD91-4217-8C5C-63F5D513491C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;">Thank you for closing the loop, = Ananya!<br id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Jun 18, 2026, at 12:32=E2=80=AFAM, Ananya Gopal = (ananygop) <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"> <div> <div style=3D"direction: ltr; font-family: "Helvetica Neue", = Arial, Helvetica, sans-serif; font-size: 11pt;"> <br> </div> <div style=3D"background-color: rgb(255, 255, 255);"> <div style=3D"text-align: left; text-indent: 0px; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> Hi Carlos, <br> <br> </div> <div style=3D"text-align: left; text-indent: 0px; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> Thank you for your valuable feedback, specially pointing out the = erroneous text describing the T-bit.</div> <div style=3D"direction: ltr; text-align: left; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <br> </div> <div style=3D"text-align: left; text-indent: 0px; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <span style=3D"color: rgb(4, 81, 165);">1.</span><span = style=3D""> The T-bit was an oversight on my part. Removed the = conflicting text to reflect that there are no changes to the = functionality of this bit as defined in the base RFC = RFC8364.</span></div> <div style=3D"direction: ltr; text-align: left; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <br> </div> <div style=3D"text-align: left; text-indent: 0px; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <span style=3D"color: rgb(4, 81, 165);">2.</span><span = style=3D""> Regarding the Group Source Info TLV Figure confusion, = added text to reflect that the figure is for IPv4 only. I would like to = note that the encoded format is depicted the same way in base RFCs RFC8364 and RFC7761.</span></div> <div style=3D"direction: ltr; text-align: left; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <br> </div> <div style=3D"text-align: left; text-indent: 0px; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <span style=3D"color: rgb(4, 81, 165);">3.</span><span = style=3D""> Added Relaxed-RPF to the Terminology section as the = name for the forwarding optimization described in Section = 3.</span></div> <div style=3D"direction: ltr; text-align: left; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <br> </div> <div style=3D"text-align: left; text-indent: 0px; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <span style=3D"color: rgb(4, 81, 165);">4.</span><span = style=3D""> 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.</span></div> <div style=3D"direction: ltr; text-align: left; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <br> </div> <div style=3D"direction: ltr; text-align: left; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> The changes are reflected in version 6 of the document. </div> <div style=3D"direction: ltr; text-align: left; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> <br> </div> <div style=3D"text-align: left; text-indent: 0px; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> Thank you,</div> <div style=3D"text-align: left; text-indent: 0px; line-height: 18px; = text-transform: none; font-family: "Helvetica Neue", Arial, = Helvetica, sans-serif; font-size: 11pt;"> Ananya</div> </div> <div style=3D"direction: ltr; font-family: "Helvetica Neue", = Arial, Helvetica, sans-serif; font-size: 11pt;"> <br> </div> <div style=3D"direction: ltr; font-family: "Helvetica Neue", = Arial, Helvetica, sans-serif; font-size: 11pt;"> <br> </div> <div id=3D"mail-editor-reference-message-container" style=3D"color: = inherit; background-color: inherit;"> <div class=3D"ms-outlook-mobile-reference-message skipProofing"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server" = style=3D"color: inherit; background-color: inherit;"> </div> <div style=3D"padding: 3pt 0in 0in; border-width: 1pt medium medium; = border-style: solid none none; border-color: rgb(181, 196, 223) = currentcolor currentcolor;"> <div class=3D"ms-outlook-mobile-reference-message skipProofing" = style=3D"text-align: left; font-family: Aptos; font-size: 12pt;"> <b>From: </b>Carlos Pignataro via Datatracker = <[email protected]><br> <b>Date: </b>Sunday, June 7, 2026 at 3:13=E2=80=AFAM<br> <b>To: </b>[email protected] <[email protected]><br> <b>Cc: </b>[email protected] = <[email protected]>; = [email protected] <[email protected]>; [email protected] = <[email protected]><br> <b>Subject: </b>draft-ietf-pim-pfm-forwarding-enhancements-05 telechat = Rtgdir review<br> <br> </div> </div> <div class=3D"PlainText" style=3D"font-size: 11pt;">Document: = draft-ietf-pim-pfm-forwarding-enhancements<br> Title: PIM Flooding Mechanism and Source Discovery Enhancements<br> Reviewer: Carlos Pignataro<br> Review result: Has Issues<br> <br> Hello,<br> I have been selected as the Routing Directorate reviewer for this draft. = The<br> Routing Directorate seeks to review all routing or routing-related = drafts as<br> they pass through IETF last call and IESG review, and sometimes on = special<br> request. The purpose of the review is to provide assistance to the = Routing ADs.<br> For more information about the Routing Directorate, please see<br> <a href=3D"https://wiki.ietf.org/en/group/rtg/RtgDir" = data-outlook-id=3D"c6868572-16b9-4779-bb79-12d4f9b62e22">https://wiki.ietf= .org/en/group/rtg/RtgDir</a> Although these comments are = primarily<br> for the use of the Routing ADs, it would be helpful if you could = consider them<br> along with any other IETF Last Call comments that you receive, and = strive to<br> resolve them through discussion or by updating the draft.<br> <br> Document: = draft-ietf-pim-pfm-forwarding-enhancements-05<br> Reviewer: Carlos Pignataro<br> Intended Status: Experimental<br> <br> Summary: I have some minor concerns about this document that I think = should be<br> resolved before publication.<br> <br> 1. T-bit semantics potential conflict with RFC 8364 =E2=80=94 = message-drop vs. TLV-drop<br> (Section 2.1)<br> <br> The draft states: "If set to 0, a router that does not support the TLV = or any<br> contained Sub-TLV MUST NOT forward the message." This seems to conflict = with<br> RFC 8364 Section 3.4.2, which defines T-bit behavior at the TLV level, = not the<br> message level. In RFC 8364, a non-transitive unsupported TLV is dropped = from<br> the forwarded message =E2=80=94 the message itself continues forwarding. = Which one is<br> it?<br> <br> 2. Group Source Info TLV Figure confusing<br> <br> The diagram shows Group Address and Source Address as single 32-bit = rows, but<br> the text correctly notes these are variable-length (64 or 160 bits = for<br> IPv4/IPv6 respectively). Could the Figure be updated to show variable = length?<br> <br> 3. Could 'Relaxed-RPF' be added to the Terminology section?<br> <br> 4. On the IANA Section, for "PIM Flooding Mechanism Group Source Info = Message<br> Types", could an experimental range and the value of 0 be defined?<br> <br> I hope these are clear and useful.<br> <br> Best,<br> <br> Carlos Pignataro<br> <br> <br> </div> </div> </div> </div></blockquote></div><br></body></html>= --Apple-Mail=_55560D76-BD91-4217-8C5C-63F5D513491C-- --===============8133603232678486294== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGltIG1haWxp bmcgbGlzdCAtLSBwaW1AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBw aW0tbGVhdmVAaWV0Zi5vcmcK --===============8133603232678486294==--