Minutes for ANIMA at IETF-95
minutes-95-anima-1

There are two sessions (120 + 60 minutes) for the ANIMA WG:

Monday, 17:40-19:40, Afternoon Session III, Buen Ayre B
Thursday, 16:20-17:20, Afternoon Session II, Atlantico C
For both sessions, the chartered work items have the priority.

Minuets taker: Bing Liu


******************Anima Session I**********************
Monday, 17:40-19:40, Afternoon Session III, Buen Ayre B

1. WG Dash - by co-chairs

2. ANIMA Generic Signaling (Design team) - by Bing Liu,
   draft-ietf-anima-grasp

[Sheng]: the listed 3 APIs, are they one instance or three different
      instances?
[Bing]: three instances. The two implementations naturally sorted
      out some APIs. But they were convenience of the implementations,
      maybe not proper for future ASA design. The API in the draft
      was totally generated by imagination, not the real implementation.
[Sheng]: two of the APIs are from you? Are they different?
[Bing]: API in the draft and second one were mainly designed by Brian.
      The third one was from BUPT. At least they were from two
      independent teams.
[Sheng]: Do you have the plan to integrate them into one?
[Bing]: Yes, exactly.
[Toerless]: For ACP, I'll get back to you for the details of usage
      of GRASP.
[Sheng]: this document is relevantly mature, two volunteers for review
      to check whether it is good enough to launch WGLC afterwards?

Michael Behringer and Michael Richardson volunteered to do the review.
The chairs will also do the review.

3. ANIMA Auto Bootstrapping (Design team) - by Max Pritikin,
   draft-ietf-anima-bootstrapping-keyinfra

[Sheng]: how do you think the document maturity for publish?
[Michael R.]: not ready for WGLC, but ready for wider WG review. A
      couple of pieces are still not yet defined. One of them is
      running EST over COAP; and other pieces regarding to certificates.
      I think they need to be tested against other people's ideas.
[Sheng]: the milestone is to submit it to IESG this month. But of
      course the quality has the higher priority. Two volunteers for
      review?

Bing agreed to review it.
Will call for other reviews in the mailing list.

4. Autonomic Control Plane - by Michael Behringer,
   draft-ietf-anima-autonomic-control-plane

[Stuart Cheshire]: Your reason of not using mDNS seems like a bit of
      stretch, why Service Discovery would certainly start breaking
      this when it works with hundreds of other things seems a bit
      contrived.
[Toerless]: I was worried about this piece if you can put my words in
      this PPT, as least that would be great, definitely. I'll ask you
      how that can be avoided; I'm not quite clear on that.
[Stuart Cheshire]: Every service is advertised as a type. Printing,audio
      airport, screen mirroring are all specific types, and the
      Anima_Protocol would be a different type. So, The ideal Service
      Discovery is you find what you're looking for; you don't find any
      other devices that you're not looking for.
[Toerless]: Right, I wasn't quite clear how common it would be trying
      to display all the type of services that discovered.
[Stuart] There actually is no way to ask all types. The querying
      includes what type you're looking for.
[Toerless] Between mDNS and GRASP, I was trying to find criteria,
      and this criteria goes away, fine.
[Max Pritikin] You (Toerless) mentioned a couple of times that some
      bootstrap integration in context of discovery. You said MACSec
      doesn't support credential based authentication?
[Toerless] As far as I understood from Brian, he told me currently
      there is no standardized solution to do the mutual authentication
      based on certificates within the scope of standardized MACSec
      solution.
[Max&Toerless] Some discussion around using GRASP for negotiation
      MACSec master key.
[Sheng] Bing, would you or Brian help to review the draft to check
      the consistency with GRASP?
[Toerless] I think it's consistent. It's not complete yet, we need to
      work through do we need registration objective and what's the
      payload.


5. Reference model - by Michael Behringer,
   draft-ietf-anima-reference-model

[Sheng]: I'm not sure the Intent section is in the charter.
[Michael B.]: who think the addressing scheme we can live with?
      (Three raised hands)
[Enno Rey]: when splitting address as pieces, what's the reason for
      deviating boundary as 77 bits versus 76bits or any other bits?
[Michael B.] The next 10bits makes it clear. We defined a Zone ID. With
      this Zone ID, you have 64bit boundary. And the Zone ID allows
      future aggregation. The address scheme is flat.
[Kreeti Compella]: (regarding V bit) why do you think these virtual
      elements are related, so that you put them together in a /126 or
      whatever? They could be completely unrelated.
[Michael.B.]: I would argue, if that is unrelated, it doesn't talk to
      the elements the box ignored in the autonomic, so you wouldn't
      see it. I'm not saying each container should use the address
      scheme, but if the container does autonomic, then do it.
[Kreeti] Not sure I buy it, but will think about it.
[Enno Rey]: 12bits for Zone ID, and 4bit for type, makes it easier life
      for operation, it's easier to type 12bit or 4bit.
[Michael B.]: Ok, be my friend. I have no strong feeling, we need a
      number.
[Sheng]: Is this the addressing stuff in ACP draft? [Michael]: Yes.
[Michael B.] "Functional Overview" not a good title, looking for a
      better one.
[Kreeti]: How about "Theory of Operation"?
[Sheng]: Security advisor here? I guess you should give us the review
      the security part.
[Security Advisor] (Nancy Cam-Winget) Yes, I'll review all the drafts.
      You asked for reviewers of bootstrap document, I can pay attention
      to it.


6. Autonomic Prefix Management in Large-scale Networks - by Sheng Jiang,
   draft-ietf-anima-prefix-management

