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