* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Anima Status Pages

Autonomic Networking Integrated Model and Approach (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 2014-Nov-03 —  

IETF-101 anima minutes

Session 2018-03-20 0930-1200: Buckingham - Audio stream - anima chatroom


minutes-101-anima-01 minutes

          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,
             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
             " is an issue? It's straightforward to just expose it. And let the
             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
             GRASP are different. If it is the latter, it should be in GRASP
          [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
             is to establish cross application standards. I try to do that in the
             draft which is trying to say okay whatever application you are if
             trying to signal a service then here is a standard for that and I
             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
             become better and better the more experience we gain, thus as a chair
             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,
             sharing some deployment experience. Maybe this document could refer
          [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
             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
             force. I don't think that this is a clear answer in you current
             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
             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
             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
             distribution will be a kind of service provided to the nodes; for
             aspects rather than simply sending and receiving messages,
             e.g. processing
             of the information, I think maybe that's additional application layer
             but I do agree we need to consider other aspects not only
          [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
             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
          [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
             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
             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
             But right now we still focus on the messaging mechanism itself. But
             with you security is something we must to consider.
          [???] Yeah now's the best time the editing because if you try to put it
          [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
             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
             the ACP. So if somebody takes GRASP puts in a different context he
             basically have to show how you get the same level of security of the
          [???] One more question, I'm not a GRASP expert anyway. Is the
             of the transport is that it are you piggybacking the authentication
             of the
             transport or are there busier abilities to layer different
             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
             connections. I'm just building it from a bunch of TLS connection I
             call that application layer so we're just using IPSec and that's why
             calling it Network layer.
          5.Constrained Voucher Profile for Bootstrapping Protocols - 15min
             10:40 - 10:55, by Michael Richardson,
          [Toerless] It would help a lot if you describes the relationship between
             bootstrap thing and related WGs in a document.
          [Michael] I have a document that is called "constraint road map" and it
             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
             it's in the IoT directorate wiki because that's where people thought
          [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
             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
             to read compare against whether there's actually pushback saying they
             want the COSE.
          [Michael] I would say there's actual pushback that says essentially I
             want to introduce a new crypto library to my system right now. I have
             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
             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
             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
             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
             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
             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
             or otherwise you know more security protected environments.
          [Michael]  I guess the thing that they get wrong is that they believe
             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
             will go somewhere they'll do something sounds to me that that the
             approach for us is in the future to write a BCP on operations of the
             and that it could refer to this option of short-lived certificates
             than OCSP
          [Toerless] maybe my point on that is that the actual Bruschi mechanism
             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
          8.Autonomic Slice Networking - 20min
             11:05 - 11:25, by Alex Galis,
          [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
             domain. Multi-domain could add a lot of other features and capabilities
             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
             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
          [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
             then you put up a bunch of virtual routers top of that with virtual
             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
             and new virtual interfaces below, so the upper customer wants to have
             interfaces plugged in from place-to-place he needs a new connection
             that's in the space of some customized ASA to me it's not on any core
             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
             network, then the question is how to build the ACP. If I understood
             correctly, he was saying this could be done through an ASA. That is
             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
             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
             But to me it is just one more use case that fits well within the
             both of 802.AR and Anima. And it is a challenge of saying that
             slicing services will use this model and look at the demands of
          [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
             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
             proposals, and which one of those would have uptake in the group and
             ones perhaps do not in terms of you can test them individually. I
             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
             going on in the DHC working group, I just wanted to bring to your
             which is that they're in the process of taking the DHCP options and
             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
          [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
             parameters, such as domain names etc.
          [Bing] For GRASP configuration, maybe we need to configure some constents,
             as MTU. If we use GRASP-Bulk, it is important to figure out a proper
             And other constents such as maximum hop count TTLs etc.
          [Michael R.] I'm less interested in how do we configure with YANG an
             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
             crossing the street or not.
          11.Summary & ANIMA future activities - 5 min
             11:55 - 12:00, by co-chairs

Generated from PyHt script /wg/anima/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -