Minutes IETF101: anima
minutes-101-anima-01

Autonomic Networking Integrated Model and Approach
   Chairs: Toerless Eckert & Sheng Jiang
   IETF101, London, United Kingdom
   Tuesday (March 20th, 2018) 2.5-hour session:
   9:30-12:00, Sophia, Morning session I

*******************************************************************************
1. WG Dash - by co-chairs


*******************************************************************************
2. WG Document Update (30min)

*******************************************************************************
   2a.ANReference Model - 10min
      9:35 - 9:45, by Michael Behringer, draft-ietf-anima-reference-model
   Had past WG last call, waiting for document shepherd.
   No comments.

*******************************************************************************
   2b. Autonomic Control Plane - 10min
      9:45 - 9:55, by Toerless Eckert, draft-ietf-anima-autonomic-control-plane
   No comments.

*******************************************************************************
   2c. GRASP Application Program Interface (API) - 10min
      9:55 - 10:05, by Bing Liu, draft-ietf-anima-grasp-api
[Sheng Jiang] Why "current API lacks support explicit locators for an objective
   " is an issue? It's straightforward to just expose it. And let the ASAs
   decide whether to use it.
[Bing] We're not very sure whether it is good to open such detailed thing to
   ASAs by the GRASP module.

[Sheng] Error codes between API and GRASP module and error codes inside the
   GRASP are different. If it is the latter, it should be in GRASP document.
[Bing] It's inside the GRASP, but it is mostly regarding to ASAs.
   (Errata: it is actually in the API not in GRASP messages.)

[Toerless Eckert] The main issue to me would be that the functionality
   expressed over grasp is meant to be application information, so the trouble
   is to establish cross application standards. I try to do that in the DNS-SD
   draft which is trying to say okay whatever application you are if you're
   trying to signal a service then here is a standard for that and I think
   that's the type of functional document not an API document.

*******************************************************************************
3.Guidelines for Autonomic Service Agents -15min
   10:05 - 10:20, by authors, draft-carpenter-anima-asa-guidelines

[Toerless] I think this work is highly useful, But we have to figure out the
   charter issue, because ASAs in general are not in current charter. It can
   become better and better the more experience we gain, thus as a chair I
   wouldn'tnecessarily want to have it finished as quickly as possible.

[Sheng] As far as I know, there are two documents not in today¡¯s agenda, but
   sharing some deployment experience. Maybe this document could refer them.
[Bing] I have a draft that describes utilizing GRASP in IoT scenario, as a
   management signaling protocol. We did implement very simple ASA, we can
   discuss it offline later.

[Alex Galis] 1) this draft is to better describe the border between service
   system right up vs. ASA right up; in other words, what are these and how to
   move from the described application towards service, that's the driving
   force. I don't think that this is a clear answer in you current system.
   2) NFV is coming in a big way, it's time to embrace the virtualization
   significantly because that's where our autonomicity will be applied.
   it's the time to embrace virtualization;
   3) Autonomicity had big subject, it's time to decouple it autonomocity
   in terms of specific self-x capabilities for which ASA or other parts of the
   Anima could be better applied. One framework for all, it's not going to be
   easy to put in deployment in all the aspects, including the control plane
   which was described recently. I'm afraid I'm not sure that this is
   deployable. But if that's not deployed, at least ASA applications could be
   better deployed.

*******************************************************************************
4.Information Distribution in Autonomic Networking - 20min
   10:20 - 10:40, by Bing Liu, draft-liu-anima-grasp-distribution

[Alex] I think this work is towards deployment, few issues:
   1) Information distribution is absolutely essential that a lot of mechanisms
   were already in place, are you thinking about an info model agnostic
   distribution of data or not? This is a key question.
   2) Distribution as a network service, plus other capabilities such as
   information processing, would provide Information as a Service capability, I
   can give you some references offline.
[Bing] For 1), AFAIK, the distribution mechanism should be agnostic to any kind
   of information models or data models. For 2), I agree with you that the
   distribution will be a kind of service provided to the nodes; for other
   aspects rather than simply sending and receiving messages, e.g. processing
   of the information, I think maybe that's additional application layer things,
   but I do agree we need to consider other aspects not only sending/cashing
   messages.

[Jefferson] I think it's very important work and we have a draft which is Anima
   Intent Policy and Format, there is a section on the distribution of policies.
   I think that we've got this apart from the draft and just use the way that
   you are proposing to distribute information in your draft.
[Bing] Sure, Intent distribution is actually one of the main targets of this
   mechanism.

[Toerless] Try to find examples references where people would chime in and say
   yeah so those existing protocols that's done better with this. I think that
   makes a lot of implementers a lot more interested to read this because
   otherwise it's all very abstract.

