Re: [Anima] AD review of draft-ietf-anima-asa-guidelines-03

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Brian,

Holding it for the last call comments is fine.  I've just kicked off the last call request.

Regards,
Rob


-----Original Message-----
From: Brian E Carpenter <[e-mail]> 
Sent: 29 November 2021 20:04
To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]; [e-mail]; Toerless Eckert <[e-mail]>
Subject: Re: AD review of draft-ietf-anima-asa-guidelines-03

Rob,

OK, thanks, I will put your suggested change in the working copy.
Shall we post an update, or just hold it until we see the Last
Call comments too?

Regards
    Brian

On 30-Nov-21 03:27, Rob Wilton (rwilton) wrote:
> Hi Brian,
> 
> Thanks for the reply and updated doc.
> 
> I've put a couple of comments/answers inline but the only actionable comments that I have relates to the NETCONF management client description, which I have brought to the top:
> 
>>> 6. I presume that the ASA would be treated like any other NETCONF
>> management client?  Perhaps this is worth stating, and that it may need to
>> coordinate configuration updates with other management clients.
>>
>>
>> Oh, it's so confusing to me that the NETCONF server (in the protocol sense) is
>> in the managed device, which in the big picture is not really a server at all.
>> Here's my attempt:
>>
>>         For example, if such management is performed by NETCONF
>>         <xref target="RFC6241"/>,
>>         the ASA must interact directly with the NETCONF server in the same
>> node,
>>         to avoid any inconsistency between configuration changes delivered
>>         via NETCONF and configuration changes made by the ASA.
> 
> The key bit is that ASA should logically be like any other NETCONF management client, .e.g., if you did "show config history" then I would expect to see the config update by the ASA, just like any other config update, so I suggest tweaking the text to something like:
> 
>         For example, if such management is performed by NETCONF
>         <xref target="RFC6241"/>, the ASA must interact with the NETCONF
>         server as an independent NETCONF client in the same node to avoid
>         any inconsistency between configuration changes delivered
>         via NETCONF and configuration changes made by the ASA.
> 
> Further comments inline ... but none are actionable.
> 
> 
>> -----Original Message-----
>> From: Brian E Carpenter <[e-mail]>
>> Sent: 24 November 2021 02:56
>> To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]; draft-ietf-
>> [e-mail]; Toerless Eckert <[e-mail]>
>> Subject: Re: AD review of draft-ietf-anima-asa-guidelines-03
>>
>> Hi Rob, thanks for such a careful review. The -04 version posted a few
>> seconds ago should respond to your points, but we have inserted comments
>> below.
>>
>> On 19-Nov-21 07:27, Rob Wilton (rwilton) wrote:
>>> Hi Authors, ANIMA, Toerless,
>>>
>>> My AD review of draft-ietf-anima-asa-guidelines-03 is inline.  I have also
>> attached a copy of my review because the IETF mailer likes to truncate my
>> review emails, so please check that you reached my signature for the full
>> review.
>>>
>>> Toerless, please can you also update the Shepherd writeup to indicate that
>> I'm the responsible AD for this document.
>>>
>>> The draft is well written, and mostly I have fairly minor comments to
>> improve the readability of the document in a few places.  I also ran the
>> document through an automatic grammar checker, and the nits raised are at
>> the end of my review.
>>>
>>>
>>>
>>> 1. Would it be useful to have a terminology section for some of the
>> acronyms, to make
>>> it easier for readers to refer back to?  This could also help indicate where
>> the terms are defined?  I'm happy to leave this entirely to the authors
>> discretion.
>>
>>
>> Yes, this seems useful (and should have been in RFC8993). Will add as an
>> Appendix.
> 
> Looks good.  Thanks.
> 
> 
>>
>>> 1.  Introduction
>>>
>>>      Another example is that an existing script for locally monitoring or
>>>      configuring functions or services on a router could be upgraded as an
>>>      ASA that could communicate with peer scripts on neighboring or remote
>>>      routers.  A high-level API will allow such upgraded scripts to take
>>>      full advantage of the secure ACP and the discovery, negotiation and
>>>      synchronization features of GRASP.  Familiar tasks such as
>>>      configuring an Interior Gateway Protocol (IGP) on neighboring routers
>>>      or even exchanging IGP security keys could be performed securely in
>>>      this way.  This document mainly addresses issues affecting quite
>>>      complex ASAs, but the most useful ones may in fact be rather simple
>>>      developments from existing scripts.
>>>
>>> 2. In this example, is the assumption that the scripts are running on the
>> devices?  It wasn't entirely clear to me.  If so, perhaps reword the first part of
>> the paragraph to make this more clear?
>>
>>
>> Yes, done.
>>
>>> 2.  Logical Structure of an Autonomic Service Agent
>>>
>>>      As mentioned above, all but the simplest ASAs will need to suport
>>>      asynchronous operations.  Not all programming environments explicitly
>>>      support multi-threading.  In that case, an 'event loop' style of
>>>      implementation could be adopted, in which case each thread would be
>>>      implemented as an event handler called in turn by the main loop.  For
>>>      this, the GRASP API (Section 3.3) must provide non-blocking calls and
>>>      possibly support callbacks.  When necessary, the GRASP session
>>>      identifier will be used to distinguish simultaneous operations.
>>>
>>>
>>> 3. Various languages have better concurrency paradigms than threads and
>> locks (e.g., actors, futures, goroutines, etc).  So, I think that you are using
>> threads here as a way to describe what operations are expected to be
>> handled in an asynchronous fashion, and to describe that using a fairly
>> simple frame of reference.  You cover the single threaded case, but I didn't
>> know whether it would be helpful to indicate that other concurrency
>> mechanisms can be used, or perhaps that would just be obvious to folks who
>> are familiar with them anyway ...
>>
>>
>> Well, I'd say "different concurrency paradigms" to avoid a value judgment,
>> but yes. We did cover this at more length in the API (RFC8992) so probably
>> we should point to that discussion. To avoid confusing text, I will move most
>> of the text about asynchronous operations into the section about the API.
>>
>> (( From a quick glance at goroutines, I can only see a syntactic sugar
>> difference between _tcp_listen(listen_sock).start() in Python and go
>> _tcp_listen(listen_sock) in Go, for example. All these things are event loops
>> under the skin, anyway. ))
> 
> The updated text looks good.
> 
> By better concurrency paradigms, I mean ones where it generally easier to write correct performant concurrent code than using threads & locks (which are hard to get good concurrency if global state is shared, but conversely very easy to get data races or deadlocks).  But this is probably a discussion over a glass of wine or beer if we manage to meet in person again ... ;-)
> 
> I think that the key difference between Go and Python is that the goroutines will run concurrently (assuming a multi-core processor), whereas in Python the global interpreter lock prevents concurrent execution - which is not as efficient on modern multi-core CPUs.
> 
> =
>>>
>>>
>>> 5.  Design of GRASP Objectives
>>>
>>>      The general rules for the format of GRASP Objective options, their
>>>      names, and IANA registration are given in [RFC8990].  Additionally
>>>      that document discusses various general considerations for the design
>>>      of objectives, which are not repeated here.  However, note that the
>>>      GRASP protocol, like HTTP, does not provide transactional integrity.
>>>      In particular, steps in a GRASP negotiation are not idempotent.  The
>>>      design of a GRASP objective and the logic flow of the ASA should take
>>>      this into account.  For example, if an ASA is allocating part of a
>>>      shared resource to other ASAs, it needs to ensure that the same part
>>>      of the resource is not allocated twice.  The easiest way is to run
>>>      only one negotiation at a time.  If an ASA is capable of overlapping
>>>      several negotiations, it must avoid interference between these
>>>      negotiations.
>>>
>>> 7. Is the alternative approach valid here, which is to design the GRASP
>> Objectives such that they can be treated idempotently?  I.e., where the
>> receiver can detect that it is a duplicate request and ignore it.  Generally, I
>> find that to be a simple and robust way to do concurrent system design.
>>
>>
>> True, will add. For example, Toerless has a model that amounts to DNS-SD
>> lookup over GRASP. That is idempotent. But a shared resource objective can't
>> be idempotent, I don't think, because if A gives some resource to B, that
>> needs to be an atomic transaction.
> 
> I agree for the case where an ASA is the owner of the block of resource and it is reallocating part of that resource to another ASA.
> 
> But I still suspect that this could potentially be modelled in a different way that would mean that the messages themselves are idempotent.  E.g., if ASA persistently track what resources have been allocated to each other ASA.
> 
> Thanks,
> Rob
>