Re: [Anima] comments on draft-ietf-anima-grasp-api

Brian E Carpenter <> Sun, 22 September 2019 23:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA0F11200B9 for <>; Sun, 22 Sep 2019 16:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BvY3-rDOxKCu for <>; Sun, 22 Sep 2019 16:47:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1134E120024 for <>; Sun, 22 Sep 2019 16:47:08 -0700 (PDT)
Received: by with SMTP id a24so6930486pgj.2 for <>; Sun, 22 Sep 2019 16:47:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Kv2oeYO7WVJkLsIOsO252AZdAdHNkLQazb50Q+QAoR8=; b=R9tyx+CB2YqqPSFD96zWtxBMAfWkAmcazZzAnudwjhpCucZ1JDjdu3P3XF0MD/tzR7 jKu2XhYt61eChr0HTM2MMjVoI3HZVum6tAMuD0975JK9xPebw3ClTt7nXJaULX68t/HK pPcF3gcWzAZ9iJ3frSpSQt3KV3sNEiL8nM8iR8+M3cTVHAajXkNsAAYFEj061g/wQ22m KqYd1SfsWSBeD9dLSmUfnfzUmO/PYJwowgpdY9SqBUEJ59pcaFmmyT/nQ+gA5AD8RcN+ oOC5SplxLWXmCpHgLsV7FcusR7A5Td3uQgPQlI59RMMNHsPlO6c1dOnmJtcROI4pxgwf eR4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Kv2oeYO7WVJkLsIOsO252AZdAdHNkLQazb50Q+QAoR8=; b=so3/9wlAlV7lxMg9X7/29bKVRT5+7oW+luoWfObXRBwXD/8vWl/vC6AETIcXKf+YTh f2w9bqkX+g5Twoq3uFh05tF/GeOSgU53qe20dK8AtFS2U/PNxkGSoo8ru2G501yua1yX LDZAGt82XStPZxxad2P6leZK6llyZ0dPhfhM7wbQw/eLMVWZpvySgs9ZoVLg5ZfkDEMq OFFUn80U2CwR25gYBraKppOI0+HO3Jo8BppWXM+LWtXxDOhlTD0P0QbCL4OGkhYQ79Q5 t7YSGtUD6MBs+E7oAgHOJZ5dl/Zv+WL6AO5h3DiVQ5WW5SpufGIGXVNMBBhJYYX9VeYg r0kw==
X-Gm-Message-State: APjAAAWJZU9wyja9cyL1P/kNPZa8Ak33XZpdjAxbtF4CBB+4vaPHysCi +NKLL9F61Nb4a3CvSPPi0RQ9+foh
X-Google-Smtp-Source: APXvYqx1/7utz4J8AwStsoR6T7tHtziy4A/yLknP1siahzqXEFfL4UygHtigUWHA1rgc7YQ2z/eBtQ==
X-Received: by 2002:a63:1c4b:: with SMTP id c11mr23978979pgm.216.1569196027286; Sun, 22 Sep 2019 16:47:07 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id c7sm6454825pfr.75.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Sep 2019 16:47:06 -0700 (PDT)
From: Brian E Carpenter <>
To: Michael Richardson <>, "" <>
References: <5523.1565112243@localhost> <>
Organization: University of Auckland
Message-ID: <>
Date: Mon, 23 Sep 2019 11:47:06 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] comments on draft-ietf-anima-grasp-api
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Sep 2019 23:47:11 -0000

With notes added while starting to update the draft:

On 07-Aug-19 14:28, Brian E Carpenter wrote:
> Thanks very much Michael. Some partial responses below.
> On 07-Aug-19 05:24, Michael Richardson wrote:
>> I read draft-ietf-anima-grasp-api from the expired drafts list.
> Right, the -03 draft expired while we were in Montreal. Our plan
> is to make the next update after the two promised reviews arrive.
>> I think that the event-loop architecture is different than a
>> polling architecture.  I agree that given an event-loop architecture,
>> that one can build a polled architecture, but the converse is not true.
>> The event-loop mechanism needs something to send events, while the polling
>> system does not.
> My understanding is limited, but the diagram at
> seems to say something different: the loop detects events by
> polling. (Yes, OK, that's talking about Javascript but the
> fundamentals are the same, surely?)

Following your comments and Guangpeng's we will try to considerably improve
and expand the text about this.

>> section
>> If you are going to insert C structures, why not use a real example?
>>   cbor_value -> cbor_item_t
> Yes, we can look at that. There are various CBOR libraries in C.

Actually it looks as if the type we need is cbor_mutable_data
(not a single item), sinc the GRASP "value" can be an arbitrary
data structure.

>> I don't understand what the asa_nonce is for.
> OK, then we need more text.
>> Is this something that the underlying GRASP library is supposed to use
>> internally to sort out which ASA is which?  Maybe this should be
>> either a UUID, or an opaque type, which might in some cases, be a file
>> handle, or contain one. (a la FILE *)
> Yes, it should probably be opaque. In fact the documentation of the
> concrete Python API says so: "Note - the ASA must store the asa_nonce
> (an opaque Python object) and use it in every subsequent GRASP call."