???: This work is very interesting. A clarification question: I see a lot of
   parallels between this and some of the big data projects that came out like
   five ten years ago. One of the underlying issues there was the lack of
   concern around security of the functionality of the system. So it was
   something that was added in after the fact. So is the security of the
   the pub/sub model that distributed data models something that's part of the
   initial scope of this draft, or is that something that's going to be
   addressed afterwards.
[Bing] Personally I think it should be in scope, but whether is in this
   specific document or another document, we need to consider in the future.
   But right now we still focus on the messaging mechanism itself. But agree
   with you security is something we must to consider.
[???] Yeah now's the best time the editing because if you try to put it in
   after-effects.
[Toerless] The current architecture is that the grass is expected to have a
   secure transport layer so that all the GRASP messages are you know secured
   within a single domain. So you're basically having a GRASP domain and only
   the members of the GRASP domain are privy to receive authenticate and
   decrypt the messages and that is in the current ANI framework done through
   the ACP. So if somebody takes GRASP puts in a different context he would
   basically have to show how you get the same level of security of the
   messages.
[???] One more question, I'm not a GRASP expert anyway. Is the authentication
   of the transport is that it are you piggybacking the authentication of the
   transport or are there busier abilities to layer different authentication
   models on top of just transport authentication?
[Toerless] You have a set of certificates that form the group and that's
   basically what you use for the authentication of all the air transport
   connections. I'm just building it from a bunch of TLS connection I would
   call that application layer so we're just using IPSec and that's why we're
   calling it Network layer.


*******************************************************************************
5.Constrained Voucher Profile for Bootstrapping Protocols - 15min
   10:40 - 10:55, by Michael Richardson,
   draft-richardson-anima-ace-constrained-voucher

[Toerless] It would help a lot if you describes the relationship between the
   bootstrap thing and related WGs in a document.
[Michael] I have a document that is called "constraint road map" and it takes
   things together. But it's unclear at this point where it belongs or what it
   belongs to. There are some WGs related: Anima, Netconf, 6tisch. Right now
   it's in the IoT directorate wiki because that's where people thought it
   belonged.

[Max Pritikin] On the discussion of the signing format, the current draft is
   empty on the COSE format and I'm asking the question with determination as
   to whether or not the issue is that people just don't understand that goes a
   format and haven't generated the text for that and thus don't have anything
   to read compare against whether there's actually pushback saying they don't
   want the COSE.
[Michael] I would say there's actual pushback that says essentially I don't
   want to introduce a new crypto library to my system right now. I have one
   in my DTLS stock and it can do CMS.

*******************************************************************************
6.Transferring Bulk Data over the GRASP - 10min
   10:55 - 11:05, by Bing Liu, draft-carpenter-anima-grasp-bulk

[Sheng] I see use cases of this, e.g. IoT device software/firmware update. But
   I'm not sure why you have the MTU as 2000 byte?
[Bing] It is mostly for convenience of parsing the GRASP messages because under
   layer is CBOR serialization, a fixed 2000 byte is easy to identify the end
   of the message.
[Sheng] I still don't hear it because if you exceed to see until it just get
   another package.
[Bing] The MTU issue was raised by Joel Halpern, there used to be some
   discussion in the mailing list, but I can remember the details. As I
   understood the fixed 2000 bytes are not flexible enough especially there are
   some small packages.(Errata: the real issue should be that whether 2000byte
   is big enough for some scenarios.)
[Sheng] Take it to the mailing list for discussion.

*******************************************************************************
7.ANI extensions for short-lived certificates - 10min
   11:45 - 11:55, by Max Pritikin

[Toerless] I have no overview about the right working group for this this draft
   overall, so let's figure that out and take offline your feedback on the detail
   so that we can fix the draft up. For me, that goes to the discussion this is
   the simple things just for not even BRSKI but for the EST renewal that
   basically by simply modifying the expectation against the lifetime that the
   EST renewal would still accept LDF ID after it has expired.
[Max] I I'm not sure exactly what your question is there, because you conflated
   the voucher conversation?
[Toerless]  I'm saying not even the voucher right so I think there is the big
   difference between how easy is it to have especially in a lot of constraint
   or otherwise you know more security protected environments.

[Michael]  I guess the thing that they get wrong is that they believe that
   we're we have specified short-lived certificates when we've specified
   short-lived vouchers in our document, that's their a mistake that
   you're referring to
[Max] exactly and I will work with them too
[Michael] what it sounds to me that that as you just said it will the document
   will go somewhere they'll do something sounds to me that that the right
   approach for us is in the future to write a BCP on operations of the ACP
   and that it could refer to this option of short-lived certificates rather
   than OCSP
