[pim] Re: Gorry Fairhurst's Discuss on draft-ietf-pim-zero conf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT)

On 20/11/2025 22:24, Karstens, Nate wrote:
>
> Gorry,
>
> Thanks for taking another look! My replies are in-line below and 
> denoted with *[NLK]*. Also, we posted a new version: -10.
>
> Nate
>
> *From:*Gorry Fairhurst <[email protected]>
> *Sent:* Thursday, November 20, 2025 06:55
> *To:* Karstens, Nate <[email protected]>; The IESG <[email protected]>
> *Cc:* [email protected]; 
> [email protected]; [email protected]
> *Subject:* Re: [pim] Gorry Fairhurst's Discuss on 
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT)
>
> Nate, I'm going to top-post on this thread to try to resolve what I 
> think are the final issues from me. I appreciate the changes that have 
> been introduced (the latest I read was -09). These go a long way to 
> address my concerns, and I think this
>
> Nate, I'm going to top-post on this thread to try to resolve what I 
> think are the final issues from me.
>
> I appreciate the changes that have been introduced (the latest I read 
> was -09). These go a long way to address my concerns, and I think this 
> is producing a much more useful and clearer document, many thanks.
>
> There are a few small issues introduced by these updates, because 
> these are now formal requirements, I have re-read the document and 
> considered each more carefully.
>
> REQ-1,3,4, 6 all seem OK to me; I expect the following might be easy 
> to resolve:
>
> 1) ** REQ-2 ought not be adjusted a little (because as worded it's not 
> a protocol requirement), rather it seems like a design goal , I'd suggest:
>
> The solution SHALL be designed to minimise introduction of a single 
> point of failure, ensuring that operation continues even if individual 
> devices or links become unavailable.
>
> **
>
> *[NLK] This wording looks OK to me!*
>
OK, thanks.
>
>
> 2) ** REQ-5 I question if the word "effective" is useful in a 
> requirement (could we delete that word? ... or if you feel 
> necessary... then explain how this will be evaluated)
>
> *[NLK] We removed the use of the word “effective”.*
>
:-). Thanks also.
>
>
> 3) ** REQ-7 I think this needs to also consider that some endpoint 
> hardware can filter only a limited number of multicast addresses (see 
> comment 1 in my IESG Comments).
> Please let me know your thoughts and hopefully we can soon resolve all 
> my issues. I expect to then clear my DISCUSS.
>
> *[NLK]*
>
> *REQ-7 is related to allocating addresses and sending to them (hosts 
> can transmit to multicast groups that they are not a member of). *
>
*Sure, that is of course vert true (it could be mentioned if helpful;.*
>
> *These filters are used when receiving.*
>
*Right.*
>
> **
>
> **
>
> *This is my reply to Joe’s original comment:*
>
> **
>
> *I understand what you’re saying here. Two things would have to happen 
> for this to be a problem: 1) the device would have to be installed in 
> an environment where there are more multicast streams that it is 
> interested in than it has filters for and 2) the switching 
> infrastructure would not use multicast snooping (in a sense, it 
> follows that in a network with multicast snooping, devices offload 
> their multicast filtering to the switch).*
>
> **
>
> *However, this problem is already faced in existing networks. Fixing 
> this would require multicast streams be grouped according to the data 
> that target devices are interested in instead of the data that the 
> device is providing. This is more difficult to coordinate in practice, 
> less flexible, and does not scale well.*
>
> **
>
> *Does that help clarify anything?*
>
*I agree with what you have written, yet also I'd like to see this 
scaling issue noted in some way... **
*

*Separating traffic into different groups can enable hardware-based 
filtering in the network layer. The success of this approach depends 
on** the size of tables maintained in switches/routers and on the number 
of multicast groups that are **subscribed to by** a particular receiver 
(where there may be limits for a particular interface).  When the 
**number of entries in the filter tables is exceeded, the receiver 
incurs a per packet cost for any software-based filtering that is needed.*

> **
>
> *[/NLK]*
>
> Best wishes,
> Gorry
>
I don't know that these need to be stated as RFC-2119 requirements 
(check with your Responsible AD), but I think we are heading in a good 
direction for their description.

I am therefore happy to clear my DISCUSS when a new revision emerges 
that addresses these topics.

Gorry

