[pim] Re: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07 tel echat Rtgdir review

Jeffrey,

Thanks for your additional comments! My replies are below with NLK>. We submitted a -09 document with the changes noted.

Nate

From: Zhang, Zhaohui <[email protected]>
Sent: Wednesday, November 19, 2025 12:41
To: Karstens, Nate <[email protected]>; [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: RE: [pim] draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07 telechat Rtgdir review

Hi Nate, Please see zzh> below. From: Karstens, Nate <Nate. Karstens@ garmin. com> Sent: Tuesday, November 18, 2025 5: 59 PM To: Zhang, Zhaohui <zhaohui. zhang@ hpe. com>; rtg-dir@ ietf. org Cc: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps. all@ ietf. org;

Hi Nate,

Please see zzh> below.

From: Karstens, Nate <[email protected]<mailto:[email protected]>>
Sent: Tuesday, November 18, 2025 5:59 PM
To: Zhang, Zhaohui <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: RE: [pim] draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07 telechat Rtgdir review

Jeffrey,

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

> It seems that the problem space and requirements are about avoiding collision of MAC addresess

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's not that the snooping switches are "particularly vulnerable". It's that the collision makes mac-based snooping less effective.

We changed the sentence to read as follows:

…link-layer address collisions reduce the benefit of using multicast snooping switches on a network.

> If mac addresses hash to the same location, wouldn't less entries be used

This is how MAC filters work in many NICs, but the way these hash tables work is a little more sophisticated. The MAC address first identifies the bucket containing the entry, and then that bucket is searched for an exact match. Attempting to add a new address to a bucket that is already full results in a failure.

> Host-Level Multiplexing

Allocating different addresses is important for the devices receiving the data. A host may create multiple streams and a given device may not be interested in all of those streams. We updated the wording on this to better call this out:

Supports Host-Level Multiplexing: It should support multiple applications on the same host, each independently allocating multicast addresses and transmitting to those addresses.

Zzh> Is “Host-level Multiplexing” is a good term for the requirement of different applications on the same host to independently allocating addresses? Just a nit, and I don’t have a good suggestion either.

NLK> I see your point, “multiplexing” isn’t great. Thanks for pointing this out. We replaced this with “Supports Multiple Host Applications”

> Is this note a repetition of #7 above?

Not exactly, this is meant to highlight that just because an address appears to be unused when first allocated, does not mean that it is actually unused.

Zzh> Both #7 and this note talk about the situation of “no collision with partition but collision after merging” though. Just a nit.

NLK> Fair enough. We removed the description of partition from the list and left it only in the note.

> Isn't this the general problem that already described earlier?

Yes. We think the technical details are useful for understanding the challenges of using IPv4 and our preference for IPv6.

> Perhaps point out that the block significantly reduces the collision space (24-bit vs 23-it) … why is the last sentence necessary?

There isn’t anything special about the Administratively-scoped block because its lower 23 bits can still conflict with other blocks. We’ve added some text to help with the math there. The last sentence is probably not 100% necessary, but does help the reader understand the need to analyze the environment the zerconf algorithm is being deployed in (in that regard, it isn’t as “zero”conf as we would prefer).

Zzh> So why bother with the admin block?

NLK> We’d really like dynamic addresses, but the admin block is the closest thing we have on IPv4. The equivalent in IPv6 is Admin-Local scope; dynamic IPv6 multicast addresses set T=1 and use group IDs with the MSb set to 1.

> Perhaps emphasizing "mac address prefix".

I’m worried that would be redundant because the same sentence refers to “Ethernet multicast address”

> Can you elaborate on "32 separate, non-overlapping address ranges"? I had thought you were talking about 32 ethernet mulitcast mac address ranges (each with 23 bits), but perhaps not - since RFC5771 is only about IPv4 blocks.

We added an example to hopefully help clarify:

Another potential solution for IPv4 was to assign 32 separate, non-overlapping address ranges to avoid collisions altogether (e.g., assign 224.0.0.254, 224.128.0.254, 225.0.0.254, etc.).

Zzh> I still have trouble understanding this scheme. Can you explain how it works, perhaps with an example?

NLK> It’s not a great scheme – our goal was to provide enough of a description to indicate that we considered it and for the reader to understand why we didn’t go with it. The idea is that if we reserve a set of 32 IPv4 multicast addresses that all map to the same link-layer address, then we can use that address in dynamic address assignments. For example, if we want the multicast MAC address 01:00:5e:00:00:fe, then we would need to reserve the addresses 224.0.0.254, 224.128.0.254, 225.0.0.254, [28 addresses removed], 239.128.0.254). The cost/benefit for this is really terrible.

Zzh> Thanks.
Zzh> Jeffrey

> I am also curious why IPv6 multicast got its own 32-bit block of mac addresses and why it can't be used for IPv4.

I’m not sure :). The block used for IPv4 goes back to at least 1989. Thankfully, the designers of IPv6 took the opportunity to improve on this.

Best Regards,

Nate