Again, we will improve the text.

>> 2.3.3 Discovery.
>>   1) I would prefer to be able to ask for the list of cached
>>      locators for an objective directly.
> OK, I can see that might be useful.

In fact, in the Python implementation, that's what you get from discover()
if the list is non-empty. Maybe we should change the meaning of timeout = 0
to mean what it says: simply return the list of cached locators as-is,
without waiting for discovery. I quite like that idea, since using
GRASP_DEF_TIMEOUT as the default for discovery timeouts was an abitrary
choice. Probably the ASA programmer should be forced to think about a
meaningful timeout.

>>   2) Rather than flush them explicitely (because there might be
>>      other ASAs depending upon them), I'd like to do a discovery
>>      that asks for objectives that are at at most X miliseconds old.
>>      Flush is therefore X=0.
> Hmm. I think we assumed you would only flush if you had reason to
> believe they were stale. But certainly adding an age limit seems
> reasonable.

Will do that - replace the flush parameter with age_limit.

>>   3) In both threaded and event-loop situations, I'd like to be able
>>      have a function called when there are new answers, otherwise,
>>      I have to poll.
> Right, that's a callback in event loop terminology. It's a matter of
> preference; I have an aversion to side effects so I don't like callbacks.
> However, you're probably right that it should be an option.

This will be explicit in the next version.
>>      (And, if a function is called, then the question as to which
>>      thread does the calling is important; specifically one needs
>>      to know which other functions one call at that point
>>      answer may well be none. The answer depends upon how locking
>>      of structures is done. The answer is easier in event-loop
>>      version)
> Yes; callbacks are a Bad Idea in a multithreaded version.

An ASA is responsible for the atomicity of its own transactions;
that's actually why I've been asserting that the session_nonce is
essential for callbacks. To be clear, GRASP negotiation messages
are *not* idempotent. So you can start several parallel negotiations
and they must be possible to distinguish from each other.
>> 2.3.4 Negotiation.
>>       Since the session_nonce is returned by the function, how
>>       can the dryrun/run ever be mixed in a single session?  maybe
>>       I don't know what a session is.
>>       Ah, it's a value/result parameters.   So, please put it into
>>       the input section too.
> OK will think about that.

An ASA that makes use of dry run isn't quite straightforward. I never
tried writing a demo of dry run, except for a trivial test that the bit
gets transmitted correctly. There's presumably implied state that a
resource is pre-booked but not actually assigned. I think we need to
make the API agnostic about the semantics of dry run.

>> listen_negotiate.
>>       I think that this call is wrong in both threaded and event-loop
>>       use.  I think that in threaded version, I really want a new
>>       thread spawned off that does the right things (negotiate_wait, etc.),
> You do need a new thread. But I don't have time right now to explain
> how that works in my example use cases. And my explanation would
> be Pythonesque.

Yes, there's no free lunch - it's the ASA writer's job to spawn a new thread
for a new transaction, in the threaded model. And in the event loop model,
the ASA needs to add a new event in the event loop for each new transaction.
We need to say this explicitly.

(It's no different than writing a server that listens for simultaneous
incoming TCP sessions; of course that's exactly what the GRASP core has
to do.)

>>       so I want to provide a function for that thread to run the negotiation.
>>       In event-loop, I think that I want the same thing, but in the
>>       function, I can't do synchronous calls, so the function has to
>>       be called each time.
> Sure. You have to insert a new event in the loop for each new negotiation.
>> negotiate_step:
>>       It says:
>>          Threaded implementation: Called in the same thread as
>>          the preceding 'request_negotiate' or 'listen_negotiate', with the
>>          same value of 'session_nonce'.
>>       but if it's in the same thread as listen_negotiate(), then I can
>>       only handle negotiation with a single peer in that thread, I think?
> Yes. Threads galore. A new thread for each new negotiation.
>>       and I don't think I'd want to call listen_negotiate() for the
>>       same objective.
> Actually that will depend on the use case, but if you do so, you need
> locks and atomicity. I put all of that into the prefix assignment demo,
> I think.

When you think about it, there's nothing special about mixing 'request_negotiate'
and 'listen_negotiate'. The problem of atomicity is identical if you run
two 'request_negotiate' sessions or one of each. Whatever shared data structure
is involved must be used by one thread at a time.

>> negotiate_wait: no idea why I'd use this.
> That simply refelects a GRASP feature: tell the other end to wait longer.
>> Summary: I do not object to this document going forward as Informational, as
>>          it represents an explanation of one implementation, and that is
>>          what Informational is about.
> All the same, I'd like to capture as much generality as possible.
>>          It would be nice to have the view of multiple implementators, but
>>          there is no energy for that.
> Yes, that's what we need.
> Regards
>      Brian
>>          While I do not object, I do not see great utility in this document.
>> nits:
>> s/neg/negotiate/
>>   I found the "NEG" term in GRASP confusing, because it seems like
>>   NEGative, rather then NEGotiate.  I'd prefer it was spelt out in
>>   the API.
>>   s/dry/dryrun/
>> --
>> Michael Richardson <>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>> _______________________________________________
>> Anima mailing list