[pim] Re: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07 iet f last call Tsvart review

Joe,

Thanks for your review! We uploaded draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08 and made changes based on your feedback:

> The document appears to be about selecting multicast IP addresses to avoid link address collisions, rather than IP address collisions. That should be made more clear in the title, abstract, intro, and throughout…

I’m hesitant to change the document title because it would narrow the focus too much are take away from the requirements (which are important for some following docs), but we added a few key references to “link-layer address collisions” early in the document to direct the user’s attention to this earlier.

> It also appears that the limited number of hardware address filters has been overlooked; i.e., if a device is capable of filtering only 4 multicast addresses in hardware, the device would more efficiently support 7 addresses if at least 3 DID collide, rather than ensuring that none collide.  When no addresses collide and the number of filters is exceeded, the network interface is driven into promiscuous mode that requires software filtering – i.e., it completely undermines the goal of this doc.

I understand what you’re saying here. Two things would have to happen for this to be a problem: 1) the device would have to be installed in an environment where there are more multicast streams that it is interested in than it has filters for and 2) the switching infrastructure would not use multicast snooping (in a sense, it follows that in a network with multicast snooping, devices offload their multicast filtering to the switch).

However, this problem is already faced in existing networks. Fixing this would require multicast streams be grouped according to the data that target devices are interested in instead of the data that the device is providing. This is more difficult to coordinate in practice, less flexible, and does not scale well.

> address assignment should be referred to as IP address assignment

Makes sense, we updated a few places to clarify that.

