* 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-102 anima minutes

Session 2018-07-18 0930-1200: Van Horne - Audio stream - anima chatroom


minutes-102-anima-02 minutes

          Autonomic Networking Integrated Model and Approach
             Chairs: Toerless Eckert & Sheng Jiang
             IETF102, Montreal, Canada
          Wednesday (July 18th, 2018) 2.5-hour session:
          9:30-12:00, Van Horne, Morning session I
          1. WG Dash - by co-chairs
          2. WG Document Update (30min)
             2a. GRASP Application Program Interface (API) - 10min
               9:35 - 9:40, by Bing Liu, draft-ietf-anima-grasp-api
          No comments.
             2b. Autonomic Control Plane - 10min
               9:40 - 9:50, by Toerless Eckert,
          [Brian Carpenter] regarding domain admission controller, it needs to be
             that it's not sort of a protocol spec; it's something we don't need
             to describe
             in detail in the protocol.
          [Toerless] authors like me prefer to elaborate more than necessary;
          but maybe
             really as you said, just the minimum statement
          [Alex Galis] 1. Network functions have their own control plane, what's
             relationship with ACP? 2. ACP allows external operators or a management
             to practically configure it, then where are the primitives or the
             APIs to allow
             this to happen, and is it a control plane or it's a management plane
             3. reachness of network function is not well exploded
          [Toerless] ANI is for any communication fabric that we need for autonomic
             or for centralized management; it does nothing more than IPv6
             btween autonomic agents, service discovery through GRASP and security
             certificates, and it's equally to anything centralized in the NOC.
             2c. Bootstrapping Remote Secure Key Infrastructures (BRSKI) - 5min
               9:50 - 9:55, by Toerless Eckert,
          No comments.
          2d. Constrained Voucher Artifacts for Bootstrapping Protocols -10 min
               9:55 - 10:05, by Peter van der Stok,
          [Toerless] Are there any real relevant functional differences between
          all these
             versions? (BRSKI, EST-COAPS, Constrained Voucher, Constrained
          [Peter] In principle it's all the same
             in MASA); the only difference is we want to reduce the payload,
             instead of
             HTTP we want to use CoAP, and then COSE is there.
          [Eliot Lear] There is a public key also transmitted as part of the
          voucher, can
             you comment on that£¿That might be a difference between the base
          [Peter] In 6tisch environment, we use certificates, but also possibility
          to use
             public keys exchange for the protection.
          [Brian] The Constraint Join Proxy would not itself be constrained? I
          assume the
             Constraint Join Proxy would join the registrar in the same way as
             the normal
          [Peter] Yes.
          [Brian] How does the pledge discover the Constraint Join Proxy?
          [Peter] We're still working on that.
          [Brian] I'd like to know if it's going to use GRASP.
          [Peter] One concern is to make this Constraint Proxy also stateless.
          [Brian] We could always talk about a mini version of GRASP for that
          [Peter] Always open to know good ideas.
          3.  Autoconfiguration of NOC services in ACP networks via GRASP
              10:05 ¨C 10:15, by Toerless Eckert, draft-eckert-anima-noc-autoconfig
              draft-eckert-anima-grasp-dnssd ¨C 10min
          [Peter] For DNS-SD, do you want to export evertything that is known in
             to the DNS later on?
          [Toerless] At this point in time, it's basically an island, so we've
             thinking about keeping very separated.
          [Laurent Ciavaglia] You propose to have a set of base NOC services to be
             autonomically discovered, and we connect it with the ANI and
             infra, is it on purpose that you limit it to this kind of NOC
             terminology, or
             we can think about all the services, I'm just thinking about for
             instance you
             want to subscribe or to discover some measurement or telemetry
          [Toerless] Here a minimal set that I would love every node that supports
             ACP to actually implement it.
          4.  Bootstrapping Key Infrastructure over EAP & BRSKI over IEEE 802.11 -
              10:15 - 10:30, Owen Friel, draft-lear-eap-teap-brski &
          [Brian] A lot focus here to proof of ownership in a sense of proving
             joining the network that you're happy to join; the opposite question,
             whether the network is happy for you to joint it, it should be in
             your proof
             of ownership list of things to be solved.
          [Toerless] In BRSKI, you can only join the network that owns the access.
          [Owen] The MASA has strong identity knowledge and knows which network
             owns which device and that will be very challenging to build.
          [Eliot] For Brian's question, what knowledge does the device have out
          of the box
             does it know the knowledge of the deployment, the whole point of
             BRSKI is
             that it doesn't, it doesn't really know who to join. The additional
             either from the manufacture indicating an authorization or from the
          5.  Autonomic functions lifecycle management & coordination between
              functions & knowledge exchange
              draft-ciavaglia-anima-coordination, draft-ciavaglia-anima-knowledge -
              10:30 - 10:55, by Laurent Ciavaglia
          [Alex] If lifecycle work is progressing and maturing, it might lead to
          a slightly
             different infrastructure which already developed in Anima to be
          [Laurent] I agree with your comment, but we need to discuss what is the
          scope of
             what we want to do, what will be implication for Anima, and then
             start to work
             on specifying a bit more on the content, the format etc.
          [Bing Liu] In general I believe this work(lifecycle) is necessary,
          because this
             work could be considered as a kind of meta-ASA, which can intiate
             ASAs before
             any ASA could work, otherwise we'll need to fall back to mannual
             I'd like to see it be progressed, come up with more specific protocol
             extensions or some node behavior requirements into details.
          [Sheng] The methodology is resonable to be included in the ASA Guidance
             but you need go beyond that and maybe lead some new works here with
             a new draft.
          [Laurent] There is surely a link with the ASA Guidelines draft. And
          there should
             be some standard track aspect in a seperate draft.
          [Sheng] (Coordination work)So far not convinced, given how complicated
          to abstract
             a common command set. I'd really like you take the design of this
             work into
             another level, with more detailed designs.
          [Laurent] We've done some POC(uniself project). It will not come with
          a univeral
             solution, but specific solutions to be deployed.
          [Alex] The work would be added value for orchestrators.
          6.  The ANIMA domain boundary - 20min
              10:55 - 11:15, by Brian Carpenter, draft-carpenter-limited-domains
          [Toerless] I think what definitely would be very helpful is you know a
             complete taxonomy (of different constrains, other than IoT) and also
             recommendations on how to deal with them. Not sure what the best WG
             to do it.
          [Brian] We've got some positive feedback in Intarea, people are intrested
          in it.
             But I'm scared of it becoming a topic that's too general. I'd like
             to see if
             there is serious focused interest in actually solving it.
          [Bing] Reading the title "Limited Domains", there are at least two
             1. regarding to human operation, we need to limit the domain for
             or for security considerations; 2. if we limit some mechanism in a
             domain it implies we can allow heterogeneous mechanisms to run
             each domain. Maybe we need to distinguish different aspects.
          [Brian] Yeah, but maybe part of the analysis we still have to do here.
          [Alex] I like the direction. Technology Domains vs. Administrative
             Multi-domain orchestration is now the norm in terms of research and
             development. This could be the source for additional protocols.
             Another dimension domain is changing.
          [Brian] Domain boundary and membership will be time varying concepts.
          [Roland] Do you consider mainly limited domains with respect to
             or is it much broader in the sense that you could also use logical
             associations defining domains on top of a common connectivity
          [Brian] Given teh internet is developing, we can assume everything can
             virtual. the domains could interpenetrate each other due to
             I think the answer is your yes anything.
          [Roland] It's quite a broard thing, it's important. But since it's
             related it's quite hard to come up with some general recommendations.
          [Doug] Are you trying to standardize the conceptual notion of a limited
             or you're a list of examples of different kinds of technologies some
             these domains can be distributed.
          [Brian] It could be. I'd like to reduce your question to "is this node
             this domain", "is this node an edge of the domain". I know how to
             turn it
             into a concrete question to ACP, that's not hard; but if you want to
             be a
             more general concept, then it becomes more difficult.
          7.  Information Distribution in Autonomic Networking - 10min
              11:10 - 10:20, by Bing Liu, draft-liu-anima-grasp-distribution
          [Brian] The proposed GRASP extensions with respect to my prototype GRASP
             implementation and thought I couldn't really see any fundamental
             The only observation I made is the Un-solicited Sync only works if
             the ASA
             at the other end is implemented to listen for the push, it's an extra
          [???](from Oracle) The extensions look useful, but going for your use
          case, are
             you suggesting (3GPP) CT4 consider this is a replacement for what
             specified for SBA?
          [Bing] The scenarios in the draft not necessarily mean we'll go to 3GPP
          to let
             them use it; the bottom line is to give some real example of what
             kind of
             scenario might use the advanced features other than the basic
             GRASP. But the
             co-author hope the 3GPP can consider existing tools rather than
             other dedicated protocols.
          [???] They haven't specified new dedicated protocols, they're using HTTP
          [Laurent] Do you also consider specifying the information semantic?
          [Bing] For this draft, it is out of scope for semantic part. Maybe it's
             proper to discuss semantics in your Knowledge Exchange draft; and
             also I'd
             suggest maybe part of the Knowledge Exchange work could be merged to
             Information Distribution.
          [Laurent] Telemetry, new monitoring protocols are also about collecting
             information and exchanging information, do you see any relationship
             what is here a bit more specific for Anima.
          [Bing] As far as I understand, Telemetry is specific to centralized
             using Netconf/YANG to collect data; but Information Distribution is
             about devices interact with each other.
          8.  Guidelines for Autonomic Service Agents, Transferring Bulk Data over
              - 10min 11:25 - 11:35, by Brian Carpenter,
              draft-carpenter-anima-asa-guidelines &
          No comments.
          9.  Trust networking and procedures for Autonomic Networking - 10min
              11:35 - 11:45, by Tae Sang Choi, draft-choi-anima-trust-networking/
          [Sheng] Your design target is what we already achieved in Anima; we
             have the trust system, the bundary and the way to discover etc. The
             thing missing from current Anima to what you described here is only
             in the
             data communication policy in data plane to stop the node talk to
             nodes out of the network boundary. So I'm getting lost what do you
             want to
             standardize here;what the extra goal you want to achieve here.
          [TaeSang] Beyond BRSKI, considering the communication between the
          [Toerless] I think you've done some prototype and demostration, so if
          we have
             some idea of the practical thing, it would be easier to map it to
             the Anima
          [TaeSang] We do have POC. The gateway have 3 things: trust management,
             management and IP allocation management.
          [Toerless] I read the draft, still difficult for me to translate.
          [Brian] 1. I found your slides are easier to understand than your
          draft. The
             draft is unclear about the relationship with ACP and BRSKI. 2. I
             think what
             Toerless is asking is I don't understand how your domain gateway can
             actually authenticate and check addresses, how does it protect itself
             against spoofed IP addresses, and how does it do this at line speed.
             You don't need to answer now, but the next version will be very
             helpful if
             this is explained much better.
          [Chong?](TaeSang's colleague from ETRI) We have app-layer use case, IPTV
             classify to different media, and sharing economy, e.g. sharing car
             is trust fair enough.
          [Sheng] Is your purpose here to make deployment use case that using
             components to serve your app level ASA, or you try to define some
             new Anima
          components to serve your purpose?
          [TaeSang] More of the latter.
          [Sheng] I'm fine with the first one; but for the latter one, I still
          don't get
             the point what do you want to do.
          [TaeSang] It's app layer ASAs, not new to the infrastructure.
          10. Summary & ANIMA future activities - 5 min
              11:45 - 11:50, by co-chairs
          WG will be re-chartered before/around IETF103.

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