Minutes IETF106: anima

Meeting Minutes Autonomic Networking Integrated Model and Approach (anima) WG
Title Minutes IETF106: anima
State Active
Other versions plain text
Last updated 2019-12-25

Meeting Minutes

  ANIMA WG Agenda for IETF-106, Singapore

  Autonomic Networking Integrated Model and Approach

      Chairs: Toerless Eckert & Sheng Jiang

Minutes by: Artur Hecker (Session I), Michael Richardson (Session II)

   17:10-18:40 Tuesday Afternoon Session III, Sophia

   15:20-16:50  Wednesday Afternoon session II, Hullet

*****************************Session II**********************************

Tuesday (November 19th, 2019) 1.5-hour session:
   17:10-18:40 Tuesday Afternoon Session III, Sophia

1.    WG Dash - 5 min
   17:10 - 17:15, by co-chairs

   Chair (Sheng): WG documents state - several key documents still have 
   DISCUSS notes from the IESG, need to finish this to advance the WG

2.    WG Document Update (25 min)
   2a. Autonomic Control Plane - 15min
     17:15 - 17:30, by Toerless Eckert, 

   No questions

   2b. GRASP API - 10min
     17:30 ¨C 17:40, by Brian Carpenter, draft-ietf-anima-grasp-api

   No questions

3.    New Chartering Unscrambling- 10 min
   17:40 - 17:50, by co-chairs

   Ignas/ IESG: the dates are not a problem, just decide what dates you 
      want to have and it can be done

   Ignas: milestones are at the discretion of the WG

   Discussions about more documents (non expired docs, etc)
   MIchael: I suspect there will be no significant changes to the protocol 
      on the wire. No risk in adopting new things.

4.    Information Distribution in Autonomic Networking - 10 min
   17:50 - 18:00, by Artur Hecker, draft-liu-anima-grasp-distribution

   Laurent: do you mean to limit all info distribution to an event?
   Artur: no, we only use event notifications for non-instant data 
      distribution, i.e. for PubSub.
   Laurent: do you mean that it must be done the way you did with GRASP?
   Artur: well, we suggest a solution based on GRASP because it has some 
      advantages, but it would be good to review and adjust the 
   Brian: GRASP is indeed quite good at some things, we should use it 
      this way.
   Ignas (IESG): it's hard to understand why you mix informational GRASP 
      API and other things in this document (also raises a general 
      question for the GRASP API doc presented before).
   Artur: can only answer for our part - we do specify the "on the wire 
      protocol" extensions to be able to implement a required ANI 
   Sheng: probably should move the API part to an appendix or take it 
      out completely.
   Toerless: need to clarify the standard (common) and non-standard ways 
      how to do info distribution.
   Artur: yes, we actually used GRASP to have a common denominator 
      integrated in ANI per default. Other ways are possible as way, 
      they can even use GRASP to communicate.
   Artur: authors generally do not claim that this document is ready, 
      but we certainly need this document to become WG document, such 
      that we can get more community comments.

   Chair: who read the document / who agrees to adopt it as WG doc / 
      who disagrees to adopt it as WG doc?
      Around 10 hands / similar number to previous question / none
   Chair: In principle, the WG reach rough consensus to adopt this draft. 
      The chairs will confirm this through adoption call to the list.

5.    ASA environment & Anima ecosystem - 20 min
   18:00 ¨C 18:20, by Brian Carpenter, draft-carpenter-anima-asa-guidelines

   Michael: we need to ask ourselves "elevator pitch" questions like "What 
      is this ANIMA all about?"
   Michael (permissionless IPv6 network?)
   David Dai: two questions 1. can you give some examples for application 
      scenarios? 2. what's the relationship between the AI.
   Brian: 1. one example scenario is already mentioned, it's the address 
      assignment. 2. AI/ML: still a research topic, not clear how we will 
      do it. It should be there though.
   Sheng: when we rechartered, we left AI out of scope on purpose. The 
      point is that the ASA AF functionality i.e. the logic, e.g. AI logic, 
      will be independent of the protocols on the wire.
   Laurent: library of AFs / ASAs / etc. - need to address usage scenarios
   Laurent: we could see a parallel between an ASA and a network function
   Toerless: there is a difference from VNF which is a virtual 
      representation of a hardware thing (== no changes in protocols and 
      APIs) to the decomposition approach taken in ANIMA
   Ignas: happy about the discussion in general. It looks like we look 
      for a problem for an existing solution. We probably need to reach 
      out to the user community and ask them what problems they have. 
      Without having a clear problem space, we are going more into the 
      IRTF view, but this is IETF.
   Michael: the answer to Ignas' comment is a tangible demo. This should 
      be the next step. We need to get those guys "excited".
   Ignas: you have your milestones since rechartering. You need to 
      follow and achieve the milestones.
   Toerless: time is up, we need to concentrate on the draft. Call for 
      adoption will be issued to the list.

