Minutes for ANIMA at IETF-92
minutes-92-anima-4
| Meeting Minutes | Autonomic Networking Integrated Model and Approach (anima) WG | |
|---|---|---|
| Date and time | 2015-03-24 20:20 | |
| Title | Minutes for ANIMA at IETF-92 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-04-07 |
minutes-92-anima-4
ANIMA WG, IETF-92 (Dallas) Autonomic Networking Integrated Model and Approach Chairs: Toerless Eckert & Sheng Jiang The Tuesday 2-hour session is dedicated for urgent WG milestones; the Friday 1.5-hour session is mainly for other work items relevant to autonomic network but not in urgent WG milestones. ------------------------------------------------------------------------- Tuesday (March 24, 2015) 2-hour session: 1520-1720 Afternoon Session II, Oak 1. 16:20 - 15:25 WG Dash 5 min ANIMA WG Chairs Slides -no comment from the room. 2. Discovery and negotiation function - 45 min 15:25 - 15:45 Generic Discovery and Negotiation Protocol - 20 min Brian Carpenter, draft-carpenter-anima-gdn-protocol-02, Slides brief overview of the protocol .3 types of objective: discovery, negotiation, synchronization .initiator/responder model .operates above layer 3, ipv6 preferred .authentication and replay protection protocol walk-through Hannes Tschofenig: Are the flows shown meant to work without config and manufacturing certificate ? Brian: almost nothing (e.g. an ID) Hannes: trust relay is also part of draft-pritikin-anima- bootstrapping-keyinfra, not part of your presentation Brian: yes, it is part of draft-bootstrapping Randy Turner : is the discovery multicast Brian: yes open issues .UDP vs. TCP .DTLS vs. TLS vs. built-in security mechanism .dos attack protection TBD .DNS like alternative to discovery .expand objective description .protocol walk-through .cross-check against other ANIMA docs .write code questions Mehmet Toy: why running on layer 3 (only) What about layer 2 Brian: mainly manage L3 resources, autonomic functions at layer 3, but nothing prevents from negotiating layer 2 resources Michael A.: homenet discussion on ISIS running directly over layer 2 and people complaining... do you want to bring it also there Rene: regarding TLS, can you develop the part on costly crypto Brian: cost of asymmetric key for every packet is too high Rene: TLS is a family of algorithms so can use any of them (fitting the needs) 15:25 - 15:55 Autonomic Distributed Node Consensus Protocol - 10 min Markus Stenberg, draft-stenberg-anima-adncp-00, Slides, OriginalURL DNCP is a generalization of HNCP DNCP leaves some details to DNCP profiles scalability issues because of single areas, use of UDP ADNCP extends DNCP for multiple areas and TLS for unicast (still udp for multicast) per objective DNCP possible Raise of hands, ca. 8 people read the draft. 15:55 - 16:10 Combined discussion for GDNP&DNCP - 15 min questions Bing Liu: are these extensions to DNCP to make it autonomic Markus: not really autonomic, but add features to scale...; can use some point-to-point TLVs range for defining arbitrary messages for autonomic use, but it doesn't actually go into detail what point-to-point exchange would be. Bing: is the goal of ADNCP to fulfill requirements of ANIMA Markus: in current DNCP, you can implement more arbitrary autonomic objectives, but it doesn't mean I want to use DNCP in that way, it's only a stating. Stuart: ADNCP does not add (more) autonomic features to DNCP than it already has. Markus: add features to address scalability issues essentially Markus: why generic Should be called autonomic, generic is misleading. Sheng: requirements for the autonomic nodes to communicate among them. Brian: the main reason that GDNP leaves a lot of things open is because we don't know the scope of resources/objectives we want to negotiate Markus: seems like flooding a lot, not good. Brian: victim of ARP storm 25 years ago. In a very large (prof-managed) network possibly arrange to stop the flooding. Markus: design of the protocol... Brian: take a use case and compare the different solutions Toerless: we already have simple example use case: set up of the autonomic control plane Markus: too simple, not interesting Toerless: need information to decide which protocol to choose Markus: this is only an academic exercise (ADCNP) Sheng: would you been interested in joining a design team Markus: possibly... Michael R.: don't understand what GDNP is for. There are good reasons to separate discovery from negotiation. DNS-SD is not applicable here. I don't want to do the 2 steps (bootstrap & discovery) together, prior to boot strap. If already boot strap, then it is able to talk to proper machines to achieve the same. Markus: not what you want, because not secure Michael R.: I now understand if the discovery is after bootstrap, maybe the node can be told the capabilities ratherthan discovery. Sheng: notification the capability is also a way of discovery. Brian: under resource consumption, can be completely event driven. At UCAN BoF several use cases to exemplify GDNP. Michael B.: distinguish between establish trust and discovery. Want to have the same protocol to find the place to enroll (trust anchor). Tommy Pauly: talking on behalf of Stuart Chesire. Discovery process, could explore if DNSSD can apply using proxy/ filtering, for that initial bootstrapping process, it seems exactly a bonjour request for finding a trustee. Markus: find onlink neighbor is ok. But find offlink node is different. Toerless: big difference between making DNSSD on top of these protocols and running MDNS. 3. Auto bootstrapping - 45 min 16:10 - 16:25 Bootstrapping-keyinfra - 15 min Michael Behringer, draft-pritikin-anima-bootstrapping-keyinfra-01, Raise of hands, ca. 10 people read the draft. Steven: more secure than DHCP. If add a device to a link with already initial config, can break your scheme. Mehmet Toy: where is the network authentication on your slide? Michael: the network is (only) "passing" the ID. Max (remote): answering Mehmet Toy, the authorization of the network is a joining step by device vivificating the token; register verifying in the log. Mehmet Ersue: will something go wrong if zero-touch netconf does not follow your approach (after Kent's presentation) 16:25 - 16:35 Netconf zero touch update for anima - 10 min Kent Watsen, draft-ietf-netconf-zerotouch-02, Slides Raise of hands, ca. 8 people read the draft. Hannes: how done in OMA M2M, maybe relates. Is what I have described in relation with what you are doing Is it the same problem or a different one trying to solve. Kent: terminology issue. Sheng: after next presentation Michael: different case, because you assume a certificate already in the device. Max (remote): Zero-Touch draft not incorporated with the 3 points in slide 9. Difference between ownership VS. math authorization: in ownership, you expecting vendors to be all to known to the security channel, but math authorization does not do it, am I correct in interpretation Kent: discussion on who is the rightful owner. 16:35 - 16:45 Survey of Security Bootstrapping - 10 min Raise of hands, ca. 4 people read the draft. Danping He, draft-he-6lo-analysis-iot-sbootstrapping-00, Slides Hannes: all the 3 mechanisms provide authentication. It's hard to say which one is better, it depends on many aspects. 16:45 - 16:55 Combine discussion - 10 min too late. no discussion. 4. Autonomic Control Plane & Discussion - 25 min Raise of hands, ca. 12 people read the draft. 16:55 - 17:20 Michael Behringer, draft-behringer-anima-autonomic-control-plane-02, Slides Mehmet T.: what are you configuring with this solution Michael: not about configuration at all. Brian: you could run netconf on top of it Michael: we are not looking for devices with absolute no dependency to configuration. This is for the longer term future. Michael A.: not solving the case of layer 1 connectivity/ reachability. Mohamed Boucadair: deterministic behavior of the network. Any way to have an exit button Fallback to legacy mode of operation. Michael: work with existing data plane processes. Mohamed: the option should be left to the operator's choice, not in the design, maybe beyond your presentation. Michael: Do the participants think the ACP is useful Michael A.: It should restrict to useful in some scenarios. The room hummed -------------------------------------------------------------------------- Friday (March 27, 2015) 1.5-hour session 1150-1320 Afternoon Session I, Parisian change in agenda: Presentation by Rene is cancelled/postponed. 1. Reference model - 20 min Michael Behringer, draft-behringer-anima-reference-model-00, Slides John Strassner: do you plan to re-use work from other groups e.g. service discovery. Michael: yes. We will steal whatever we can. John: MANET has mechanisms for discovery. Mentions DLEP as mechanism for neighbor discovery. Toerless: Please open a discussion on the mailing list on that topic! Dean Bogdanovic: started simple prototype implementation of autonomic networking. Thinks it is necessary that a single agent can covers multiple devices that are geographically close to the agent. Toerless (as an author): Supporting this notion. Explain how draft authors did not want to put it from the beginning to not boil the ocean before having confirmation of requirements/ interests. Sheng: We are at the beginning stage to understand the requirements for the autonomic network. We encourage you to raise your specific requirements. The chair may later form a design team to work on the common reference model. John Strassner: worked a bit on autonomics, urge the WG to not just think in terms of APIs but as software contracts (pre/post conditions), do not change over the life-cycle of a function. bring rigor. Capabilities: willing to work to define more formally this aspect. GDNP seems overloaded if tries to negotiate for everything. Toerless: Asks where formalisms mentioned exist (not aware of IETF formalisms). John: not in IETF, but in other SDOs. Bing Liu: Willing to contribute also on current un-filled contents and also possible extensions of reference model. Section 7: Distinguish ACP as component of the ANI and the ASAs running to top of the ACP, might need to distinguish them more clearly in the draft. Michael: correct. 2. Observations on bootstrapping and synchronization - 15 min Rene Struik, no draft, no slides received Postponed by the speaker. 3. Coordinating multiple (conflicting) autonomic functions - 15 min Laurent Ciavaglia, no draft Toerless: Please provide a simple example to illustrate. Laurent: ECMP agents and power saving agents. ECMP agent try to keep up links to best utilize bandwidth but power saving agents try to shut down links. Conflict of interest between agents requires coordination between them (who is more important compromise.. ). Michael: Lot of this happens at ASA level. Is something missing in the infrastructure for this Laurent: Unclear. Will review documents to identify gaps. John Strassner: Work on knowledge representation. May need to be explicitly added to the infrastructure to be able to be explicitly used by infrastructure. Need some way to reason about knowledge. Otherwise two different services looking same at the surface but incompatible due to their dependencies. Look at KIF/Common Logic. Brian: What is common between separated coordination function in different Autonomic server agents Is it a separate ASA or common for all ASA (in the infra). Laurent: we need to answer that in the coming work. Michael: what is need in the infrastructure Laurent: It depends on the definition of infrastructure. It may be implementation choice or deployment model choice. We need to work on it further. Sheng: But, it is still confuse whether this is requirements for each ASA or a reusable component to support all ASA. The current WG charter is focusing on reusable component in the AN infrastructure. We certainly think coordinating is important since there are conflictions. You need to come back with a concrete functional requirement. Laurent: understand that. John: it should be added in the infrastructure. It should be a function that every ASA can use. Would be happy to help on how to exchange the knowledge. 4. Self-Managed Networks with Fault Management Hierarchy - 15 min Toy Mehmet, no draft, Slides Bhumip Khasnabish: Is this deployed/implemented in Comcast network Mehmet: Vendors not yet implementing required dependencies. Bhumip K.: if NEs starts testing at the same time, can break your network. Mehmet: no, run the testing in the background 5. Predictive risk awareness for proactive management - 15 min Laurent Ciavaglia, no draft, slides Toerless: Requirements against underlying infra for Laurent "predictive" and Toy's "reactive/tracking" management actions look very overlapping, true Laurent: Yes, Toy nodding. Brian Carpenter: very interesting. Would have liked to see compressed version of Comcast presentation to be able to extracts requirements against the infrastructure. Bing Liu: is ASA-ASA communication involved for it Laurent: two models, one is one ASA local decision; the other involves ASA-ASA communication 6. Closing by Co-Chairs - 10 min Toerless: Would like to start building design teams for a) bootstrap and b) signaling, which are milestone building blocks. If interested to participate, please send mail to chairs. We will also reach out to the candidates we think would be great to have. Goal of design teams of course is to work on a common solution. Do not want various contributors to come in and beat each other up on competing solutions - but rather work towards a common goal. Think ACP is at the current level of design uncontentuous enough that we do not need a design team. But ACP depends on the other two components, so the design teams shuould not only resolve their own requirements but those of the two other milestone building blocks. Think that bootstrap is the most urgent problems due to ongoing work in NETCONF (and others...). Plan to set up a virtual interim for it. To ensure that we really make progress towards the three milestones, the chairs will post questions about - Scenarios to understand the scope that the design teams feel they want to cover and - How the components of the milestone building blocks could interact. So that we quickly resolve agreed mutual requirements that the design teams need to resolve. Sheng: the participants who are interested in the design team also need to feedback their time zones so that the chairs can organize interim meetings accordingly. If the chairs cannot find a good time suitable for all design team members because the global distribution, we have to share the pain by switching between two chosen times.