Skip to main content

Minutes for ANIMA at IETF-96
minutes-96-anima-5

Meeting Minutes Autonomic Networking Integrated Model and Approach (anima) WG
Date and time 2016-07-18 16:00
Title Minutes for ANIMA at IETF-96
State Active
Other versions plain text
Last updated 2016-08-15

minutes-96-anima-5
Anima Session I, Monday July 18th, 2 hour session

18:00-20:00      Afternoon Session III, Potsdam II

1.       WG Dash - 5 min / Chair slides
by co-chairs
  Sheng reporting on draft status:
  Need to get more feedback / discussion about bootstrap review onto main
  anima mailing list to move it to last call.
  Autonomic Control plane: Milestone planned for september, also need more
  review feedback for it.
  Use case drafts - plan not to send them to IESG until we have the other
  documents stable and ready to send to IETF.
  Also please provide more feedback for reference model.

2.       ANIMA Generic Signaling (Design team) - 30 min
by Brian Carpenter, draft-ietf-anima-grasp
  [Sheng]: Whether GRASP main document could be standalone without API draft?
  [Brian]: Yes, the main document only states there needs to be API,
   but doesn't discuss the API in anyway.They are seperate documents.

  [Toerless]: GRASP can live outside the kernel, we only need privileged
   user land for flooding and multicast.
  [Brian]: Yes, I think it's the shared multicast socket that needs kernel
   privileged..

  [Toerless]: We haven't standardize how to discover registar, that might
   be the biggest gap in current ACP text -> GRASP.

  [Eliot Lear]: If you don't put the "unused protocols analysis" in the
  appendix, then you can make a summary, not full analysis, but shorter.
  [Brian]: I don't have a strong feeling on that. It needs a critical 
  review. No reviews have covered that part.
  
  [Toerless]: Can you explain the most simply example where the "Rapid Mode"
  is highy beneficial?
  [Brian]: It simply reduces two packets in Sync procedure.
  [Toerless]: So basically it might be better in IoT environment with
  counting bits.
  [Michael Behringer]: I was about to say do we really need that efficiency?
   (Rapid Mode). But Toerless made a good point in IoT case.
  [Laurent C.]: 1. Comment on IoT thing: maybe an ASA in the gateway talking
  for the devices, then no issues anymore for devices.
  2. Is there any negotiation of GRASP capabilities? If one doesn't support 
  Rapid Mode, then fail back to normal mode.
  [Brian]: Rapid Mode is like an attachment in GRASP message, if one doesn't
  reply with Rapid Mode manner, it implies it doesn't support it.

  [Terry Manderson]: (Speaking as AD, regarding to some "MAY" keyword usage
  in current draft) You do have the Appendix very easily used for informational
  pieces. But I think you need a lit bit more information about that.
  [Terry Manderson]: If you send the document with MAY, please also include 
  Guidance.

  Point 49: signaling across two domains:
  [Michael B.]: (For cross-domain communication issue) It is not that complicated.
  If you have two domains working together, then you need a common trust anchor.
  It needs a common CA for cross-signing, but it needs a standized connection 
  such as TLS for that.
  [Max Pritikin]: I don't think that's quite enough to authorize other domain for
  certain things. I'd more comfortable to say these things are undefined rather
  than already defined partially.
  [Sheng]: It will be fine to say that is an identified future work.

  [Sheng]: When do you think you close all the open issues?
  [Brian]: Most them I think can be closed very quickly after discussion with 
  Toerless/Max. The first one (people validate GRASP design and use cases) is 
  the hardest one. 
  [Sheng]: This document is already late as a milestone. WGLC is one of
  the most efficient way to get reviews. I'd like to close the open issues and
  send it to WGLC.
  [Brian]: The first open issue is not under control. The other ones, we can close
  in a few weeks.

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

  [Sheng]: (without chair hat on) GRASP for discovery should be "MUST". 
  The WG's ambition is to have one uniform signaling protocol.
  [Max]: low end device running GRASP stack might not work...
  [Sheng]: We assume later there will be more ASAs on devices to use the single one protocol
  [Max]: Maybe GRASP for secure mode; this one (mDNS) for unsecure mode.
  [Toerless]: mDNS on proxies to bootstrap non-Anima devices; if the client is an Anima
   device, then "MUST" use GRASP to find proxy.
  
  [Michael Richardson]: since we use discovery, then no need for port reservation for proxy 
  or registrar.
  [Toerless]: Yes, Every discovery protocol needs to be able to discover the port and address.
  
  Michael R. and Toerless made some discussion of moving some operational cost from proxy
  to registrar.
  
  Eliot Lear stated that he expected the document Max referenced would be adopted soon.
  
  [??From Ericsson]: Have you considered "COSY?" ? CBOR encryption.
  [Max]: Sorry, I don't know that.

  [Dan Harkins]: How did the new entity get the MASA server's certifacate?
  [Max]: The new entity has it from manufacture.
  [Dan]: So it's the CA cert for manufacturer? [Max]: Yes.

  Some detailed discussion regarding to domain hash, between Michael R., Eliot Lear, and Max.

  [Toerless]: Right now in the charter, I don't think we've defined two enrollment devices 
  using GRASP outside the ACP. Maybe in re-chartering.

  [Laurent]: Regarding to charter, I'm not sure it is explicitly specified GRASP in ACP.
  I agree it might be an outcome of the WG's work, but disagree it is in the charter.
  [Toerless]: Maybe I was overstating it is in charter. But it is in framwork how these
  things interact.

  [Michael R.]: I'd suggest: if there are addtional attributes required in the pledge
  certificate, that become known autonomically, that the new member will request a
  new certificate with the corret new attributes. We should write that into the
  bootstrap document.
  [Max]: I like that.

  [Sheng]: I'm asking you to get more reviewers, and make their comments in the mail
  list pulicly.

