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

Gorry,

I apologize for the significant delay since my last reply. We posted draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-11 to address your concern:

https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/

Please see the last paragraph of section 2, which is new.

Also, regarding your DISCUSS about the RFC 2119 language, we are wondering if the note included at the end of section 1.1 is sufficient to address this. A similar approach is being used in this draft: https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/__;!!EJc4YC3iFmQ!SWcA284xHUtsvfPr_7Tr8tWk_uxUZOHmBQuyhZ2d5WJV96cVYtPP5Hr7SMZUh80-t5n9ySo6Jn8O4I-FFZi9eC2ZyR3f$>

Cheers,

Nate

From: Gorry Fairhurst <[email protected]>
Sent: Monday, November 24, 2025 08:19
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)

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 <gorry@ erg. abdn. ac. uk> Sent: Thursday,

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]><mailto:[email protected]>
Sent: Thursday, November 20, 2025 06:55
To: Karstens, Nate <[email protected]><mailto:[email protected]>; The IESG <[email protected]><mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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.



________________________________

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]