From: Zhaohui Zhang via Datatracker <[email protected]<mailto:[email protected]>>
Sent: Friday, November 14, 2025 09:13
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: [pim] draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07 telechat Rtgdir review

Document: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps Title: Zeroconf Multicast Address Allocation Problem Statement and Requirements Reviewer: Zhaohui Zhang Review result: Has Issues It seems that the problem space and requirements are about


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

Title: Zeroconf Multicast Address Allocation Problem Statement and Requirements

Reviewer: Zhaohui Zhang

Review result: Has Issues



It seems that the problem space and requirements are about avoiding

collision of MAC addresess mapped from IP multicast addresses,

not about avoding collision of IP multicast address themselves.

This needs to be made clear early on in the abstract and introduction section.



   Second, networks that use multicast snooping switches are

   particularly vulnerable.  As described in [RFC4541], Section 4, many

   switches forward multicast traffic based solely on the link-layer

   address, without considering the network-layer group (see the results

   for Q2 and Q3).  In such cases, if two multicast streams share the

   same MAC address, traffic may be sent to devices that did not request

   it.  This is especially problematic when low-bandwidth links are

   overwhelmed by high-bandwidth streams.  Additional concerns related

   to the overlap of IPv6 and link-layer addresses are discussed in

   [RFC4541], Section 3.



It's not that the snooping switches are "particularly vulnerable".

It's that the collision makes mac-based snooping less effective.

"particularly vulnerable" and "less effective" are different.



   Third, the internal design of some switches can also contribute to

   collisions.  For example, certain switch implementations

   [US6690667B1] use hash tables to store forwarding entries based on

   MAC addresses.  If multiple addresses hash to the same location and

   the table fills up, additional entries may be dropped or rejected,

   resulting in forwarding failures.



If mac addresses hash to the same location, wouldn't less entries be used?

Additionally, even if we avoid mac address collition when allocating

IP multicast addresses, wouldn't this third problem still lead to issues

on these certain implementations?



In other words, this third problem does not seem to be related and

perhaps should be removed.



   6.  Host-Level Multiplexing: It should support multiple applications

       on the same host, each independently allocating and using

       multicast addresses.



This does not seem to be a real requirement?



I assume different applications on the same host will allocate different

multicastt addresses for their own usage; whether the mapped MAC address

are the same should not matter. I doubt that you're requiring that they

allocate the same IP multicast address.



   7.  Collision Detection and Resolution: The protocol should include

       mechanisms to detect and resolve multicast address collisions,

       including those that may occur due to network partitions and

       subsequent re-merging of segments.



   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

   should be detectable and resolved gracefully.



Is this note a repetition of #7 above?



   In IPv4, multicast addresses can sometimes cause conflicts at the

   Ethernet (link-layer) level.  As explained in Section 6.4 of

   [RFC1112], this happens because only the lower 23 bits of an IPv4

   multicast address are used to generate the Ethernet multicast

   address.  Since an IPv4 multicast address is 32 bits and starts with

   a fixed 4-bit prefix, this means up to 32 different multicast IP

   addresses can map to the same Ethernet address.  As a result, devices

   may receive multicast traffic they didn't ask for.



   The address allocation guidelines in [RFC5771] did not account for

   this type of collision when they were created.  Because of this

   limitation, the recommended approach for new designs that need

   dynamic multicast address assignment is to use IPv6 instead of IPv4.



Isn't this the general problem that already described earlier?



   However, if using IPv4 is necessary, then multicast addresses should

   be chosen carefully from within the Administratively Scoped Block

   (239.0.0.0/8).  Additionally, the protocol should try to avoid using

   addresses that may already be in use by other applications on the

   same network, to minimize the risk of conflicts.



Perhaps point out that the block signficantly reduces the collision space

(24-bit vs 23-it).

why is the last sentence necessary? Shouldn't it be a given (to avoid

IP multicast address collision)? Or are you saying to avoid addresses

whose last 24-bit conflict with other addresses' last 24-bit?



6.  Excluded Solutions



   The way multicast IP addresses are mapped to Ethernet (link-layer)

   multicast addresses is already defined in existing standards:

   [RFC1112] for IPv4 and [RFC2464] for IPv6.  These standards specify a

   fixed prefix used in creating the Ethernet multicast address.

   Changing this prefix would open the door to new solutions, but those

   are not being considered here for practical reasons.



Perhaps emphasizing "mac address prefix".



   Another potential solution for IPv4 was to assign 32 separate, non-

   overlapping address ranges to avoid collisions altogether.  But this

   was rejected because [RFC5771] discourages new allocations, given how

   limited the IPv4 multicast address space already is.



Can you elaborate on "32 separate, non-overlapping address ranges"?

I had thought you were talking about 32 ethernet mulitcast mac address ranges

(each with 23 bits), but perhaps not - since RFC5771 is only about IPv4 blocks.



I am also curious why IPv6 multicast got its own 32-bit block of mac addresses

and why it can't be used for IPv4.



Thanks.

Jeffrey







_______________________________________________

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.

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