Hi,

I agree with Toerless (except that I don't understand COAP well enough to
have a strong opinion). The change to "constrained" instead of "lightweight"
is good, because it gives better focus. I support adoption.

One detail: when developing RFC 8991 we were given very strong advice to
avoid the word "nonce" as some people find it offensive (it has a slang
meaning in British English). We switched to "handle" in that RFC. But given
that GRASP and cGRASP both have a pseudo-random "session-id", why not simply
call it "message-id"?

I am a little concerned by the reduction from 32 to 16 bits for the session-id.
It very significantly increases the chance of collision. Section 2.7 of RFC 8990
does cover this (and section 3.1 of draft-zhu-anima-lightweight-grasp-03 covers
the same risk for the nonce/message-id). With only 32 bits this is a real
issue, not a theoretical one.
Regards
   Brian Carpenter

On 10-May-25 03:56, Toerless Eckert wrote:
[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)



_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org

Reply via email to