Dear ANIMA-WG
Thanks a lot for the good discussion about subject draft adoption, which had
some solid support
for the work, but also cricism from Carsten Borman re. possible conflicts with
CoAP/Core work.
This email is approving the work for WG adoption, but hopefully with
the degree of sufficient detail to make it clear what is to be achieved and how.
---
First Let me try to unravel the goal of this proposed work first from the
discussion:
ANIMA/ANI is meant to support constrained node/link networks. For BRSKI we have
ongoing
work, for GRASP not. So it is not possible to build the ANI or any parts of it
that
rely on GRASP when constrained nodes or links are involved that can/do not want
to use TCP.
The draft currently proposes two approaches, I) without CoAP, II) with CoAP.
during the discussion on the list it became clear that that simple distinction
is not sufficient. Instead, there are three areas of investigation - not
all of them would necessarily lead to PoC/standardization:
1. Reliable/congestion controlled unicast UDP transport for GRASP - without
GRASP
This is likely a challenging option because of the feedback from Carsten re.
"reinventing CoAP". ANIMA typically attempts to re-use working IETF protocols
and only adds/extends when shown necessary.
Inventing a new reliable/congestion controlled transport for GRASP messages
over UDP will raise all type of questions of validation from WIT CC review,
as well
as "why re-invent, why not use CoAP".
So, if we wanted to re-use CoAPs reliable/congestion controlled transport
layer,
but not actual CoAP packet headers: that transport layer is not well
separately
specified, but i was proposing that extracting its behavior should be
possible.
However, it does not make sense to invest that work if IETF/CORE/WIT will
reject that option even if just on (not necessarily technicallly sound)
principle.
So this option first needs more discussion with CORE-WG/WIT, which likely is
easiest in person @IETF. Or even attempt to get onto one of the CORE meetings/
interims..
2. "constrained GRASP over CoAP" - unicast
2.a) The current draft describes actually one option to do this, by
implementing
GRASP simply as an "application" on top of CoAP - without changing CoAP.
2.b) There is also the option to extend CoAP with new CoAP message types
that would support (unicast) GRASP. Specifically synchronize/negotiate message
types which would be multi-round-trip reliable unicast message CoAP
transactions,
This would be more optimized, but likely would need good persuasion of CORE-WG
of the benefit.
3. Reliable/scoped multicast flooding for announcements/discovery
This third part is important and currently missing from the draft,
because there is no equivalent to GRAP's per-hop reliable multicast
forwarding.
For example, CoAP group communications is only relying on "outside"
multicast forwarding mechanisms such as IP multicast or MPL (RFC7731) neither
of which are reliable.
So, for this work element there seem to be three options:
3.a) As 2.a), simply defined as a CoAP application
3.b) As 2.b), aka: new CoAP message types. In this case, there
might be more interest by CORE-WG, because this could ultimately be
a CoAP standalone multicast option (removing dependencies from
third-party
multicast options mentioned above).
3.c) As 1), aka: if work item 1) can be defined (reliable UDP, no-coap layer)
then put GRASP multicast on top of it.
The authors have also confirmed that they are able and willing to do PoC
implementation
work for the draft. I think this is very positive, because in the past, the
absence of such a
commitment made it very hard to move forward some work in ANIMA WG because it
was to unspecific and could not be vetted. So the best practical way forward
beside discussions about the options with the affected parties, e.g.: CORE-WG
and
WIT seems to be to determine the most interesting practical PoC experiments
to help in decision making. For example, Michael Richardson was suggesting
to look at a feasible CoAP stack for constrained devices and check if/what
amount of additional code would be needed for e.g.: option 2.a) through PoC
work.
(Or how much change to the CoAP change there would need to be for 2.b).)
---
So: With this (sorry way too long) intro text, i would hereby want to
approve the draft for WG adoption because from the discussions, i think
we do have sufficient interest, but also the clear understanding and agreement
that the authors nor the WG can spend the cycles necessary for above without WG
adoption of the work.
The WG work goals on this draft are as follows:
- Investigate with affected parties (CORE-WG, WIT/CC) the acceptability/
interest of the different options from 1...3.
- Determine PoC work with the WG.
- Document in the draft goals, results of investigation and PoC.
- status of the document will be decided upon the progress made up to WGLC,
e.g.:
- If the results of PoC show sufficient feasiblity for standards track, we
go standards track with the spec.
- If the results of the PoC are incomplete, it could become experimental.
- If the results of PoC are insufficient for standards track / experimental,
the work invested should not be lost but instead be documented as
an informational WG doc.
- If discussions with CORE-WG turn out that an option should be pursued
that would require a CORE-WG draft, then this may also impact the
resulting status of whatever work is then still left to be documented
through the ANIMA WG draft.
So, authors, please submit
draft-ietf-anima-constrained-grasp-00
Note the change to "constrained", which was discussed in adoption thread, simply
to better match prior ANIMA work on constrained BRSKI so it is clearer that
this is for the same type of ANIMA/ANI networks.
Thanks a lot!
Toerless (for the chairs).
On Fri, May 09, 2025 at 05:52:59PM +0200, Toerless Eckert wrote:
> Dear ANIMA WG enthusiasts
>
> This email starts a three-week adoption call for drafts
>
> draft-zhu-anima-lightweight-grasp
>
> The timeline is longer than the usual two weeks because we have other drafts
> up for adoption call in parallel.
>
> [ Note that the file name only includes "lightweight" to make the revision
> history easier,
> the text already calls it constrained GRASP (cGRASP). It would/should be
> renamed
> to "constrained" during adoption. ]
>
> This draft has undergone already several rounds of improvements and good
> discussions on the list and during WG meetings. However, investing more
> substantial
> work into this effort would be much better spent if it was clear that the WG
> agrees to carry this effort through, and hence this adoption call.
>
> Constrained GRASP is a necessarily element for implementation of an ANIMA ANI
> on
> constrained devices without requirements for TCP. It even more so would be
> required
> by ASA on devices without TCP. This includes potentially even
> devices without IP, such as in BLE networks.
>
> Constrained GRASP could have benefits also for non-constrained environements -
> it could eliminate the need for different protocol approaches for
> constrained/unconstrained
> ANI environments.
>
> Also, cGRASP could provide in-network flooding that could aleviate the need
> to encumber
> IGP protocols with additional, non-routing related information that needs to
> be flooded.
>
> So, please review, provide feedback, also if you are interested to help
> as author or contributor.
>
> And as always: If you don't like something, please explain.
>
> ---
> Toerless Eckert (for the chairs)
>
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
