Dear ANIMAers,

>>During the period of the adoption call, our draft-zhu-anima-lightweight-grasp 
>>(cGRASP) has received a few comments and discussions. All of these are 
>>greatly appreciated, and we will address them in the next update. We 
>>summarize the major discussion points below:

1)    Is CoAP-based cGRASP necessary and practicable?

The messaging model of CoAP can be reused, since CoAP has the congestion 
control and the retransmission mechanism. However, the CoAP “Request/Response” 
layer and the cGRASP transaction layer can not perfectly match, which is the 
key challenge to designing CoAP-based cGRASP.

2)    What are the typical application scenarios for cGRASP?

cGRASP can offer GRASP services for the constrained devices defined in RFC7228 
that can not use GRASP, but would be able to use CoAP or UDP.

3)    Is the 16-bit session ID reasonable?

The reduction from 32 to 16 bits for the session ID should be done carefully, 
since it will increase the chance of collision.

>>There is still a key point remaining open: CoAP-based or UDP-based?

CoAP has two sublayers: message layer and request/response layer. CoAP is 
RESTful and client/server-based, which conflicts with the cGRASP point-to-point 
transaction semantics. Thus, it’s challenging to map the cGRASP into the CoAP 
request/response. Since the two CoAP sublayers are coupled, although the 
reliability mechanisms in the CoAP message layer are useful to cGRASP, cGRASP 
cannot bypass the request/response layer to directly use the CoAP message layer 
without modification to CoAP itself.

>>Based on all the discussions and comments, we prefer the UDP-based version 
>>with a newly designed reliability mechanism, which is borrowed from CoAP.

>>And we are planning to make the following updates in the next draft versions:

1)     Clarify the typical application scenarios of cGRASP in the draft.

2)     Improve the design of  cGRASP mechanisms:

a)  Reconsider the length of the session ID.
b)  All the CBOR-related issues will be checked and corrected.
c)  Add a congestion control mechanism (if necessary).

We are also planning to develop an open-source prototype of cGRASP in the near 
future.

>>Thanks for all the reviews and advice. More comments are welcome.

Best regards,
Longwei Zhu




 
From: Toerless Eckert
Date: 2025-05-09 23:52
To: anima
CC: anima-chairs; mjethanandani
Subject: [Anima] Adoption call for constrained GRASP ( 
draft-zhu-anima-lightweight-grasp )
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
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org

Reply via email to