[pim] Ketan Talaulikar's Discuss on draft-ietf-pim-zeroconf- mcast-addr-alloc-ps-09: (with DISCUSS and COMMENT)

Ketan Talaulikar has entered the following ballot position for
draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-09: 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.

Note: this ballot is updated based on the v09 of the document and the discuss
numbers that are still open are retained as-is while closed discussion and
comments have been removed.

Please find below discussion points inline in the idnits o/p of v08 of this
document:

<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.

Uber Comment: 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?

Nate> We believe that there is benefit to documenting problems with the status
quo and providing metrics that future solutions (such as
draft-ietf-pim-ipv6-zeroconf-assignment and draft-ietf-pim-gaap) can be
evaluated by.

KT> There is a difference between documenting and publishing as an RFC. I don't
see the long term benefit of publication of the document given the state of the
solution work. There are plenty of examples where such work is adopted but not
published as an RFC. Anyway, this was not a technical point and I will leave
this to the WG and the responsible AD's call. I'll move this down into comments
just to make sure it is not seen as a DISCUSS

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?

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.

<EoRv08>



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