Minutes IETF100: anima
minutes-100-anima-00

ANIMA IETF-100, Singapore
Chairs: Toerless Eckert & Sheng Jiang
Note taker: Bing Liu

Monday (Nov 14th, 2017) 2.5-hour session:
9:30-12:00, Sophia, Morning session I


********************************************************************************

1. WG Dash - by co-chairs

Sheng give a brief update for all WG documents. All WG milestones are in the
matureor almost mature situation. 4 WG document are with IESG already.

********************************************************************************

2. WG Document Update

2a. ANIMA Auto Bootstrapping, by Michael Richardson,
   draft-ietf-anima-bootstrapping-keyinfra, remote
[Sheng]: Toerless, may I ask you as the document shepherd, do you think it¡¯s
   ready for WGLC?
[Toerless]: I think I need a second round review, and come to that conclusion.
[Michael Richardson]: I think it¡¯s ready for WGLC. It would be good to have
   another review by you or others have never read it before.
[Toerless]: at first round review, good experience of driving changes through
   Github, instead of only sending to the mailing list which obviously is an
   IETF requirement.
[Brian]: relaying Jabber: Bella(?) said he is in the process of reviewing
   BRSKI. I think it¡¯s his first time.

********************************************************************************

2b. Autonomic Control Plane, by Toerless Eckert,
   draft-ietf-anima-autonomic-control-plane
[Sheng]: giving the WGLC comments received, do you think there will be
   significant change, that a second call is needed?
[Toerless]: No. One or two small points from Bill Wood, would be very small
   changes.
[Brian]: 1. Just for the information, both the draft and previous one defines
   some grasp objectives, so I have written demo code for both for all three
   objectives concerned and prove that they do in fact work and produce valid
   results and if you want sample messages in binary I can generate them for
   you. Either as the authorship teams if you want to include such examples;
   2. For the AD, both of the drafts and the prefix management draft which we
   didn¡¯t need to discuss all three and IANA considerations define grasp
   objectives and IANA has pointed out already that they need an expert reviewer
   because otherwise they¡¯re not ever going to let those drafts can progress.
   So we do need an IANA expert appointed otherwise all three drafts will sit
   there forever.
[Toerless]: Keep the GRASP Objectives in these main RFCs as simple as possible
   and then make the flexibility through extensions so maybe that helps to
   quicker close on any questions related to those objectives.

********************************************************************************

2c. AN Reference Model - by Jeferson Nobre, draft-ietf-anima-reference-model
[Sheng]: as the shepherd, I¡¯ll do the review in a month.

********************************************************************************

3. * GRASP Application Programming Interface - by Brian Carpenter,
   draft-liu-anima-grasp-api
[Brian]: should the WG adopt this work as sort of extension of the current
   chartered items?
[Toerless]: I think we definitely should adopt this. But I¡¯m not sure if we¡¯re
   with the current text close to the final stuff. We should have first defined
   the API as that the service GRASP provides and think about the protocol.
   Security review might impact the API would be to expose.
[Sheng]: For me, this is very important work. It actually increases the
   reusability of GRASP and that will makes the ASA much easier. Terry, is that
   right to define such API? Because it is within devices.
[Terry]: Good question, I don¡¯t have an answer straight away. Traditionally
   we¡¯d like to think about things on the wire; but in the situation like this,
   if the interoperability within the two functions is not appropriate, this is
   going to impact implementation. So, right now I don¡¯t know.
[Brian]: Just interpret that we have done APIs in the past as informational
   documents not as standard track documents. Terry: yes.
[Diego Lopez]: I would like to say yes as well. When you look at this in the
   context of network softwarization and the idea that we are going to run many
   different pieces like as software elements running in homogeneous
   infrastructures, precisely this kind of API set is going to become more and
   more part of the network interface. It¡¯s not only what goes on the wire on
   the air or the other fibers.

Sheng asked the WG opinion of whether adopt this document. Some people hum for
   support, none against.

