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 <[email protected]>
> Sent: 24 November 2021 02:56
> To: Rob Wilton (rwilton) <[email protected]>; [email protected]; draft-ietf-
> [email protected]; Toerless Eckert <[email protected]>
> 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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