[Toerless] maybe my point on that is that the actual Bruschi mechanism right
   given if you fail right if your certificate expires right then the fact we
   can still use the brachot the brewski proxy even though we're just doing EST
   renewal and we couldn't do that across the ACP anymore because our
   short-lived certificate expired
[Michael] I would say that again that probably belongs an operational document.

*******************************************************************************
8.Autonomic Slice Networking - 20min
   11:05 - 11:25, by Alex Galis, draft-galis-anima-autonomic-slice-networking

[Sheng] You mentioned multi-domians, personally I'm fine with that. That's
   actually my ambitious to be able to handle that. But the reality is up to
   now Anima is based on something we are working for a single domain, so I'm
   afraid there lacks some fundamental supporting to do so.
[Alex] From the positive point of view, multi-domain issues is a norm now for
   operators and for management. Why not to constraint too much to a single
   domain. Multi-domain could add a lot of other features and capabilities you
   need to be customized, that's a complexity of yet but still possible.
[Bing] Response to Sheng's comment: I think the autonomic network slicing also
   can be doable with limiting Anima technologies into one single domain. Jut
   let the orchestration level to separate the slicing requirement into
   different domains and then the Anima only handles the requirements for the
   actions within that domain.
[Sheng] That will make it easier for the current Anima to accept such things.

[Michael R.] Why you need any Augmentation to Anima? As far as I can see if
   you're using the physical layer Anima, you build a ACP in a network and
   then you put up a bunch of virtual routers top of that with virtual links
   between them. There's no reason you can't run another instance of Anima if
   the customer want to run their own autonomic Network on top of that.
   Yes there are some interfaces that you need to be able to configure physical
   and new virtual interfaces below, so the upper customer wants to have
   interfaces plugged in from place-to-place he needs a new connection but
   that's in the space of some customized ASA to me it's not on any core pieces
   of Anima.
[Alex] I think it's a time to move forward rather than that ASA feeds all type
   of our arguments. I'm not convinced.
[Sheng] I'm with Michael.
[Toerless] If I'm building a slice and that consists of virtual machines
   across a bunch of devices and I want to have this virtual network an ACP to
   manage it in the same way that we currently are doing it for the physical
   network, then the question is how to build the ACP. If I understood Michael
   correctly, he was saying this could be done through an ASA. That is true,
   but think amount of choices we have to build that type of ACP is a lot larger
   when it's a virtual context, mean the question has to be raised why wouldn't
   an SDN controller be able to do it, because you already have that and you
   already have the connectivity into all these devices.

[Robert Moskowitz] It's an interesting use case that definitely looked at.
   But to me it is just one more use case that fits well within the framework
   both of 802.AR and Anima. And it is a challenge of saying that network
   slicing services will use this model and look at the demands of scaling.

[Sheng]  I can say I like your shopping list but that's not the way how IETF WG
   work. You should come to bring a solution which give us something maybe
   implementable, then we can discuss whether those solutions are good.

[Eliot Lear] I think you're talking about our next steps, in terms of how you
   might evolve what you've started in a draft into very specific protocol
   proposals, and which one of those would have uptake in the group and which
   ones perhaps do not in terms of you can test them individually. I think
   it's perfectly reasonable comment for the chair to have made.

*******************************************************************************
9.DNS-SD compatible service discovery in GRASP - 10min
   11:25 - 11:35, by Toerless Eckert,draft-eckert-anima-grasp-dnssd

[Eliot] Slide 3 has a lengthy list of things one might want to get in terms of
   what things people might want to discover. There's a related effort that's
   going on in the DHC working group, I just wanted to bring to your attention
   which is that they're in the process of taking the DHCP options and yang
   off'eyeing them it may be that there's some way you can leverage that
   mechanism in terms of not having to response all of the the discovery formats.

[Michael R.] Eliot definitely has a very good point. I actually think some of
   this stuff could really be killer app for a lot of things and particularly in
   a bunch of ISPs and you can't use often DDHCP for this.

*******************************************************************************
10.Yang model for ANI - 10min
   11:35 - 11:45, by Toerless Eckert

[Sheng] We are autonomic, so by default those Netconf/YANG configured
   parameters has a value, it doesn't need me to configure it.
[Toerles] Definitely true. That's what I said, we only configure the minimum
   parameters, such as domain names etc.

[Bing] For GRASP configuration, maybe we need to configure some constents, such
   as MTU. If we use GRASP-Bulk, it is important to figure out a proper MTU.
   And other constents such as maximum hop count TTLs etc.

[Michael R.] I'm less interested in how do we configure with YANG an autonomic
   system that we shouldn't configure; I'm much more interested in how do we
   find out what it did and why and whether it will hit another pedestrian
   crossing the street or not.


*******************************************************************************
11.Summary & ANIMA future activities - 5 min
   11:55 - 12:00, by co-chairs