ANIMA WG, IETF-93 (Prague)

Autonomic Networking Integrated Model and Approach

Chairs: Toerless Eckert & Sheng Jiang

There are two sessions (150+90 minutes) for the ANIMA WG:

Monday, Morning Session I 0900-1130

Thursday, Afternoon Session III 1740-1910

For both sessions, the chartered work items have the priority.

-------------------------------------------------------------------------

Monday (July 20^th, 2015) 2.5-hour session:

9:00-11:30 Monday Morning session I, Karlin I/II

1. WG Dash - 5 min
9:00 - 9:05, by co-chairs
No comment from the room.

2. ANIMA Generic Signaling (Design team) - 35 min
9:05 - 9:40, by Brian Carpenter, draft-carpenter-anima-gdn-protocol
Brian C.: we suggest to rename the protocol name from GDNP
(Generic Discovery and Negotiation Protocol) to GRASP
(GeneRic Autonomic Signaling Protocol)? Two considerations:
easier to say than GDNP; leaves scope for future extensions.
WG showed no objection on renaming it to GRASP.
Henk Birkholz: Regarding to CBOR, you should look at CDDL whether
it's suitable for your problem space.
Brian C.: Not sure if CDDL is quite finished yet. For JSON-like
notations, CBOR is a very powerful tool. Whether people think this
efficiency loss is worth paying the other advantages moving to
object-oriented approach?
Markus Stenberg: In general, I don't care about the end coding or even
transmitting, because I assume these would not be very chatty things.
One observation of efficiency is that it becomes a problem if you are
sending multicast because you can't fragment them.
Brian C.: In our model, multicast only comes up in the context of
discovery. If we could find a way that the discovery packets never
exceed 1500 bytes, I think it will be OK.
Toerless: one question is whether we should work in datagram
environment or it's good enough to work in a stream environment.
Even for unicast, the stream environment like TCP/SCTP would make
life for larger objects like intent a lot easier.
Markus S.: then I guess it means you're essentially not using multicast for
anything except for the three primitives. You can do multicast stream?
But I can't.
Toerless: the idea is I think GRASP will do hop-by-hop application layer
multicast. One the layer-2 link, I do TCP/SCTP, I can still multicast
across multi-hops at the application layer.
Who thinks we should explore the Object-Oriented approach in much detail?
Lots of hum.
Who thinks that will be a bad idea if we stick into the traditional TLV design?
No hum.
WG Chair solicited hum support for the signaling documents:
lots of hum supported; non opposed

3. ANIMA Auto Bootstrapping (Design team) - 35 min
9:40 - 10:15, by Max Pritikin, draft-pritikin-anima-bootstrapping-keyinfra
Michael B: a clarification question: this is not saying like for a constrained
node "I cannot do security"; but it is saying "I do not want to do security".
(Max P.: correct.) So the constrained node considerations are still there,
maybe there are devices that cannot support for example the certificates.
Toerless: what's happen if there is neither a nonce nor data information,
what's the security then?
Max P.: you have a permanent ownership claim of the device.
Sheng: what's the security mechanism between domain bootstrapping
server and cloud server? Is that solved in your draft?
Max P.: Yes. It depends on the PKI model of authentication.
Brian C.: you're using url as the redirection option, and you're assuming
one of the pros is to run over http. If you go this way, and we go
JSON/CBOR way, we're stating the renders stuff is big enough to
process JSON and http. Just want to check that assumption is one of
what the WG would actually buy.
Max P.: we did make assumption http could be used by nodes. There is
some texts regarding to JSON, we can revise it to TLV, based on
feedbacks in the WG.
Toerless: a suggestion on redirect versus full-config download. Maybe a way to
get to the middle line is to have a most simple YANG model for a redirect to
specify what we'd like to see in Anima.
Max P.: that is to say, here is profile we think proper for bootstrapping
WG Chair solicited hum support for the secure bootstrapping draft:
lots of hum supported; non opposed

