[pim] Re: Mohamed Boucadair's Discuss on draft-ietf-pim-ze roconf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT)

Med,

I apologize for the significant delay in responding to your last message. We uploaded v13 of the document, which hopefully addresses your remaining concerns:

https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/

Please also see my responses below, marked [NLK3].

Cheers,

Nate

From: [email protected] <[email protected]>
Sent: Friday, November 21, 2025 00:42
To: Karstens, Nate <[email protected]>; The IESG <[email protected]>
Cc: [email protected]; [email protected]; [email protected]
Subject: RE: [pim] Re: Mohamed Boucadair's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT)

Hi Nate, Thanks for the changes in -10. I think that we are almost there. Please see inline. Cheers, Med De : Karstens, Nate <Nate. Karstens=40garmin. com@ dmarc. ietf. org> Envoyé : jeudi 20 novembre 2025 23: 23 À : BOUCADAIR Mohamed INNOV/NET

Hi Nate,

Thanks for the changes in -10. I think that we are almost there.

Please see inline.

Cheers,
Med

De : Karstens, Nate <[email protected]<mailto:[email protected]>>
Envoyé : jeudi 20 novembre 2025 23:23
À : 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] Re: Mohamed Boucadair's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT)


Med,

No problem, thanks for the continued dialog!

Please see inline [NLK2]. Also, we posted a version -10.

Best Regards,

Nate

[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?
[Med] I was looking for some brief description about the hosts that seek (are these senders, receivers, etc.) for address allocation, scope within which conflicts will be checked/avoided, is the intended outcome only about allocation an address or does this result also in that address being shared and used among a group.

[NLK2]
For scope, I think we address this with the following entries:

[REQ-5] Single-Subnet Operation: It SHALL support effective operation within a single IP subnet, which is typical in link-local or isolated network environments.
[CONS-1] Multi-Subnet Support: Operation across multiple subnets is beneficial in more complex or routed environments and SHOULD be supported.

Do you think that is sufficient?
[Med] Defining the requirements is one step further, IMO. My concern is that we need some description of what is intended before getting into specific requirements. That description helps understand why these specific requirements are identified at the first place.
[NLK3] We expanded the second-to-last paragraph in the introduction to address this.

Regarding the hosts that seek addresses, I’ve thought about this and considered adding to our solution requirements section, but I’m concerned that this goes against best practices for multicast protocol design so much so that it would be stating the obvious. Let me explain…

Although it is possible for there to be zero or one receivers, multicast is traditionally thought of as either a one-to-many or many-to-many distribution model: there is at least one sender and multiple receivers. Coordinating addresses between devices is more difficult than having a single device be responsible for this. If you rely on receivers to allocate addresses, then you always must coordinate address allocation, whereas if you rely on senders to allocate addresses, then you only need to coordinate between senders in applications that utilize many-to-many.

Maybe I’m bringing in my own bias and this is not obvious, but I’m also not certain that is something that should be in-scope for this document. Open to other viewpoints on this :).

Similarly, the use of the allocated address is somewhat dependent on the nature of an application. This document describes more the one-to-many case, but I wouldn’t want to reject an algorithm that automatically negotiates a common address between hosts. Again, this seems out-of-scope.

Would it be helpful to list some of these as being out-of-scope? It’s hard sometimes to know when saying something is out-of-scope is helpful, and when it just gets in the way.
[/NLK2]
[Med] I’m in favor of explicitly calling out what is out of scope. This has the merit to set the expectation properly. Thanks.
[NLK3] Sounds good! We added this to the second-to-last paragraph of the introduction.

One recommendation could read as follows:

The solution SHOULD support the one-to-many traffic distribution model and MAY support many-to-many

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.
[Med] Thanks.

> 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.
[Med] ACK.

> 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?
[Med] Yes, I think that including such details would help. Thanks.

[NLK2]
Our -09 draft includes the following update (specifically the underlined text):

Note: In rare cases, collisions may arise after a temporary network partition, when different parts of the network allocate the same multicast address independently. Upon reconnection, such collisions SHALL be detectable and resolved gracefully by ensuring that conflicting streams are migrated to unique addresses.

Does this provide the right mix between describing behavior without getting too detailed?
[/NLK2]
[Med] I think that’s sufficient. Thanks.

> 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.
[Med] Thank you.

> 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.
[Med] OK. My comment was to clarify this in the requirements document. Of course, no need to mention the solution spec.

Is there an assumption that all standards documents are applicable unless stated or withdrawn?
[Med] No.

[NLK2]
OK, we moved RFC 3307 to a normative reference based on feedback from Deb. Do you think this is enough? Alternatively, how would you feel about modifying the first sentence of our IPv6 Considerations section as underlined?

The rules for IPv6 multicast addresses, described in RFC 3307, are comprehensive and well-organized, and MUST be followed by any solution allocating IPv6 multicast addresses.

I’m worried that’s a little redundant because we already list RFC 3307 as normative and describe it as containing “rules”. Another alternative might be replacing that sentence with something like this:

The requirements RFC 3307 contains for allocating IPv6 multicast addresses are comprehensive and result in a well-organized system.

Do either of those address your concern?
[/NLK2]
[Med] What about the following?

NEW:
The rules for IPv6 multicast addresses, described in RFC 3307, are comprehensive and well-organized. These rules must be followed by any solution allocating IPv6 multicast addresses, including solutions that meet the requirements defined in this document.

[NLK3] Looks good, thanks! This has been incorporated into v13.

> 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.
[Med] Thanks.

> 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?
[Med] What you have there is sufficient. I think we can park this one.

> 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.”
[Med] WFM .Thanks.

> 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?
[Med] Maybe: “The solution should work independent of the dynamics of the underlying topology and adjacencies.” ?

[NLK2]
OK, we added the following:

[CONS-7] Network Topology: The solution SHOULD work independent of the dynamics of the underlying topology and adjacencies.

[/NLK2]
[Med] Thank you.

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$>


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]