[Brian]: We really love to have at least one another co-author who is an active
   C programmer that would help a lot.
[Terry]: I don¡¯t think there is any judge of consensus there. Please take that
   to the mailing list, and I¡¯ll be watching carefully. It¡¯s a WG, you need
   people to be engaged and to work on these things.

********************************************************************************

4. * Information Distribution over GRASP - by Bing Liu,
   draft-liu-anima-grasp-distribution
[Sheng]: You presented the use cases in Seoul, what feedback you received
   afterwards out of line.
[Bing]: we haven¡¯t received any essential feedback, but during the discussion
   I think in the room people had consensus that selective flooding is something
   useful. We can raise some more discussion in the mailing list.
[Sheng]: That made me concerned, we need people to confirm that¡¯s a real use
   case.
[Toerless]: I think we need to do it. I¡¯m just not sure how and how much of
   that would be in charter. I think the draft is a good start with requirements,
   it¡¯s not really conclusive as a proposed solution.
[Artur Hecker]: I find it extremely useful in the sense that we have in the
   Reference Model the information distribution so somehow we need to do it.
   However, I do not care where it¡¯s done, whether it¡¯s GRASP doing it or we
   do it on the top. I don¡¯t have any preference, let¡¯s find a place for it.
   It¡¯s in the Reference Model already so I do not see how it cannot be done.
[Sheng]: For me the information distribution work is definitely needed; but for
   how we process it, I¡¯m thinking current format of this document is very
   primary, mostly focus on requirements, and you haven¡¯t really covered the
   Pub-Sub and Bulk Transport. Maybe the best way would be first make a
   requirements document, since you¡¯re talking about multiple solutions so it
   might make sense to do integrated requirements first as informational
   document and then have each of the functions separately later.

********************************************************************************

5. * Guidelines for Autonomic Service Agents- by Laurent Ciavaglia,
   draft-carpenter-anima-asa-guidelines
[Bing]: I think this a useful document and I have two specific comments. 1. You
   mentioned in general the ASA should support multi-thread, but in some very
   constrained devices such as IoT nodes, maybe you can also have some
   description of very tiny ASA, which just has one thread and one very specific
   objective, so in that case the ASA could be very simple and don¡¯t need any
   multi-threading. 2. In the NFV scenarios, there is a concept of Microservice
   which in my opinion is very similar to the ASA concept in Anima; so maybe
   there needs to be some explanation between the similar concepts. In my point
   of view, I think they are essentially the same.
[Laurent]: 1. This document focuses on what ASA developers should care about, so
   if it is really constrained, they will concentrate on having efficient light
   code etc., they can rely on maybe a single thread or event oriented approach,
   but it should be aware that behind that GRASP maybe have a synchronously so
   that you should not lock the process of GRASP because you cannot only in a
   serial manner. 2. If we expect Autonomic Functions to be just software pieces,
   yes there are some other context like NFV microservices, any kind of embedded
   code we should get best current practices and see what the specificities of
   autonomic networks we need to describe in those drafts for instance like
   coordination the life cycle may be specific, the fact that they are running
   in closed loops may be different from other environments. This is what we need
   to capture and not to re-invent the wheel, if there is already good practice
   in software domain, then it is not the goal of this document to do that again.
[Toerless:] 1. Out of current charter; 2. This is interesting and should be done,
   but need to figure out how and when we do it; 3. What ietf would like to do,
   some distinction between things that are done on interface is called API vs.
   interfaces that are called YANG¡­ this may be easier to be adopted in IETF if
   it¡¯s seen as e.g. starting on dependencies between different data models that
   are representing what a particular mode a ASA is doing; as opposed to starting
   it from the typical software development perspective, thinking more about the
   data modeling aspect.
[Brian]: 1. Binging up the NFV point is a good one, we do need to think about
   that, because if we propagate one religion and if he propagates a different
   religion then you know whoever I don¡¯t know end up in trouble, so I think we
   really should take that point rather seriously. 2. Really simply ASAs might
   not need API, so this draft focus more on high-end ASAs.