4. Autonomic Control Plane & Addressing - 30 min
10:15 - 10:45, by Michael Behringer, draft-behringer-anima-autonomic-control-plane
& draft-behringer-anima-autonomic-addressing
Toerless: (discussing slides showing goals): maybe have separate goal for 'robust'
independent of 'must provide IPv6 connectivity'
Michael Richardson(via Jabber): Can ACP make network so complex that even
ACP can't guarantee (robustness) we will shoot ourself in the foot (keep ACP
simple to be robust).
Michael B.: the ACP will add some complexity to the network for sure. We have to
make sure it as simple as possible. But there is added value; and if you add
value that usually comes with some additional complexity.
Sheng: you depend on IPv6 (ULA), currently doesn't support IPv4; Generic should
mean IP version independent?
Michael B.: No. We should stick to one protocol for complexity reason.
Toerless: Generic is a very generic word (eg: suggest to reconsider wording to be
more specific). The answer to Sheng, it's not basically anybody who wants to
use the ACP could expect exactly get his own personal choice of layer2/3
protocols (in the ACP), but he will get the ability to for robust connectivity that
he (hopefully) doesn't have to worry about addressing.
Juliusz Chroboczek: some rumor that one of the simple routing protocols in
consideration is RPL. I strongly recommend you to take a weekend off,
implement RPL from scratch before commit using RPL as a "simple" routing
protocol.
Michael B.: I can only comment in our implementation that we're running RPL.
Henning Rogge: most routing protocols I think use multicast to talk with each
other, how does this work get a concept of secure tunnels with most time the
tunnels are point-to-point. Do you plan if the ACP detects 20 neighbors in the
link-local zone to build 20 tunnels and duplicate every multicast 20 times?
Michael B.: Indeed. The fundamental observation is short of secure multicast which
is a complex thing. If you want to know who you are talking to, you have to have
a one-of-one security association with your neighbors on the link.
Toerless: if we say the signaling through ASAs depends on the security of the ACP,
then we need to figure out what is the minimal requirement to ensure that a
message from one ASA to another is protected all along the path by the ACP.
This either means potentially a full mesh of p2p security associations between all
AN nodes, or - and that's what we propose in ACP - to have hop-by-hop security.
We hope this is most simple.
Michael R.: I don't understand the data plane based ACP, does it mean that GRASP
has to provide application layer objecting routing function?
Michael B.: No. In that case, it means you rely on the routing instance that has been
configured.
Michael B.: who had read the draft? (Some hands raised).
Markus S.: some might only read the previous version.
Brian C.: Suggest people read all three documents and comment, also for the
GRASP and Bootstrapping. For GRASP, hope people to tell whether there is
something wrong.
Michael R.: very concerned about the ACP draft readability.
Michael R.: still not understand data plane based ACP, will layer3 GRASP packets,
or GRASP before things hop-by-hop?
Michael B.: It depends on the operational model of GRASP.
Brian C.: normally, the GRASP discovery result should be ACP routable address.
Michael B.: GRASP is actually one way to use ACP.
Toerless: GRASP in/out ACP, need describe in the reference model.
Michael R.: GRASP is the protocol to get the addresses for the data plane to work,
so before it exist, how do things work?
Michael B.: For the independent model, it needs the data plane routable before
GRASP can do anything beyond link local.
WG Chair solicited hum support for the ACP document:
lots of hum supported; non opposed.

5. Reference model - 30 min
10:45 - 11:15, by Michael Behringer, draft-behringer-anima-reference-model
Sheng: there are some contents not in current charter yet. With Chair hat on, the
current draft should focus on the charted content.
Juliusz C.: it's not clear for me about the concrete devices, some examples
that clearly in and clearly out of the gray zone?
Michael B.: ...I really don't know, ideally we want a model, for example a light bulb
autonomically registered to the light bulb switch, it supports some basic form
of GRASP or whatever, is that feasible? I cannot tell right now. My wish is that
a light bulb can join an autonomic network.
Brian C.: one test case: is the lighting controller for the M floor in Prague Hilton,
is that powerful enough to run an ASA?
Toerless: two limitations for a full-autonomic node, one is the size; the other one is
it must routing. Anything that cannot route, I'd to put it as constrained and talk
about it later.
Sheng: there is one important section missing in Section 4, an overview of the
infrastructure, the reference model should describe how those components
working together and how they fit each other, like some components using
GRASP in some places.
Toerless: what's the minimum for naming and addressing?
Michael B.: we have to figure out what's in the certificate;
Toerless: unless someone brings a good reason why we need naming, we will
use random names.
Sheng: I don't think even random names are needed here. What we actually need
here is some statement saying we need a name here, whatever the name is.
That's good enough for other components. Whether it's random or some cool
mechanism to get out some human-readable names, that's something else,
out of scope for now.
Michael B.: We need to define naming at least to the extent to what we put in the
subject name in the certificate
John Strassner: I'm really nervous about overloading names for semantics. It's
really a bad idea. IMO, I think instead we should look at Metadata that can be
used to be augmented. Nodes augment their features to be used in GRASP,
or could be used in other things.
Teco Boot: ULA, is it for the site or for the whole domain? What happened if
multiple domains...
Michael B.: Nodes get addresses, not ASAs.
Toerless: I still like the idea, autonomic nodes get prefix, so that each ASA could
get an address. But at this point, I wouldn't see it as necessary minimum.
Markus S.: why don't you just stick in the type of the hash, because technically
there is no reason to reserve 3 bits for that. Given if you only have one hash
method, it is the same as 3 bits other methods that 40bit is very unlikely to
collide.

