Re: [pim] WG adoption call for draft-karstens-pim-zeroconf-mcast-addr-alloc-ps-01

["Stevens, Jim A Collins" <[e-mail]>]

> Message: 1
> Date: Tue, 29 Aug 2023 09:49:28 -0700
> From: Stig Venaas <[e-mail]>
> To: [e-mail]
> Subject: [pim] WG adoption call for
>       draft-karstens-pim-zeroconf-mcast-addr-alloc-ps-01
> Message-ID:
>       <CAHANBtKQ8VWYLCY65V1RLY--
> [e-mail]>
> Content-Type: text/plain; charset="UTF-8"
>
> Dear WG
>
> At our meeting in San Francisco there seemed to be good support for adopting
> draft-karstens-pim-zeroconf-mcast-addr-alloc-ps-01 as a WG document. See
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-karstens-
> pim-zeroconf-mcast-addr-alloc-
> ps/__;!!MvWE!E7ihmyo1X8uQYSPwXWLBMISHsvzbSp0-JMVCFxEBTW21-
> i7S6GiRKX9KCuR53Oue7VMEb-otKs5pYOzeZIKUpslwBoxq7Fn2$
>
> We still would like to check on the mailing list how many people are in favor,
> and whether there are any objections or concerns.
>
> Please respond by Friday September 8th whether you believe it is ready or not
> and any comments you might have.
>
> Thanks,
> Stig
>
Stig,


Sections 2 & 5 of the draft document discuss address collisions at the link layer.  Section 5 specially addresses IPv4 considerations including discussion of the fact the IPv4 mapping to 802 addressing causes a collision at the link layer from multiple IPv4 multcast groups

Here is a link to an email thread mboned working group where I asked if we could solve that IPv4 to 802 multicast address collision problem the conclusion was that this was not a big issue to be worth the pain of making change. https://mailarchive.ietf.org/arch/msg/mboned/NoRz8S8b0DVGUQNtsAqVONs-atE/

I'm curious to see what this group thinks about need or potential interest in solving the IPv4 to 802 multicast address collision.  (and yes, I recognize that there is a large overlap between pim working group and mboned working group members)


Section 3 describes protocol requirements.

I work mostly with military mobile ad hoc networks (MANETs) where is it is quite common for radios/nodes to power up and form networks that then merge and split.  the address assignment problem that handles these type of collisions when networks merge is a significant issue.  And often these wireless nodes are in the same IP subnet whether merged or split - so that these wireless networks form what are called multi-link subnets in RFC 4903.

I would like to add multi-link subnets to the protocol requirements.  (I would prefer as a MUST but understand that the group might want to make this a SHOULD.)


Some other related references to duplicate address problem in multi-link networks are

https://datatracker.ietf.org/doc/html/draft-ietf-ipv6-multilink-subnets-00 section 4.1.3 addressed this problem in general for duplicate address detection.

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7248394 Efficient 6LoWPAN Neighbor Discovery Applied to Multilink IoT Subnets and issue of address collisions

file:///C:/Users/jasteven/Downloads/Multi-Link_Support_for_IPv6_Networks.pdf for autoconfiguration of MULTI-LINK SUPPORT FOR IPV6 NETWORKS

https://datatracker.ietf.org/doc/html/draft-ietf-intarea-ippl-00 IP over Intentionally Partially Partitioned Links


In summary, I support moving forward on this draft as a WG document.


Jim