> The protocol requirements need some refinement. Resistance to failure is NOT the same as robustness to a single point of failure; the tag phrase and the definition need to be adjusted to align. Item 3 is “multicast self-assignment protocol coexistence”, i.e., this isn’t about interoperation with other protocols in general. Item 7 (collision detection and resolution) is not a requirement; it is an approach to satisfying other requirements, such as 1, 2, and 5. It would help if the tag phrases were similar (they seem to be phrases
defining properties, except for #6, which should be “supports host-level multiplexing” – check this throughout for all lists).

We updated those titles as suggested. I don’t think item 7 is adequately captured by other requirements and so we left that in the list, but are willing to discuss more.

> The Note needs revision; the collisions arise after *rejoining disconnected networks caused by* a temporary network partition. I.e., it is the rejoining that causes the problem, not the partitioning.

This would somewhat imply that a partitioned network could operate correctly, but partitioning causes problems with traffic distribution because multicast streams are no longer able to reach all intended targets.

> The second list should describe goals of a design; it seems odd to include “cross-platform availability”, as this seems to conflate deployment with OS capabilities; it is difficult to appreciate what OS properties could ever interfere with these mechanisms. An example would help as would rephrasing this as “OS independence”.

This is meant to indicate that solutions that bespoke solutions are less desirable than those that are available on a wide variety of platforms.

> Sec 5 should more clearly relate the way 32 IP addresses could map to the same MAC address, i.e., this is because only the lower 23 bits are used of the 28 bits in the IP multicast address range. It would be very useful if the reason for this mapping were discussed in this doc – i.e., why did we not just use all 28 bits?

We added some text to clarify the math there:

Since an IPv4 multicast address is 32 bits and starts with a fixed 4-bit prefix (leaving 28 bits), this means up to 2(28-23) = 32 different multicast IP addresses can map to the same Ethernet address.

I’m not sure why 28 bits were not used – that decision goes back to at least 1989. In section 6 we mention that we considered proposing a new prefix for IPv4 mapping, but decided against it because, even if everyone agreed to it, it would take too long to make its way into host network stacks.

> Sec 5 seems to suggest a revision of RFC 5771 is warranted. Simply saying “that doesn’t work, so you should use IPv6” is not realistic. Further, using addresses from /8 blocks (admin scoped) still requires care; it would be useful to remind designers that they should ensure that the bottom 23 bits are unique, i.e., to NOT rely on the top bit there (or in other multicast addressing) for independence

We were trying to avoid solutions that would require too much change to existing infrastructure. IPv6 supports more multicast streams and it is structured better because its larger address space allows for this. IPv4 can still be used, it just needs more care when deployed.

> Sec 6 should reconsider the advice to not revise RFC 5771 assignments. I.e., new systems could select addresses in ways that avoid collisions, which could relieve even legacy systems from the effect of collisions in switches.

I’m not necessarily against someone trying to revise that, though it would be a long-term investment that might never pay off because the industry appears to be trying to transition to IPv6. In any case, it seemed out of scope for this document.

Best Regards,

Nate

From: Joseph Touch via Datatracker <[email protected]>
Sent: Thursday, October 9, 2025 11:24
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: [pim] draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07 ietf last call Tsvart review

Document: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps Title: Zeroconf Multicast Address Allocation Problem Statement and Requirements Reviewer: Joseph Touch Review result: Ready with Issues This document has been reviewed as part of the transport


Document: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps

Title: Zeroconf Multicast Address Allocation Problem Statement and Requirements

Reviewer: Joseph Touch

Review result: Ready with Issues



This document has been reviewed as part of the transport area review team's

ongoing effort to review key IETF documents. These comments were written

primarily for the transport area directors, but are copied to the document's

authors and WG to allow them to address any issues raised and also to the IETF

discussion list for information.



When done at the time of IETF Last Call, the authors should consider this

review as part of the last-call comments they receive. Please always CC

[email protected]<mailto:[email protected]> if you reply to or forward this review.



--



There are no transport issues in this document.



However, the following two key issues appear to be significant and should be

addressed.



The document appears to be about selecting multicast IP addresses to avoid link

address collisions, rather than IP address collisions. That should be made more

clear in the title, abstract, intro, and throughout. The current text is easily

misread as focusing on IP address collisions until section 2.



It also appears that the limited number of hardware address filters has been

overlooked; i.e., if a device is capable of filtering only 4 multicast

addresses in hardware, the device would more efficiently support 7 addresses if

at least 3 DID collide, rather than ensuring that none collide.  When no

addresses collide and the number of filters is exceeded, the network interface

is driven into promiscuous mode that requires software filtering – i.e., it

completely undermines the goal of this doc.



The follow comments are also provided, if useful:



The document jumps between link and network issues without enough context for

the reader to distinguish between the two. Collisions should be referred to

throughout as link address collisions, not just address collisions, and address

assignment should be referred to as IP address assignment.



The protocol requirements need some refinement. Resistance to failure is NOT

the same as robustness to a single point of failure; the tag phrase and the

definition need to be adjusted to align. Item 3 is “multicast self-assignment

protocol coexistence”, i.e., this isn’t about interoperation with other

protocols in general. Item 7 (collision detection and resolution) is not a

requirement; it is an approach to satisfying other requirements, such as 1, 2,

and 5. It would help if the tag phrases were similar (they seem to be phrases

defining properties, except for #6, which should be “supports host-level

multiplexing” – check this throughout for all lists).



The Note needs revision; the collisions arise after *rejoining disconnected

networks caused by* a temporary network partition. I.e., it is the rejoining

that causes the problem, not the partitioning. The second list should describe

goals of a design; it seems odd to include “cross-platform availability”, as

this seems to conflate deployment with OS capabilities; it is difficult to

appreciate what OS properties could ever interfere with these mechanisms. An

example would help as would rephrasing this as “OS independence”.



Sec 5 should more clearly relate the way 32 IP addresses could map to the same

MAC address, i.e., this is because only the lower 23 bits are used of the 28

bits in the IP multicast address range. It would be very useful if the reason

for this mapping were discussed in this doc – i.e., why did we not just use all

28 bits?



Sec 5 seems to suggest a revision of RFC 5771 is warranted. Simply saying “that

doesn’t work, so you should use IPv6” is not realistic. Further, using

addresses from /8 blocks (admin scoped) still requires care; it would be useful

to remind designers that they should ensure that the bottom 23 bits are unique,

i.e., to NOT rely on the top bit there (or in other multicast addressing) for

independence.



Sec 6 should reconsider the advice to not revise RFC 5771 assignments. I.e.,

new systems could select addresses in ways that avoid collisions, which could

relieve even legacy systems from the effect of collisions in switches.







_______________________________________________

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]