[Diego]: micro service, involving it here might be dangerous
[Sheng]: I¡¯d like to take a wider discussion than the document; very specific
   ASAs out of the scope, generic ASAs should be done in this WG.
[Alex Galis]: Comment about how to extend this work before too late. Assuming
   there¡¯ll be many ASAs sooner or later, the problem of coordination of all
   of them is going to be fundamental; it¡¯s not something which will be easy
   to add after, therefore the coordination and orchestration of these ASAs in
   some sense have to be added to the problem from beginning, like a northern
   ecosystem for these ASAs. Second, in order to be practical, we need
   recursiveness, in other words, to build some ASAs from other components.
[Laurent]: there is a draft about coordination in Anima, we welcome everyone
   to contribute on this.

********************************************************************************

6. * Bulk data over GRASP - by Brian Carpenter, draft-carpenter-anima-grasp-bulk
[Sheng]: Personally I like the motivation very much, because at the very
   beginning of Anima, we said if that¡¯s possible we¡¯d like to have GRASP as
   ¡°the¡± single signaling protocol. E.g. in IoT, we use modified GRASP for
   network management.
[Toerless]: I have a couple of ASAs between two nodes, bringing up them with bulk
   transfer, I¡¯m confused about the multiplexing of GRASP, would there be any
   risk of head of line blocking? [Brian]: I don¡¯t think so, it¡¯s a synchronous,
   I¡¯m a Python programmer I use threads; the transactions are completely
   separate and independent sessions run in parallel.
[Toerless]: So those would be on separate five-tuples? [Brian]: yeah.
[Toerless]: Whether or not ASAs would like to use some existing file transfer
   standard or come up with a new one like this, I¡¯m not sure of how to make a
   choice between that. Your justification is just that some applications may
    want to use it; I think it would be good to have more brainstorming on the
   justifications.
[Brian]: Sure, it comes back to what Sheng said, there is simplification of
   your software environment.
[Bing]: Echo to Toerless, GRASP bulk not only for simplification, but also can
   reduce some extra configuration, because if we use others (FTP/TFTP etc.),
   it implies extra configuration.
[Sheng]: A clarification question, are you proposing a generic function without
   extending any requirement to GRASP?
[Brian]: this only very preliminary test I did.
[Sheng]: if no extension to GRASP, then it is a validation use case as an
   informational draft.
[Jefferson]: security considerations? [Brian]: my assumption is it is running
   in ACP, where there is no man-in-the-middle no spies.
[Jefferson]: do you think it will be good to have another layer of security.
[Brian]: if this is insecure, then no other ASAs secure either.
[Toerless]: 1. If we make it as informational, it sounds like some
   recommendation for how to use GRASP to do something, I think that¡¯s still
   within current charter; 2. Is the segment limitation in GRASP as we defined
   it, is still viable beneficial or should we rather updating it. A
   competition is including an http header into GRASP objective.
[Terry]: AD hat on. Does it inhibit or is it a blocking aspect by not having
   this to the deployment of autonomic networking; does this fill our absolute
   requirement somewhere. [Brian] We have this set of problems that Bing
   talked about for distribution. So we need something. I¡¯m not saying we need
   this, I¡¯m just saying we could do this. [Terry]: there is obviously an open
   question there about ¡°COULD¡± vs. ¡°SHOULD¡±. The benefit of this really is
   you¡¯re using GRASP to bypass adding extra layers extra machinery.
[Bing]: Echo to our AD. In my mind there are at least two use cases. 1) at the
   initial stage, one device joining the domain, it will download image, if
   GRASP provides the capability, then no other configuration. 2) the ASA
   itself could also be delivered. [Terry]: that has a nice play in IoT scenario.
[Diego]: We started talking about the ¡°COULD¡± and ¡°SHOULD¡±, my only concern
   is that it doesn¡¯t become a ¡°MUST¡±, as long as you can use GRASP to send
   references using other protocols, I think there is value of this, definitely.