6. (Postponed to Thursday Session)
Autonomic Prefix Management in Large-scale Networks - 15 min
11:15 - 11:30, by Brian Carpenter, draft-jiang-anima-prefix-management

-------------------------------------------------------------------------

Thursday (July 23^rd, 2015) 1.5-hour session:

17:40-19:10 Thursday Afternoon session III, Congress Hall I

1. Updates from Design Teams - 15 min
17:40 - 17:55, by Brian Carpenter & Max Pritikin
Bootstrap Design Team Update - Max
Toerless: Ensuring the protocols in the bootstrap are inclusive of the protocols
wanted to be used by ANIMA.
Signaling Design Team - Brian
CBOR Mapping questions started.
Goal to determine if CBOR is reasonable to move forward.
Sheng: The reference model shows how the components work together. The
design teams should work with the reference document team to ensure
congruent work efforts.

2. Autonomic Prefix Management in Large-scale Networks - 15 min
17:55 - 18:10, by Brian Carpenter, draft-jiang-anima-prefix-management
Slides are examples to show the use case, not real numbers to be used for this
example.

3. Using Autonomic Control Plane for Stable Connectivity of Network OAM
- 15 min 8:10 - 18:25, by Toerless Eckert, draft-eckert-anima-stable-connectivity
Sheng: Clarification question: solutions defined are built for v6 ACP.
Recv'd v4 ACP draft should review and may apply to this draft as needed
and if applicable.
Lopez: Does CA need to be online.
Toerless: Brought in because they are part of the bootstrap draft.
Lopez: will continue to review and bring up online if required.

4. * Autonomic Network Intent Concept and Format - 10 min
18:25 - 18:35, by Jeferson C Nobre, draft-du-anima-an-intent
Sheng: clarifying as WG chair: this is not a chartered item, although mentioned
intent in the charter text. It may become chartered item when ANIMA is
re-chartered, or another group may define and ANIMA will evaluate.
Toerless: Interested in what version or application of Intent will be applied to
ANIMA.
Brian: Some objects may be large and likely over 1500 bytes
Don: SUPA BOF - may not mean the same thing on the word Intent between
ANIMA and SUPA
John: Draft in SUPA that compares Intent efforts from other sources. Summary
of draft: main diff is amount of specifics that is conveyed in Intent, some
definitions are vague and others want details. SUPA appears in the middle of
the two endpoints.
Michael B: focus on what we do inside of ANIMA. Every function can determine
without Intent should be ASA specific, could increase conflict.

5. * Autonomic Network Intent Distribution - 10 min
18:35 - 18:45, by Bing Liu, draft-liu-anima-intent-distribution
Michael B: - when would you not flood intent? Is there a use case for point to point
intent?
Brian: you may need solicited distribution of intent if a node has been added or was
removed and added again.
Sheng: This appears to be generic distribution function, what is specific to Intent
here? This could be moved into or handled by GRASP.
Brian - Yes, this could be a part of GRASP. GRASP needs to be able to extend to
handle Intent, or generic distribution ability.
John - Nodes will send out Intent, but how do they first get that Intent. Starting to
design and ESP. Is this required?

6. * Self-Managed Networks with Fault Management Hierarchy - 10 min
18:45 - 18:55, by Dan Romascanu, draft-mtoy-anima-self-faultmang-framework
Author not here, please read and provide feedback
Jefferson: it would be good to understand how the model fits into ANIMA model.

7. * Coordination of autonomic functions - 10 min
18:55 - 19:05, by Laurent Ciavaglia (remotely), draft-ciavaglia-anima-coordination
No question from the room

8. Closing by Co-Chairs - 5 min
19:05 - 19:10, by co-chairs

* mean the non-chartered work items.