4.       AN Reference model - 35 min
by Michael Behringer, draft-ietf-anima-reference-model

  [Michael R.] The naming is exactly the attributes we talked several minuets ago.

  [Sheng]: The word "Intent" has been over-used a lot. Different people have different
  meaning of Intent. In Anima, it's good to have specific instance of Intent, not a
  generic Intent.  Or, maybe Anima Intent is a subset of a generic Intent.
  [Michael B.]: I hope that SUPA defines a framework for Intent, and we grab a subset of it.
  [Laurent C.] 1.To my knowledge, SUPA is not chartered to do any Intent or Declaritive
  Policy. 
  2. In both of the two Intent drafts, we try to make it specific, maybe another terminology
  such as Goal.
  3. Where we start from considering Intent in Anima. E.g., Intent is from operator, or
  from user?
  [Michael B.]: I think it's the operator. Because Intent defines a control way how network
  administrators operate.
  [John Strassner]: I agree with pretty much everything that Michael said, Laurent said. 
  Except one tiny thing. SUPA is not chartering to do Declaritive Policy, but SUPA model has
  the abstraction of the facility.

  [Laurent C.]: The shared adjacency table has any isolation?
  [Michael B.]: How ASAs access adjacency table is a good question.
  [Laurent C.]: Let's take it off line.
  [Brian]: I don't think the ASAs need direct access to the adjacency, except for the 
  infrastructure supported ASAs which arebe special. 
  
  [Sheng]: You must find a way of avoiding un-converged Intent for IESG.
  I'll do the Reference Model review.
  
Anima Session II

1. ACP update, by Michael Behringer

  [Michael R.]: We'll run a seperate instance of GRASP in insecure mode on proxy and nodes try ACP.

  Some detailed discussion regarding to COAP between Toerless, Sheng, and Max.
  [Sheng]: co-author make a solution, send it to the mailing list, don't wait for the 
  next meeting.

2. Intent Distribution, by Bing Liu

  [Michael B.]: we sort of decided against selective distribution
  [Sheng]: it's not a WG item yet, not in this charter.
  [Laurent C.]: for Intent Distribution, currently no need for selective flooding;
  for information distribution, it is a wider scope, depends on the use cases.
  [Bing] For Intent distribution, I basically agree we might not need selective
  distribution. For information distribution, I believe selective feature is a useful tool.
  
  [Michael B.]: You might want to identify who issued the content, and naildown a specific
  node.
  
  [Max]: if we allow abitrary injection, then content source authorization would be
  very difficult.
  
  [Michael B.]: for conflict handling, just keep the latest Intent.
  [Bing]: conflict handling most depends on Intent definition. 
  
  [Laurent]: for information distribution, we need more analysis such as requirement
  analysis.

3. Coordination Functions, by Laurent C.

  [Michael R.]: a concrete example of risk failure monitor?
  [Laurent]: you can monitor in the router, the CPU, memory etc.
  
  [Sheng]: are you going to standardize that graph?
  [Laurent]: it is only one example using grahp theory.
  [Sheng]: the manifest seems like we need a full list of possible actions and
  parameters etc.
  [Toerless]: the manifest doesn't seem imply loops exist.
  [Laurent]: no, the manifest is just an ASA write down in a file. Conflict is a dedicated
  function that gather different manifests, parse them, and detect conflict.
  
  [Sheng]: still not convinced this is doable.
  [Laurent]: it's not the end of the story. Some prove points: we made the solution several
  years ago, with 6 ASAs PoC.
  
  [Bing]: for coordination, are there other functions than just conflict handling?
  [Laurent]: it depends on what we want to do.
  
  [Sheng]: you should document the requirements of this function
  [Laurent]: that's the next presentatino.

4. ASA Lifecycle, by Laurent C.

  [Michael B.]: what is the stage of the port number used?
  [Laurent]: two stages, in the install stage and configuration stage.


5. GRASP API, by Brian Carpenter

  No comments due to very limited timeslot.