********************************************************************************

7. * Towards PubSub and Storage integration in ANIMA - 15 min
11:25 - 11:40, by Artur Hecker/Xun
[Toerless]: Any specific differences between Event Service vs. Pub-Sub?
[Xun]: Event Service is to enable the Pub-Sub; Pub-sub should have a kind of
   Event Service so that it can do a synchronous communication. This is not a
   replacement of Pub-sub, actually it is for Pub-Sub.
[Toerless]: you¡¯re concentrating on Event Service because you¡¯re trying to
   provide an infrastructure where you could also do other things than Pub-Sub
   on top of it?
[Xun]: yes, but primarily for Pub-Sub.
[Artur]: Usually when you have Pub-Sub, you need some kind of decoupling between
   the sender and the receiver, so you need some intermediate party to
   essentially store messages of backing them or whatever, and that¡¯s
   essentially our way of saying ok we can call it Event Service we can call it
   Pub-Sub service, I don¡¯t care, it¡¯s just the name. But in implementation
   component to enable Pub-Sub.
[Toerless]: I think about both of Bing¡¯s distribution and your draft, if I try
   to cut the cake into two pieces: the one piece to me seems that we have
   things that is meant to be a long-lived data distributed in the network,
   mostly about flood; the other is much bigger and much cooler, you¡¯re starting
   to have a lot of interesting ASA datasets that not everybody in the network
   needs, in my prior life I would have called multicast distribution trees,
   that would be cool, but we need to find a lot more in our support for doing
   this.
[Xun] Here what we see is for the Event Service is kind of glued for other
   components you mentioned e.g. distributed databases and some kind of
   asynchronous communication requirements. This Event Service glue them together.
[Bing]: If I understand correctly, there are actually two modules, one is for
   Pub-Sub, the other is for distributed storage. [Xun]: the Event Service
   module will handle that two parts.
[Bing] So are the two parts totally separated, or they need to be bind together?
[Xun]: It depends. If the Event Service has the full control of the storage
   of the network, then they¡¯re together; if the Event Service only has some
   kind of access rights, then they¡¯re de-coupled. [Bing] Personally I¡¯d
   suggest if follow the way to make some extension to ANI, maybe it¡¯s better
   to make them as two modules. They¡¯re open to the upper layer, it depends on
   ASAs. I think this is very valuable, as I mentioned in the Information
   Distribution presentation. Whether merge two draft, or remain them separately,
   let¡¯s discuss it later.
[Xun] Personally we don¡¯t have any preference. Merging to your Information
   Distribution draft may be even better.
[Sheng]: Pub-Sub and Distributed Storage, they¡¯re quite useful ability for
   autonomic networking; but for the concept of ¡°Event Service¡±, I¡¯m not
   sure, it looks for me you¡¯re trying to do a connection of all various
   actions regarding to events. For me, that¡¯s risky to say sometimes we
   may have a complete list of every possible actions there. I¡¯d suggest
   to do the fundamental ability like Pub-sub and storage, rather than to do
   a layer like Event Service.
[Artur]: Co-author of the draft, I agree with Toerless that in a general
   sense it might beyond the charter. But we can limit ourselves to Information
   Distribution in the sense that it¡¯s communication service, we use GRASP as
   a concrete example, it is chartered. But Information Distribution in not
   only in space but also in time, that why the storage somehow becomes
   necessary. There is information must be postponed. How we integrate it in
   which point and for which exact job, I do not know and I don¡¯t think it¡¯s
   very important.
[Xun]: In principle our motivation is that ANI can support asynchronous
   communication in a native way.

********************************************************************************

8. * DNS-SD over GRASP - 15 min
11:40 - 11:55, by Toerless Eckert
No discussion.

********************************************************************************

9. Summary& ANIMA future activities - 5 min
Intermediate meeting might be held.
Meeting adjourned. See you in London.
Note: * mean the non-chartered work items.