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

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Question: 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?

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.



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