[core] Groupcomm-bis: proposed "groups" model updated based on IESG review

[Esko Dijk <[e-mail]>]

Hi all,

Me and Marco (authors of draft-ietf-core-groupcomm-bis) are processing 
the IESG reviews. One particular comment by Med triggered us to review 
the current "groups" model again (summarized in Figure 1).
We believe that this model would benefit from an update, as specified 
below. This mail is to inform the CoRE WG about this coming update so 
that people have an opportunity to react/agree/disagree.

The intended change will be on the group relation multiplicity: we 
currently say that an application group is always associated to exactly 
1 CoAP group; and it's implied by the text that this CoAP group has 1 
multicast IP address. (Not multiple.)
And we say a CoAP group can be identified by a hostname plus port, where 
the hostname would resolve to the 1 multicast IP address.

Now the comment was about dual-stack usage: what if the hostname 
resolves to an IPv6 address and an IPv4 address - then we would need 2 
CoAP groups; but our text suggests it would be treated as 1 CoAP group only.
(See for the original comments: 
https://mailarchive.ietf.org/arch/msg/core/6bjFRbSwzAvfdQqupIn9hCxB_OA/ )

More generally, indeed a single hostname can resolve to multiple 
addresses (IPv6 and/or IPv4), for example when DNS is used to resolve 
names to addresses. So we would need a text update to include this 
possibility.

Even when hostname resolution is not considered, there are still use 
cases for addressing a single application group through multiple IP 
addresses. A good example here is RFC 7252 / 6690 CoAP discovery. 
There's a single application group targeted, as defined by the URI path: 
/.well-known/core.
The CoAP group may differ based on the selected discovery scope: for 
example ff02::fd to discover link-local, ff03::fd to discover mesh-local 
e.g. on a 6LoWPAN network, or ff05::fd for site-local discovery.
So there are multiple potential CoAP groups associated to the same 
application group here. The same mechanism one might want to use for 
other use cases, such as IoT device control.
Example: query a sensor status in application group "ag1". The request 
could be sent to different CoAP groups based on desired scope.
  - send to "all.west.bldg6.example" - all nodes in the west wing of 
building 6.
  - send to "all.bu036.floor1.west.bldg6.example" - all nodes in office 
bu036 in that same west wing.
  - send to "ff03::fd" - all CoAP nodes in the same mesh network as the 
sender. Nodes that aren't part of the application group ag1 would ignore 
the request. Any ag1 members would respond.

All the above can be incorporated into our model if we make the 
following changes:

1) An application group can use one or more CoAP groups, instead of only 
one.

2) A CoAP group corresponds to exactly one pair (multicast IP address, 
port number).

3) A group URI can identify multiple CoAP groups at once. That's the 
case when the authority component is a registered name, which resolves 
to multiple IP addresses (irrespective of them being IPv4 and/or IPv6).

4) A CoAP client sending a group request can choose the target CoAP 
group based on implementation-specific rules in case it is configured 
with multiple CoAP groups, or in case it uses name resolution which 
yields multiple CoAP groups. It may be just "pick the first one". It may 
be "prefer IPv6". Or it may be something else.
   We don't plan to go into details here.

One thing to keep in mind is that in certain corner cases the number of 
associated CoAP groups could differ per node/server. For example, a 
server for which the IPv4 stack was just disabled would not be 
associated anymore to an IPv4 CoAP group, while another server in the 
same (application) group would still be.
Similar cases arise when e.g. an operator accidentally configures 3 
multicast IPv6 addresses (AAAA records) on the same hostname, while some 
constrained server nodes in the group only have a capability to listen 
on at most 2 multicast IPv6 addresses for a given application group.
Such cases seem all related to technical limitations, failures, or 
misconfigurations - but nevertheless they can occur. From a high level 
viewpoint, the application group is still associated to multiple CoAP 
groups, when taking the union of such information across all group members.

A PR with text for this change will follow later. Meanwhile any inputs 
are welcome!

best regards
Esko & Marco

-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339