[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 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]
To unsubscribe send an email to [email protected]