No comments.

7. An open source implementation of SNBI & ACP - by Toerless Eckert

[Sheng]: plan for GRASP included in it?
[Toerless]: I want to have the plan, but need buddy do that.



******************Anima Session II**********************
Thursday, 16:20-17:20, Afternoon Session II, Atlantico C

1. Autonomic Network Intent Concept and Format - by Jeferson C Nobre,
   draft-du-anima-an-intent

[Michael B.]: regarding to Question 8, Intent is not from ASA, but Human
      operator, this is clear consensus we're starting to converge. Just
      a general comment: we're risking in trying to pleasant everything
      with everybody and making the thing blow out of. What I would
      encourage to think about is, what is the minimal we can start
      with, doing the minimum right now and knowing where to go from
      there.
[Jeferson]: this draft, as I view, is going towards what you mentioned.
      So, you're looking for simplify, the use cases and how they can
      be addressing in the network.
[Sheng]: without chair's hat, I have a slightly different opinion with
      you. For now this work is not in charter, so we have enough time
      to gather information, what we want to do, what we need for the
      autonomic network to be able run. No matter it is named "Intent",
      or "Parameter" for ASA. My suggestion is we can describe all the
      information between autonomic node. Include them into one
      document, and then we classify it and name them.
[Michael B.]: a lot of back-force, agree-disagree, is because of the
      naming. As we can be very able to describe what we mean, I
      think it will make things a lot easier. I'd suggest try to get
      the names right asap.
[Sheng]: discuss that in the mailing list, and put whatever we get
      consensus in the draft. And don't feel pressure on timing, so
      far it's not the WG milestone.
[Jefferson]: No, no, we're continuing do it.
[Sheng]: I have no doubt the intent would be in the next charter, if
      approved.


2. Autonomic Functions Coordination - by Laurent Ciavaglia,
   draft-ciavaglia-anima-coordination

[Michael B.]: can you help us understand what a good example would be,
      and what a minimal policy engine would look like?
[Laurent]: sure. As discussed in the mailing list, that I see merging
      needs a policy engine compose of different functions. Input the
      policy, translate the policy, and check the config. As I
      mentioned, coordination block could be one of the blocks of the
      policy engine.

3. Information and Knowledge exchange in Autonomic Networks
   - by Laurent Ciavaglia, draft-ciavaglia-anima-knowledge

[Bing]: I think the concept of information exchange is valuable. That's
      one of the reasons we re-named the distribution draft from "Intent
      Distribution" to "Information Distribution". My question is, are
      you proposing a new protocol dedicated for knowledge exchange, or
      do you think the exchange could be possibly run over GRASP?
[Laurent]: So far, both options are possible. I think GRASP can fit part
      of the requirements. But my knowledge is some exchange might
      beyond the capability of GRASP. GRASP is agnostic to content, but
      we need to know the content for exchange. Maybe an upper layer
      with additional functions run above GRASP.
[Bing]: that will be great if you can sort out some specific
      requirements, and then we can check whether they could be covered
      by the distribution function.
[Laurent]: yes, we can work together.
[Jefferson]: my question is similar to the previous one, but about the
      data models. You mentioned several forms of information like
      monitoring, measurement and so on. There are several current data
      models for that, my question is if you're considering to integrate
      the current data models with the new one that you're planning to
      deploy? Or a clean slate approach to have this information
      exchange in the autonomic network?

Laurent was dropped offline. Will take the questions to the mailing list
as well.

4. Autonomic Function Lifecycle Management - by Pierre Peloso,
   draft-peloso-anima-autonomic-function

[Bing]: slide 12, in my understanding, it's not difficult to add such
      kind of more information in GRASP, because GRASP totally enable
      very flexible structure to be encapsulated either in Discovery
      of Discovery_Response messages. Slide 10, it's also not difficult
      to add such operation in messaging perspective. But the essential
      thing is not only regarding to GRASP, IMHO it is more regarding
      to reference model. There might be vital security consideration
      that it is risky to allow one ASA to control another ASA.
[Pierre]: you point is very interesting. Regarding whether it is a ASA
      design or GRASP design point of view, the main topic of the draft
      is ASA behavior and whether we have some management functions that
      considered as very specific ASAs to control this ecosystem. In my
      opinion it a design choice we need to make in our WG.
[Toerless]: to me, it looks like there needs to be some ASAs that are
      up there from the beginning, controlling the other ASAs.
[Michael B.]: same opinions to me as Toerless'. To me it's a specific
      type of ASA, sort of meta-ASA that controls other ones.
      For knowledge exchange, what you do with coordination needs a
      knowledge plane, right?
[Pierre]: it depends what you consider as knowledge plane?
[Michael B.]: your presentation and Laurent's to me sound like attack
      the same problem from different angles. If you want to registry
      the ASAs with parameters they attach, then you need to capture
      that somewhere in something could be called the knowledge plane.
      I think the two are related.
[Pierre]: this information is related, and we use it for coordination
      as well.

5. Information Distribution over GRASP - by Bing Liu,
   draft-liu-anima-grasp-distribution

No time for presenting this draft this time. Will make it a higher
priority among non-milestone work items in next meeting.

[Toerless]: for the Intent folks here, I found it extremely helpful
      to look at and understand Brian's GRASP prototype code, so if
      want to make progress, maybe also make a prototype for others
      easier understand than the PPT.
[Sheng]: we originally applied 90min for this second session, but the
      secretory only assigned us 60min. Next time we'll make sure we'll
      have longer time for interesting discussion.


See you in Berlin.