6.    Layer 2 Autonomic Control Planes - 10 min
   18:20 - 18:30, by Brian Carpenter, draft-carpenter-anima-l2acp-scenarios

   Mark Smith: potentially 5000 node subnets in future VLANs
   Remy Liu: in your mind, what's the limit?
   Brian: hard to say, but we see at many IETF meetings...
   Remy: Is the requirement for IPv6 support only Linklocal?
   Brian: yes, link local
   Remy: is IP here mandatory or optional?
   Brian: in principle we could do it directly over L2, yes, but we would 
      not have the APIs.
   Remy: but normally you mean L2/IPv6/GRASP?
   Brian: yes.
   Toerless: if we continue this work, we need to understand that ANIMA 
      already supports management of L2 networks. This should be precised; 
      it's a special case.
   Ignas: there is a WG working on topology bootstrapping (LSVR)

7.    Introduce of ETSI ZSM on closed loops - 10 min
   18:30 - 18:40, By Laurent Ciavaglia

   No questions.

*****************************Session II**********************************
Wednesday (November 20th, 2019) 1.5-hour session:
   15:20-16:50       Tuesday Afternoon session II, Hullet

1.      WG Dash - 5 min
   15:20 - 15:25, by co-chairs

   MCR says that there is little to say about constrained-voucher.

2.      WG Document Update (20 min)
   2a. Bootstrapping Remote Secure Key Infrastructures (BRSKI) - 10min
      15:25 - 15:35, by Michael Richardson, 

   2b. Constrained Voucher Artifacts for Bootstrapping Protocols - 10 min
      15:35 - 15:45, by Michael Richardson, 

   MCR update on document.
   Sheng asks that no new documents be adopted without finishing current 

5. (changed order)     ACME Integrations with BRSKI - 15 min
   16:15 - 16:30, by Owen Friel, draft-friel-acme-integrations

   Unclear where this document should live.
   TE: has this document gone to EMU, etc. yet?
   OF: TEAP requires some tweaks, and this was discussed in EMU.

   XiaLing(XL): this is about using a public CA?
   If this is a private CA, do we need the same adjustments?
   OF: what we see is that most customers with private CA run MSCA, and 
      so you need their custom APIs/SDK. THere are some on-premise CAs 
      that also support ACME, and then you could just use that interface.

   OF: this document will go to ACME on Friday?
   TE: is this document ready for adoption in whichever place makes sense?
   OF: I think we need to figure out where the document goes first, and 
      then get the right views?
   MCR suggests that this belongs in ACME due to the need to get WGLC 
      review from ACME.

3.      BRSKI Cloud Registrar - 15 mins
   15:45 - 16:00, by Owen Friel / Michael Richardson, 

   TE: what is the difference between a default Cloud Registrar, and a 
      Cloud Registrar?
   OF: the default is one that is baked into the firmware.

   XL: how do I understand what the home domain?
   OF: you plug in a device at your home, and you want the device to 
      register to your head-quarters. Is it possible to have more than 
      one home domain? That's a general BRSKI question? Like if you have 
      different Enclaves?
   MCR: Yes, that would just be two systems.

   OF: There are three options on the table, which option should we 
      support? (If we support none, then BRSKI is wrong)
   TE: They seem to be co-located with MASA?  
   OF: the cloud CA does not have to be with the MASA?

   MCR: there are three choices, and we probably only need two of them.
   OF: one issue will be whether the local operator wants to run a CA?

   Interjected: ACP DISCUSS on rfc822Name.

   Ben presents a mapping of the rfc822Name -> X509 extensions.
   MCR: this is about getting all this crap in through current CA 

4.   BRSKI-AE Updates - 15 min
   16:00 - 16:15, by Steffen Fries, draft-fries-brski-async-enroll

   started at 16:40pm. No questions.

6.      Delegated Voucher - 15 min
   16:30 - 16:45, by Michael Richardson

   No questions.
7.      Summary & ANIMA future activities - 5 min
   16:45 - 16:50, by co-chairs