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
