Minutes IETF102: anima
minutes-102-anima-02

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, draft-ietf-anima-autonomic-control-plane

[Brian Carpenter] regarding domain admission controller, it needs to be clear
   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 the
   relationship with ACP? 2. ACP allows external operators or a management system
   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 issue?
   3. reachness of network function is not well exploded
[Toerless] ANI is for any communication fabric that we need for autonomic agents
   or for centralized management; it does nothing more than IPv6 reachability
   btween autonomic agents, service discovery through GRASP and security through
   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, draft-ietf-anima-bootstrapping-keyinfra

No comments.

*******************************************************************************
2d. Constrained Voucher Artifacts for Bootstrapping Protocols -10 min
     9:55 - 10:05, by Peter van der Stok, draft-ietf-anima-constrained-voucher

[Toerless] Are there any real relevant functional differences between all these
   versions? (BRSKI, EST-COAPS, Constrained Voucher, Constrained Join-proxy)
[Peter] In principle it's all the same BRSKI(Pledge-Proxy-Registrar-CA-Vouchers
   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 BRSKI.
[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
   proxies.
[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 specific
   case.
[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 GRASP
   to the DNS later on?
[Toerless] At this point in time, it's basically an island, so we've been
   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 underlying
   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 services.
[Toerless] Here a minimal set that I would love every node that supports the
   ACP to actually implement it.

*******************************************************************************
4.  Bootstrapping Key Infrastructure over EAP & BRSKI over IEEE 802.11 - 15min
    10:15 - 10:30, Owen Friel, draft-lear-eap-teap-brski &
    draft-friel-brski-over-802dot11

[Brian] A lot focus here to proof of ownership in a sense of proving you're
   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 operator
   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 info
   either from the manufacture indicating an authorization or from the deployment.

*******************************************************************************
5.  Autonomic functions lifecycle management & coordination between autonomic
    functions & knowledge exchange
    draft-peloso-anima-autonomic-function, draft-ciavaglia-anima-coordination
    draft-ciavaglia-anima-coordination, draft-ciavaglia-anima-knowledge - 25min
    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 changed.
[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 operations.
   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 draft;
   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 more
   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 aspects:
   1. regarding to human operation, we need to limit the domain for scalability
   or for security considerations; 2. if we limit some mechanism in a certain
   domain it implies we can allow heterogeneous mechanisms to run differently
   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 Domains.
   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 connectivity
   or is it much broader in the sense that you could also use logical
   associations defining domains on top of a common connectivity substrate.
[Brian] Given teh internet is developing, we can assume everything can be
   virtual. the domains could interpenetrate each other due to virtualization.
   I think the answer is your yes anything.
[Roland] It's quite a broard thing, it's important. But since it's context
   related it's quite hard to come up with some general recommendations.

[Doug] Are you trying to standardize the conceptual notion of a limited domain
   or you're a list of examples of different kinds of technologies some of
   these domains can be distributed.

[Brian] It could be. I'd like to reduce your question to "is this node within
   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 difficulty.
   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
   feature.

[???](from Oracle) The extensions look useful, but going for your use case, are
   you suggesting (3GPP) CT4 consider this is a replacement for what they've
   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 specifying
   other dedicated protocols.
[???] They haven't specified new dedicated protocols, they're using HTTP with
   JSON.

[Laurent] Do you also consider specifying the information semantic?
[Bing] For this draft, it is out of scope for semantic part. Maybe it's more
   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 between
   what is here a bit more specific for Anima.
[Bing] As far as I understand, Telemetry is specific to centralized server
   using Netconf/YANG to collect data; but Information Distribution is more
   about devices interact with each other.

*******************************************************************************
8.  Guidelines for Autonomic Service Agents, Transferring Bulk Data over GRASP
    - 10min 11:25 - 11:35, by Brian Carpenter,
    draft-carpenter-anima-asa-guidelines & draft-carpenter-anima-grasp-bulk

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 already
   have the trust system, the bundary and the way to discover etc. The only
   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 other
   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 entities.
[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
   case.
[TaeSang] We do have POC. The gateway have 3 things: trust management, domain
   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 customer
   is trust fair enough.

[Sheng] Is your purpose here to make deployment use case that using Anima
   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.