[pim] Re: Mohamed Boucadair's Discuss on draft-ietf-pim-ze roconf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT)
"Karstens, Nate" <[email protected]> Thu, 20 Nov 2025 06:57:22 +0000
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <CH3PR04MB87941BF4AF84E6189B96839F9CD4A@CH3PR04MB8794.namprd04.prod.outlook.com> |
Med, Thanks for your additional suggestions! My replies are inline, denoted with “[NLK]”. Also, we uploaded draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-09. Best Regards, Nate From: [email protected] <[email protected]> Sent: Wednesday, November 19, 2025 11:30 To: Karstens, Nate <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: RE: [pim] Mohamed Boucadair's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT) Hi Nate, Thank you for the follow-up and for the changes made so far in -08. Please see inline. Cheers, Med De : Karstens, Nate <Nate. Karstens@ garmin. com> Envoyé : mardi 18 novembre 2025 23: 59 À : BOUCADAIR Mohamed INNOV/NET <mohamed. boucadair@ orange. com>; Hi Nate, Thank you for the follow-up and for the changes made so far in -08. Please see inline. Cheers, Med De : Karstens, Nate <[email protected]<mailto:[email protected]>> Envoyé : mardi 18 novembre 2025 23:59 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : RE: [pim] Mohamed Boucadair's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT) Mohamed, Thanks for your review! We uploaded draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08 and made changes based on your feedback: > Unless I’m mistaken, there was not review check with mboned for this document. There was not a formal review with mboned, but many of the members of pim participate in that WG as well. > It is not clear to me what the “protocol” is supposed to do This document by itself does not specify a protocol. [Med] Got that. The concern I had was that the requirements are drawn for a “protocol”. I was unable to see the involved elements and the expected outcome. [NLK] ACK. Can you please let us know if additional changes are needed to address this concern? It may be helpful to consider the other I-Ds related to this: * draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id/__;!!EJc4YC3iFmQ!RPK7-B5pJM3zHicgLmVKXs6Hv4J-dS7vE9ynajadr0fKLmwcojm-vHA7JcCTQ2V_BRF4OTU62DOz2yczwjuRkJd1oHBxHg$> * draft-ietf-pim-ipv6-zeroconf-assignment<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/__;!!EJc4YC3iFmQ!RPK7-B5pJM3zHicgLmVKXs6Hv4J-dS7vE9ynajadr0fKLmwcojm-vHA7JcCTQ2V_BRF4OTU62DOz2yczwjuRkJdEa3OO5A$> * draft-ietf-pim-gaap<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-gaap/__;!!EJc4YC3iFmQ!RPK7-B5pJM3zHicgLmVKXs6Hv4J-dS7vE9ynajadr0fKLmwcojm-vHA7JcCTQ2V_BRF4OTU62DOz2yczwjuRkJebZgYaHQ$> In concert these will provide a mechanism for zeroconf multicast address allocation and enable optimized distribution of multicast traffic on networks that deploy multicast snooping switches. > Also, as I’m lacking a reference architecture, I may be missing obvious aspects for the authors. I can sympathize with that. It would be great to discuss a little more to identify the areas where we need to bridge the gap so that we can better determine how to update the document accordingly. [Med] The examples I provided below are those that I think would be helpful to clarify. [NLK] Got it. We made some changes as noted below. > For example, does collision mitigation lead to use of a distinct address? Yes. The document identifies a number of problems that are resolved by ensuring a unique address is used. [NLK] We added a new [REQ-1] to address this. > What are the implications on applications bound to a multicast group address? By using the term “bound” I’m going to assume that this is receive-side, and that this is about what happens when a collision is detected after an application has already bound a socket to the address/port. [Med] Yes. Ultimately, I think that will depend on the protocols that implement these requirements. Our implementation of the algorithm in draft-ietf-pim-ipv6-zeroconf-assignment<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/__;!!EJc4YC3iFmQ!RPK7-B5pJM3zHicgLmVKXs6Hv4J-dS7vE9ynajadr0fKLmwcojm-vHA7JcCTQ2V_BRF4OTU62DOz2yczwjuRkJdEa3OO5A$> requires applications to register a callback. The callback is executed when the address is first assigned. The callback is executed a second time if a collision is detected, which would then cause the application to stop its multicast stream. Finally, the callback is executed a third time once the collision is resolved. [Med] I appreciate that we don’t need to include solution specific details in the doc, but have some discussion that would capture some key expected behavior would help me. [NLK] I want to make sure I’m understanding correctly – are you satisfied with the info already supplied? Are you suggesting that the document should include some of these details? > What about address discovery and announcement to other members of the group? I think it makes sense to add a recommendation that protocols address this somehow. We added this to section 3: Advertisement: The protocol SHOULD describe a mechanism for advertising and discovery allocated addresses. [Med] Thanks. Maybe better: s/protocol/solution [NLK] Ketan had a similar comment. We updated the document accordingly. > Compliance with 3307 as requirement RFC 3307 is more about how IPv6 multicast addresses are divided into different blocks. The second I-D in this series, draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id/__;!!EJc4YC3iFmQ!RPK7-B5pJM3zHicgLmVKXs6Hv4J-dS7vE9ynajadr0fKLmwcojm-vHA7JcCTQ2V_BRF4OTU62DOz2yczwjuRkJd1oHBxHg$>, improves these requirements a bit to make them easier to adhere to. [Med] My comment was on the absolute requirement for address allocation in 3307. Would it be possible to indicate in the req draft whether that is applicable or, if not, explain it does not need to adhere to it. [NLK] RFC 3307 would be applicable once we address the shortcomings in draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id. Is there an assumption that all standards documents are applicable unless stated or withdrawn? > Any reference to quote for the following… This is a common pattern that we see in recreational marine networks and is reflected in standards like NMEA OneNet. Its applicability is not limited to marine, though. [Med] As the text claim a property for “most marine network”, I think that it would be helpful to back that with a citation. Otherwise, consider s/most/some or similar. [NLK] I think we can soften that statement a bit. > Is this claim about SSM a generic claim or only specific to the marine case mentioned in the introduction The claim is not limited to marine. Many switch parts support multicast snooping (it is easy for them and requires connection with a management CPU), but do not have an address table structured to support SSM. [Med] ACK. > explain what is meant by not support SSM Cost-effective switches often do not support source-specific multicast (SSM) because their address table only maps destination MAC addresses [Med] Thanks. [NLK] Sure thing :) > What is the target deployment scope? Many zeroconf scenarios are focused on the local network, but this document does not impose any limitations in that regard – it is up to the protocol implementing these requirements. [Med] Can you please add that to the draft? [NLK] We kind of cover that in [REQ-5] Single-Subnet Operation and [CONS-1] Multi-Subnet Support. Do you have any recommendations on how to better highlight that? > Requirement 3: Protocol Coexistence Our hope, at least with IPv6, is to create an environment where this is possible (hence draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id/__;!!EJc4YC3iFmQ!RPK7-B5pJM3zHicgLmVKXs6Hv4J-dS7vE9ynajadr0fKLmwcojm-vHA7JcCTQ2V_BRF4OTU62DOz2yczwjuRkJd1oHBxHg$>). IPv4 is a more difficult case. Determining which protocol is more important is more of a deployment decision and out-of-scope for this document. [Med] Can you please record that in the draft? [NLK] Sure, we added the following sentence to the end of the IPv4 Considerations section: “Zeroconf coexistence with other IPv4 multicast address allocation solutions may not be possible, in which case it may be necessary to require manual configuration or to limit the solutions that are deployed.” > Should any assumption be made about the nodes motions/adjacencies/etc I think those challenges would be taken into account by the allocation protocols, as the solution is likely related to how they uniquely operate [Med] As this is defining requirements, wouldn’t be better to capture these then in the document? [NLK] I’m not sure what exactly would be helpful, do you have any suggestions that would help us get started? Best Regards, Nate From: Mohamed Boucadair via Datatracker <[email protected]<mailto:[email protected]>> Sent: Friday, November 14, 2025 06:08 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] Mohamed Boucadair's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel Mohamed Boucadair has entered the following ballot position for draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: 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!RhuVcYtyfJFxbH4QIvam5tdvlYObGNOsY8uDqG0O3qO0sm9e5Ol_z2ENDpfnDwe9Sh3pk-2yJItqghaluA$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!RhuVcYtyfJFxbH4QIvam5tdvlYObGNOsY8uDqG0O3qO0sm9e5Ol_z2ENDpfnDwe9Sh3pk-2yJItqghaluA$> 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!RhuVcYtyfJFxbH4QIvam5tdvlYObGNOsY8uDqG0O3qO0sm9e5Ol_z2ENDpfnDwe9Sh3pk-2yJItc83VQjw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!RhuVcYtyfJFxbH4QIvam5tdvlYObGNOsY8uDqG0O3qO0sm9e5Ol_z2ENDpfnDwe9Sh3pk-2yJItc83VQjw$> ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Nathan, Dino, and Mike, Thank you for the effort put into this document. Unless I’m mistaken, there was not review check with mboned for this document. Please find below few DISCUSS points: # It is not clear to me what the “protocol” is supposed to do? What is the expected outcome overall? What are the elements supposed to be involved for that protocol? Also, as I’m lacking a reference architecture, I may be missing obvious aspects for the authors. For example, does collision mitigation lead to use of a distinct address? What are the implications on applications bound to a multicast group address? What about address discovery and announcement to other members of the group? Can we please clarify that? # Compliance with 3307 as requirement RFC3307 says: This document specifies guidelines that MUST be implemented by any entity responsible for allocating IPv6 multicast addresses. Again, maybe this is obvious for the authors, but how do we expect to still adhere to that MUST? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Any reference to quote for the following: CURRENT: Most marine networks are built on a single subnet and rely on Layer 2 Ethernet switches to connect devices. # Is this claim about SSM a generic claim or only specific to the marine case mentioned in the introduction: CURRENT: Cost-effective switches often do not support source-specific multicast (SSM), so IGMP snooping [RFC4541] is used to control multicast delivery. Also, may be helpful to update this text to explain what is meant by not support SSM in light of this discussion [1]. # What is the target deployment scope? Is this a local network? # Requirement 3: Protocol Coexistence Which one will take precedence in such case? is that a concern at the first place? # Requirement 7 Should any assumption be made about the nodes motions/adjacencies/etc.? Should those be frozen? Cheers, Med [] https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/mboned/ulvDZNBBm90d_LdtPePdS14msHQ/__;!!EJc4YC3iFmQ!RhuVcYtyfJFxbH4QIvam5tdvlYObGNOsY8uDqG0O3qO0sm9e5Ol_z2ENDpfnDwe9Sh3pk-2yJIsNrcsBjg$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/mboned/ulvDZNBBm90d_LdtPePdS14msHQ/__;!!EJc4YC3iFmQ!RhuVcYtyfJFxbH4QIvam5tdvlYObGNOsY8uDqG0O3qO0sm9e5Ol_z2ENDpfnDwe9Sh3pk-2yJIsNrcsBjg$> _______________________________________________ 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. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. 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]