[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-zer oconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)
"Karstens, Nate" <[email protected]> Thu, 12 Feb 2026 19:54:13 +0000
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <CH3PR04MB87946CD2E87F6C16BCD42EBA9C60A@CH3PR04MB8794.namprd04.prod.outlook.com> |
Ketan, I apologize for the significant delay since my last reply. We posted draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-11 to address your concerns: https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/ Please see responses below, marked [NLK2]. Cheers, Nate From: Ketan Talaulikar <[email protected]> Sent: Friday, November 21, 2025 06:22 To: Karstens, Nate <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [pim] Ketan Talaulikar's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT) Hi Nate, Thanks for the continued discussion and the improvements being made to the document. Please check inline below for responses with KT2 and I am not following up on the points where we have reached an agreement. On Fri, Nov 21, 2025 at Hi Nate, Thanks for the continued discussion and the improvements being made to the document. Please check inline below for responses with KT2 and I am not following up on the points where we have reached an agreement. On Fri, Nov 21, 2025 at 3:53 AM Karstens, Nate <[email protected]<mailto:[email protected]>> wrote: Ketan, Thanks for taking another look! My responses are below, denoted with [NLK]. Also, we posted a version -10. Best Regards, Nate From: Ketan Talaulikar <[email protected]<mailto:[email protected]>> Sent: Thursday, November 20, 2025 02:30 To: Karstens, Nate <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [pim] Ketan Talaulikar's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT) Hi Nate, Thanks for your response and the document update. Please check inline below for my responses/clarifications. For the ones where I haven't responded, the changes and/or your responses address my comments. Thanks. Also, I might have Hi Nate, Thanks for your response and the document update. Please check inline below for my responses/clarifications. For the ones where I haven't responded, the changes and/or your responses address my comments. Thanks. Also, I might have sneaked a peek at some of the solutions but by and large my review has turned a blind eye to all those other drafts. I strongly recommend that if this document is to be published as an RFC it should be standing on its own with the necessary specifics and clarity. [NLK] That makes sense. I think our document is intended to stand on its own, but knowing about the other documents might help understand why we are writing this document at all. Note: I found it hard to process your style of responses where my original comments have been trimmed. Could you please respond inline in the future to preserve the context? I am dealing with a lot of context switches and would appreciate it if the full context was preserved during such discussions. [NLK] My apologies and sorry for the additional work that caused for you. All future replies will be inline. On Thu, Nov 20, 2025 at 12:26 PM Karstens, Nate <[email protected]<mailto:[email protected]>> wrote: Ketan, Thanks for your review! We uploaded draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-09 and made changes based on your feedback: > …why the WG wishes to publish this document as an RFC… We believe that there is benefit to documenting problems with the status quo and providing metrics that future solutions (such as draft-ietf-pim-ipv6-zeroconf-assignment and draft-ietf-pim-gaap) can be evaluated by. KT> There is a difference between documenting and publishing as an RFC. I don't see the long term benefit of publication of the document given the state of the solution work. There are plenty of examples where such work is adopted but not published as an RFC. Anyway, this was not a technical point and I will leave this to the WG and the responsible AD's call. I'll move this down into comments just to make sure it is not seen as a DISCUSS [NLK] Sounds good, thanks! > A way to address this is to replace the "new protocol" with a "solution" Mohamed had a similar suggestion. We updated the document accordingly. KT> Thanks. I'll clear this point. [NLK] Great, thank you! > Assuming there is indeed the need for something new, I was looking for some analysis of why we need to build something new for IPv4 and why not just for IPv6. Our recommendation is to use IPv6, but leave that up to the protocol designer in case they need IPv4 for their use case. draft-ietf-pim-ipv6-zeroconf-assignment uses IPv6 only, while draft-ietf-pim-gaap supports both IPv4 and IPv6. KT> I am not sure who you are referring to by "our". I see the authors of this document are authors for both of those documents. Regardless, I would look for what is the WG consensus on this topic and it would be good to document the analysis on why work on IPv4 for something new. This point remains open. [NLK] I think there are networks in use today that would benefit from host-based multicast address allocation, but where transitioning to IPv6 is not practical. We didn’t want to preclude anything that could be beneficial. I think the WG still regards IPv4 as worth maintaining because the charter mentions IGMP and RFC 9776 (an update to IGMPv3) was published earlier this year. KT2> Some text along the lines of your response above in the introduction section would help. It would be better if this were one of the considerations that conveys that the problem needs to be solved for IPv6 but it would be good to solve also for IPv4 (or something along those lines). [NLK2] We added another paragraph to the Introduction section to address this. > [Referring to RFC 4541] That RFC is almost 20 years old. Is it still relevant? Yes, it is still relevant :). We are working on some improvements, see draft-karstens-pim-multicast-snooping-optimization. KT> I find it very hard to believe that RFC4541 is still relevant and reflects the current state. Especially the "survey" in https://www.rfc-editor.org/rfc/rfc4541#section-4<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc4541*section-4__;Iw!!EJc4YC3iFmQ!U6InPKfEEzSRFhS0SwFKiXm1PWzYkxm1AGEWdvmV8SOk3vxx9cQ4mkgwdcwCTfafIxP8oCtnkPYF3WijEmoc198$> was only referring to IGMP and not covering MLD. IPv6/MLD text in that RFC gives the impression of it being "bleeding edge" while it clearly cannot be so in 2025? Is there any discussion that you could point me to? This document claims "many switches" and I would like to see some substantiations of those claims. This point remains open. [NLK] We can discuss this more and get back with you. I do agree that IETF documentation on this is not in the best state. Some of that may be because ownership is not entirely clear – IETF owns network-layer and above, IEEE owns link-layer and below, and snooping crosses both of those layers. In any case, we are working on improvements. KT2> I don't see any issue there - IETF and IEEE have a collaborative liaison between them. Back to the topic, I haven't seen any changes in this text in the latest version. At a minimum this claim needs to be revised perhaps from "many switches" to "some switches" and the text should include the clarification that there does not exist a more recent survey/analysis but it is likely that some of those limitations (e.g., old or "deficient" switches) still exist in some of the target deployments. [NLK2] Sorry, I didn’t initially understand the main point you were making with the comment, which is that the survey results are old and may not apply anymore. We updated that section to point that out. You also mentioned MLD. My experience has been that the “IGMP/MLD snooping” feature in switch hardware just detects the IGMP or MLD protocols and kicks the Ethernet frame up to a management CPU for further handling. The CPU is then able to treat MAC addresses generated by IPv4 multicast and IPv6 multicast interchangeably as far as programming address tables in the switch. This is a limited sample of course, but illustrates that the transition to MLD didn’t necessarily require a large change in switch operation. [/NLK2] > The reference to a 20+ year old patent (so the idea is even older) as an example or justification seems very odd to me I’m not sure how prevalent this feature/limitation is in the market, but we still encounter it in modern parts. KT> I find that response unconvincing. Is there anything lost if this point and the entire paragraph were removed from this document? This point remains open. [NLK] Yes, section 2.1 of draft-ietf-pim-ipv6-zeroconf-assignment<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/__;!!EJc4YC3iFmQ!VZVZL6NsedgtdadKkEPD8oCo9u42E2jDZ7zuZ-CbKvLkIMlncbh_S43hv1pHToHnIANWGySfC7l2OJ9uGPcrIqw$> describes a mitigation for this issue. KT2> Thanks for that clarification. In which case, the problem may be described briefly inline to benefit the reader instead of pointing normatively to a 20+ year old patent. Is that possible? [NLK2] Yeah, no problem. We improved the description a bit and moved the patent to an informative reference (the diagrams and description are still helpful). > I find this very strange. Why is this a requirement? I would have expected it to be the other way around - use/extend what exists? The only protocol that was published as a standard is MADCAP. Making that work as a host-based (vs server-based) allocation model was something we looked into briefly, but it would be significantly more complicated than a protocol designed for host allocation. We left it out of the Excluded Solutions section because it was never really a viable option. KT> I'll remind you that we are not anymore talking about protocols but solutions. This text is not just about MADCAP. Taking a step back and thinking about this, is the intention actually the following (please feel free to wordsmith to convey the intention)? [CONS-2] Standards Compatibility: The solution SHOULD aim to minimize the need for changes to existing protocols or standards that affects backwards compatibility or deployment in existing networks. [NLK] I’m fine with this wording. > It is not clear if the solution can extend to both host stacks as well as network devices. We somewhat address that with the Standards Compatibility consideration. That is limited to protocols and standards, though that can be extended to a desire to minimize any change. We can update the document to reflect that if you prefer. KT> Yes, however, it would be preferable to describe in terms of applications, hosts, and routers/switches. When you say "platform", it is not clear what exactly that refers to. I suspect this is on the hosts - but please clarify. [NLK] Sure, we can clarify that this is referring to host platforms. > Should it also cover MLD snooping We can update this to say “IGMP/MLD snooping” > Perhaps you would want to clarify why not? Is it because it requires a server and is not a decentralized mechanism? That’s correct. We rearranged the sentence a bit to make that more apparent: RFC2730 (MADCAP) describes a method for multicast IP address allocation, but its server-based model does not suit a zeroconf environment. > Does "Ethernet" here imply the "wired" media or in general for others such as wifi and various other link layer technologies? Éric Vyncke had a similar comment. We updated the document to be more neutral with regards to link layer. > I am assuming the "hardware" being referred to here is an L2 switch? No, this would be in the Ethernet MAC, for example. KT> Could you please clarify and be more precise? [NLK] Sure. We updated this paragraph as follows: First, many host network interfaces allow filtering of multicast traffic directly in hardware. When an application joins a multicast group, the host network stack typically programs the hardware to accept only traffic for that group. However, if two groups share the same link-layer address, the hardware network interface cannot distinguish them. The network stack is then forced to process unwanted traffic in software, reducing performance and increasing CPU usage. Does that help? [/NLK] KT2> Yes, it does. Thanks. Thanks, Ketan > "gracefully" is not very precise We left that vague to allow flexibility in protocol design. Still, it would be helpful to at least indicate that streams should be migrated to a unique address. We updated this accordingly. > I am not able to parse the above statement properly. Could you please clarify or rephrase Sorry, my grammar was terrible there. I updated to say “advertising and discovering allocated addresses”. This was from Mohamed Boucadair’s question about how the allocated addresses would be communicated (see https://mailarchive.ietf.org/arch/msg/pim/yvDAR-jVVIuexooqwS9P8FywSNk/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/pim/yvDAR-jVVIuexooqwS9P8FywSNk/__;!!EJc4YC3iFmQ!U6InPKfEEzSRFhS0SwFKiXm1PWzYkxm1AGEWdvmV8SOk3vxx9cQ4mkgwdcwCTfafIxP8oCtnkPYF3WijaaFO6qw$>). > The above sentence is not appropriate for this document Éric Vyncke had a similar comment. Our concern with removing the reference from the IPv6 considerations section is that the reader may get the impression that there is no solution to the issues we describe. KT> It is not right that a problem statement and requirement document references solutions. Please remove this reference. What prevents the WG from finding another solution? Do we want this document to be partial to one particular solution? [NLK] OK, we will remove it. Thanks, Ketan > I find the discussion of excluded solutions in this document to be odd I can’t say that the WG spent extensive time discussing these, though that might have been because we listed them in our first draft. We moved this to an appendix. Best Regards, Nate From: Ketan Talaulikar via Datatracker <[email protected]<mailto:[email protected]>> Sent: Wednesday, November 19, 2025 08:33 To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [pim] Ketan Talaulikar's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT) Ketan Talaulikar has entered the following ballot position for draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel Ketan Talaulikar has entered the following ballot position for draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!UjULH0DhVmj7ill_v9jfReZ7yq_cT2H8QJnwK_ItAH83KaVQhMPVVUq-VtkisWQ_PdLPxlq7rDQbI7GChw$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!UjULH0DhVmj7ill_v9jfReZ7yq_cT2H8QJnwK_ItAH83KaVQhMPVVUq-VtkisWQ_PdLPxlq7rDQbI7GChw$> for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!UjULH0DhVmj7ill_v9jfReZ7yq_cT2H8QJnwK_ItAH83KaVQhMPVVUq-VtkisWQ_PdLPxlq7rDRKAVrmUA$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!UjULH0DhVmj7ill_v9jfReZ7yq_cT2H8QJnwK_ItAH83KaVQhMPVVUq-VtkisWQ_PdLPxlq7rDRKAVrmUA$> ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. There are several aspects in this document that I would like to discuss with the authors and the WG. There is also an overarching question at the back of my mind on why the WG wishes to publish this document as an RFC when it has already adopted multiple documents related to solutions that supposedly address this problem space (draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id (in IETF LC), draft-ietf-pim-ipv6-zeroconf-assignment, draft-ietf-pim-gaap (experimental)). Just curious ... perhaps the WG can just decide not to publish this as an RFC and instead continue their work-in-progress solutions while keeping this draft as a guidance? Please find below discussion points inline in the idnits o/p of v08 of this document: 29 zeroconf deployment. This foundation serves as a reference for 30 developing future multicast address allocation protocols that operate 31 autonomously within local networks. <discuss-1> It is strange for a problem statement and requirements documents to pre-suppose a solution that requires new/future protocols. I would have expected the document to remain open to any solution that solves the problem and meets the requirements. It may be a protocol or a mechanism (e.g., a mapping scheme for multicast address allocation). It may an extension of an existing protocol or mechanism or a new one. I do not see the analysis that rules out extending existing things and makes it a must to define new ones. A way to address this is to replace the "new protocol" with a "solution" so this document is not getting into the specifics of the solution space. <discuss-2> Assuming there is indeed the need for something new, I was looking for some analysis of why we need to build something new for IPv4 and why not just for IPv6. 154 Second, link-layer address collisions reduce the benefit of using 155 multicast snooping switches on a network. As described in [RFC4541], 156 Section 4, many switches forward multicast traffic based solely on 157 the link-layer address, without considering the network-layer group 158 (see the results for Q2 and Q3). In such cases, if two multicast <discuss-3> That RFC is almost 20 years old. Is it still relevant? 165 Third, the internal design of some switches can also contribute to 166 collisions. For example, certain switch implementations 167 [US6690667B1] use hash tables to store forwarding entries based on 168 MAC addresses. If multiple addresses hash to the same location and 169 the table fills up, additional entries may be dropped or rejected, 170 resulting in forwarding failures. <discuss-4> The reference to a 20+ year old patent (so the idea is even older) as an example or justification seems very odd to me. I find the argument odd that we need to design a new protocol in 2026+ to fix this thing ... 224 2. Standards Compatibility: The protocol SHOULD aim to minimize the 225 need for changes to existing protocols or standards. <discuss-5> I find this very strange. Why is this a requirement? I would have expected it to be the other way around - use/extend what exists? 227 3. Cross-Platform Availability: It SHOULD use capabilities that are 228 widely available across platforms and operating systems. <discuss-6> It is not clear if the solution can extend to both host stacks as well as network devices or only to the network devices or only to the hosts. Would it be desirable if the solution only comprises of changes in the hosts (e.g., a new plugin for socket layer) and does not require any other changes? I don't find any discussion or analysis on this part. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would also like to share some comments/suggestions inline in the idnits o/p of v08 of the document. 103 destination MAC addresses. Instead, each multicast stream is 104 assigned a unique destination multicast IP address, and IGMP snooping <minor> Should it also cover MLD snooping? 114 [RFC2730] (MADCAP) describes a method for server-based multicast IP 115 address allocation, but this does not suit a zeroconf environment. <minor> Perhaps you would want to clarify why not? Is it because it requires a server and is not a decentralized mechanism? 146 First, many Ethernet interfaces allow filtering of multicast traffic <major> Does "Ethernet" here imply the "wired" media or in general for others such as wifi and various other link layer technologies? 147 directly in hardware. When an application joins a multicast group, 148 the network stack typically programs the hardware to accept only <major> I am assuming the "hardware" being referred to here is an L2 switch? And is the "network stack" here IP Routing or L2 bridging? Is it possible to make this more precise so the target deployment network can be better understood by those that would build the solutions? 212 Note: In rare cases, collisions may arise after a temporary network 213 partition, when different parts of the network allocate the same 214 multicast address independently. Upon reconnection, such collisions 215 SHALL be detectable and resolved gracefully. <major> "gracefully" is not very precise. Is there a time period in mind here? Is it OK for the multicast service to be disrupted? Any details on what is expected from the applications, from the host stack, and from the network devices (switches/routers)? 241 7. Advertisement: The protocol SHOULD describe a mechanism for 242 advertising and discovery allocated addresses. <major> I am not able to parse the above statement properly. Could you please clarify or rephrase? 268 A solution to these issues is presented in 269 [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id]. <major> The above sentence is not appropriate for this document. 295 6. Excluded Solutions <major> I find the discussion of excluded solutions in this document to be odd. However, if they have been discussed in the WG as part of this work and there is a need to document them (not as requirements but just as "notes") then perhaps this can be moved to the Appendix with such a note? <EoRv08> _______________________________________________ pim mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. _______________________________________________ pim mailing list -- [email protected] To unsubscribe send an email to [email protected]