[WG chair hat off - to chime in with my own opinions]
Thanks a lot for the work to the authors so far. I think constrained GRASP is
very important
for ANIMA not only to allow a complete "TCP-free" constrained ANI with an ACP
not relying on TCP, but also for ASA to ASA communications on constrained
devices
without the need for TCP stack. And:
For me, reliable flooding of information (such as service announcements) or
discovery (flooding of discovery) is the biggest benefit of GRASP that no other
existing IETF protocol can provide (they all rely on servers or multicast, and
multicast across router hops is difficult). So i am particularily excited that
flooding could be done a lot better with cGRASP than GRASP due to the absence
of TCP
(i'll describe details later).
In general i think there is a good amount of work that needs to be done to get
the draft
into the shape i would like to see it in, but if we can agree on the goals,
then i would
rather like to see that work done as an adopted WG draft than as an individual
document
(as i already wrote in the adoption call email).
How level what i would like to see:
1. Structure: There needs to be a better distinction between the different type
of changes
from GRASP to cGRASP:
1.1. The additional information carried in a cGRASP message not in a GRASP
message
so that it can run over UDP. Aka "Nonce", Acknowledgment info and the like
1.2. New / changed information elements not related to 1.1, aka: in the GRASP
header as it would be even if running over TCP. Those information element
changes could be because there where bugs or the like in RFC8995 or for
other
reasons.
1.3 Elements removed from the RFC8995 GRASP headers (if any), e.g.: for
optimization.
2. Choice between CoAP and UDP:
I think it would be great to agree on the relationship between cGRASP and
CoAP.
Here is my opinion:
2.1. I don't think we should ever use CoAP. I just can't see how CoAP overall
would be
anything but a pain and duplication of effort. Unfortunately, CoAP is not
modularily
defined with multiple layers, so we would always need to put cGRASP inside
of a
CoAP header, and that involves using some CoAP Method Codes, where we then
either
need to also add (unnecessary) URI fields into the packet, or have useless
struggles
with the CoAP folks to get our GRASP message type(s) be recognized as new
Code's
for CoAP. And extending CoAP with multiple GRASP message types really does
not sound
like a good method. What if the next protocol like GRASP wants to use CoAP
reliability...
But (c)GRASP is just not request/reply based, so the existing CoAP Code
points are
just unnecessarily complex for cGRASP also from that point.
2.2 However, i very much would like to re-use the CoAP "messaging model", aka:
how messages over UDP are made reliable and in a limited fashion
flow-controlled.
I think the spirit of cGRASP reliability already does this, but it neither
says
so explicitly, nor is it consistent in terminology (e.g.: Nonce in cGRASP
instead of
Message ID in CoAP), nor in functionality. Aka: no specification of
exponential
backoff in retransmission, values for default parameters, no specification
of
the congestion control with NSTART or the like.
Motivation: The biggest challenge of cGRASP will be to prove to WIT IESG
review that we
have a working reliability mechanism with flow-control sufficient for the
target
deployment targets. And given how we do not want to re-invent the wheel, i
think
the easiest way to get through this and feel confident about what we do is
to simply
use CoAPs model. We just need to extract the relevant functionality from
the CoAP
RFC (which alas is not written too modular).
I think CoAP is exactly the right protocol to steal/get this
reliability/flow-control layer
from, as it is the most widely deployed, IETF specified protocol, over UDP
AFAIK.
Ultimately this also means the transport layer for cGRASP is a good amount
of textual
spec work more - but NO actual functional novelty that we would have to
verify,
prove and optimize. Just extracting/copying the right text!
3. I think we do need a section for cGRASP relays:
GRASP relay, every message needs potentially be copied and buffered
separately to every
GRASP neighbor, and if there is even short term congestion, then those TCP
buffers can
become large.
On a cGRASP relay, reliability and flooding are joint in a single protocol
layer.
Hence a cGRASP relay can simply keep each message to be floowed in a single
buffer,
generate a Nonce (aka: CoAP transport Message ID) for it and then just keep
the list
of cGRASP neighbors from which it has not received an acknowledgemenet for
it.
In addition, also the flooding can easily be optimized: In redundant
networks and using
TCP, a message may need to be resent unnecessarily because it is in a TCP
buffer,
but the same message was already received by the peer from another redundant
path and
is being sent back. With cGRASP integrating reliability and flooding, it is
easy to
discover this situation: find received message by session-id. If we already
have it,
we mark the peer from which we received it as alreasdy having the message
and cancel
any outstanding retransmissions.
When we start to go into this direction, we are btw. getting very much into
IGP territory,
where ISIS and OSPF are very much beloved to flood all type of
"not-necessarily-core-routing"
related information - and both protocols struggle in whether or how much of
such
extraneous information they may want to flood. cGRASP could become an
interesting alternative.
The flooding in ISIS/OSPF has two more optimizations to make them more
scalable which we
could IMHO also add if we wanted).
Also textual note: the -03 version says that we MUST NOT make flood sync
messages reliable,
but of course the opposite is true. _The_ big benefit of cGRASP is
lightweight, hop-by-hop
reliable flooding.
4. I would restructure the "non-IP considerations" under a new section for
"link-local" GRASP, describing all options of cGRASP without the presence of
any GRASP relay (aka: DULL plus cGRASP unicast link-local), and then include
the
option for non-IP encapsulations in that. Because that's ultimately the
limiting
characteristics:
- We could use GRASP relays to forward cGRASP messages between multiple
non-IP
networks (mesh of BLE or the like), but because we do not want to re-invent
unicast forwarding, but we do need unicast end-to-end connectivity, this
solution
will not fly. So all the considerations for BLE without IP have to stay
within a single
L2 network.
Cheers
Toerless
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)
>
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
