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