[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 free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/



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