[pim] Mohamed Boucadair's Discuss on draft-ietf-pim-zeroconf -mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: 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:
----------------------------------------------------------------------

Hi Nathan, Dino, and Mike,

Thank you for the effort put into this document.

Unless I’m mistaken, there was not review check with mboned for this document.

Please find below few DISCUSS points:

# It is not clear to me what the “protocol” is supposed to do? What is the
expected outcome overall? What are the elements supposed to be involved for
that protocol?

Also, as I’m lacking a reference architecture, I may be missing obvious aspects
for the authors. For example, does collision mitigation lead to use of a
distinct address? What are the implications on applications bound to a
multicast group address? What about address discovery and announcement to other
members of the group?

Can we please clarify that?

# Compliance with 3307 as requirement

RFC3307 says:
   This document specifies guidelines that MUST be implemented by any
   entity responsible for allocating IPv6 multicast addresses.

Again, maybe this is obvious for the authors, but how do we expect to still
adhere to that MUST?


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

# Any reference to quote for the following:

CURRENT:
   Most
   marine networks are built on a single subnet and rely on Layer 2
   Ethernet switches to connect devices.

# Is this claim about SSM a generic claim or only specific to the marine case
mentioned in the introduction:

CURRENT:
   Cost-effective switches often do not support
   source-specific multicast (SSM), so IGMP snooping [RFC4541] is used
   to control multicast delivery.

Also, may be helpful to update this text to explain what is meant by not
support SSM in light of this discussion [1].

# What is the target deployment scope?

Is this a local network?

# Requirement 3: Protocol Coexistence

Which one will take precedence in such case? is that a concern at the first
place?

# Requirement 7

Should any assumption be made about the nodes motions/adjacencies/etc.? Should
those be frozen?

Cheers,
Med

[] https://mailarchive.ietf.org/arch/msg/mboned/ulvDZNBBm90d_LdtPePdS14msHQ/



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