>
>  ----
>
> <<snip>>
>
> On 18/11/2025 22:57, Karstens, Nate wrote:
>
>     Gorry,
>
>     Thanks for your review! We uploaded
>     draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08 and made changes
>     based on your feedback:
>
>     > there are no formal requirements based on RFC-2119 keywords derived
>
>     You are right. We updated section 3 to use requirements language.
>
>     > I expect the declaration of keywords can also be removed
>
>     I see your point – this document, being informational, does not
>     impose any requirements. It does document requirements for other
>     protocols, but this is different than imposing its own
>     requirements. I’m not sure if we should remove the reference to
>     RFC 2119 et al. It is useful in interpreting the language in
>     section 3. It may be most appropriate to move these references to
>     the list of informational references?
>
>     > From the TSV_ART review…
>
>     We’ve incorporated updates from this review.
>
>     Best Regards,
>
>     Nate
>
>     *From:*Gorry Fairhurst via Datatracker <[email protected]>
>     <mailto:[email protected]>
>     *Sent:* Monday, October 20, 2025 07:19
>     *To:* The IESG <[email protected]> <mailto:[email protected]>
>     *Cc:* [email protected]
>     <mailto:[email protected]>;
>     [email protected] <mailto:[email protected]>; [email protected]
>     <mailto:[email protected]>
>     *Subject:* [pim] Gorry Fairhurst's Discuss on
>     draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: (with DISCUSS and
>     COMMENT)
>
>     Gorry Fairhurst 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
>
>     Gorry Fairhurst 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!Sh0STv2fUKkYSFJv0dneOqISoNnD-CP2_kbiVw7u1vK0CcltJubqbgwaC4Q7NGpNYwAI5MyCK8FTjQUfWw$ <https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!Sh0STv2fUKkYSFJv0dneOqISoNnD-CP2_kbiVw7u1vK0CcltJubqbgwaC4Q7NGpNYwAI5MyCK8FTjQUfWw$>
>
>     for more information about how to handle DISCUSS and COMMENT
>     positions.
>
>     The document, along with other ballot positions, can be found here:
>
>     https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!Sh0STv2fUKkYSFJv0dneOqISoNnD-CP2_kbiVw7u1vK0CcltJubqbgwaC4Q7NGpNYwAI5MyCK8HdhfdgYQ$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!Sh0STv2fUKkYSFJv0dneOqISoNnD-CP2_kbiVw7u1vK0CcltJubqbgwaC4Q7NGpNYwAI5MyCK8HdhfdgYQ$>
>
>     ----------------------------------------------------------------------
>
>     DISCUSS:
>
>     ----------------------------------------------------------------------
>
>     (1) The documents says it defines requirements.
>
>     I saw in the abstract this statement:
>
>     "The document presents explicit requirements covering discovery",
>     but yet from
>
>     a standards perspective it does not - there are no formal
>     requirements based on
>
>     RFC-2119 keywords derived. That may well be suitable for an
>     Informational
>
>     document, and I expect the declaration of keywords can also be
>     removed, and
>
>     this sentence could be rewritten as guidance for future work
>     rather than
>
>     requirements?
>
>     (2) From the TSV_ART review:
>
>     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.
>
>     Can this be clarified in the document?
>
>     (3) The TSV_ART review suggested:
>
>     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.
>
>     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?
>
>     Can this be clarified in the document?
>
>     ----------------------------------------------------------------------
>
>     COMMENT:
>
>     ----------------------------------------------------------------------
>
>     Thank you Joe Touch for his TSV-ART review, I'd like to pick-up on
>     the issues
>
>     discussed there, so include them here:
>
>     (i) It also appears that the limited number of (host) 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.
>
>     (ii) 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).
>
>     (iii) 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”.
>
>     ... Please see additional comments in the review that may also be
>     helpful.
>
>     _______________________________________________
>
>     pim mailing list -- [email protected] <mailto:[email protected]>
>
>     To unsubscribe send an email to [email protected] <mailto:[email protected]>
>
>     ------------------------------------------------------------------------
>
>
>     CONFIDENTIALITY NOTICE: This email and any attachments are for the
>     sole use of the intended recipient(s) and contain information that
>     may be Garmin confidential and/or Garmin legally privileged. If
>     you have received this email in error, please notify the sender by
>     reply email and delete the message. Any disclosure, copying,
>     distribution or use of this communication (including attachments)
>     by someone other than the intended recipient is prohibited. Thank you.
>
>
> ------------------------------------------------------------------------
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the 
> sole use of the intended recipient(s) and contain information that may 
> be Garmin confidential and/or Garmin legally privileged. If you have 
> received this email in error, please notify the sender by reply email 
> and delete the message. Any disclosure, copying, distribution or use 
> of this communication (including attachments) by someone other than 
> the intended recipient is prohibited. Thank you.

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