[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-zer oconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)

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.

> A way to address this is to replace the "new protocol" with a "solution"

Mohamed had a similar suggestion. We updated the document accordingly.

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

> [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.

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

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

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

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

> "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/).

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

> 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]>
Sent: Wednesday, November 19, 2025 08:33
To: The IESG <[email protected]>
Cc: [email protected]; [email protected]; [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.

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]