ANIMA WG, IETF-94 (Yokohama)

Autonomic Networking Integrated Model and Approach

Chairs: Toerless Eckert & Sheng Jiang

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

Monday, 1300-1500, Afternoon Session I

Tuesday, 1520-1650, Afternoon Session II

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

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

Monday (November 2^nd, 2015) 2-hour session:

13:00-15:00 Afternoon Session I, Room 304

1. WG Dash - 5 min
13:00 - 13:05, by co-chairs
https://www.ietf.org/proceedings/94/slides/slides-94-anima-0.pdf

Planning adoption calls after this IETF meeting on the list:
draft-behringer-anima-reference-model
Next milestone: Jul 2015, Adoption of reference model
draft-eckert-anima-stable-connectivity
Next milestone: Jul 2015, Adoption of the two validation drafts
draft-jiang-anima-prefix-management
Next milestone: Jul 2015, Adoption of the two validation drafts

Documents that are considered as chartered work items without current
milestones:
draft-behringer-anima-autonomic-addressing
draft-liu-anima-grasp-distribution
Chairs encouraged contributions (IDs) on ASAs to consider possible
topics/areas for re-chartering discussions next year.

No comments from the room.

2. ANIMA Generic Signaling (Design team) - 30 min
13:05 - 13:35, by Bing Liu, draft-ietf-anima-grasp
https://www.ietf.org/proceedings/94/slides/slides-94-anima-2.pdf

The presenter mentioned previous main changes:
- protocol name changed from GDNP to GRASP
- message/option definition changed from TLV to CBOR format

**Discovery relevant open issues**
Open issue no18: handling of multiple discovery responses
Sheng Jiang: 1) some scenarios may wish to have multiple responses.
Default to one response is not right. 2) I don't think the GRASP
as a fundamental protocol to do the choice, should expose to ASAs
depending on different discovery objectives.
Laurent Ciavaglia: consider to include a flag to indicate one or
multiple or all responses the sender want to get.
Sheng: not sure a flag is a good design, receivers don't know about
how many responses, only senders know and care
Laurent: issue is to know when (if) all peers have been discovered.
this is more an issue for the ASA first, but is not solvable solely
by the ASA (well know peer discovery problem)
Brian Carpenter: it will never know how many peers are there in some
sense...
Bing Liu: rather than including a flag, the discovery initiator could include
some criteria that how it will choose the most proper response.
Open issue no24: fast withdrawal
Michael Behringer: both the questions go to "where the intelligence is", in
the GRASP or upper layer. I suggest draw the line what intelligence is
in GRASP and what not. And I think the intelligence generally is in the
layer above.
Sheng: I do agree there should be a clear line. But some actions have
to go through the GRASP, even the decision has to be made by ASA.
So discussed here is ability of GRASP to parse the decision from ASA.
Bing: the question could be simplified as is it the GRASP's job or ASA's
to maintain the caches.
Sheng: the GRASP should have the ability to do this job, but how/whether
to do that job is the decision of ASA.
New open issue: Clarify if/when discovery needs to be repeated
(proposed 1 min for discovery repeat)
Michael B.: should not be defined in GRASP, this is ASA responsibility.
Bing: but do you consider it is a very basic feature to maintain the state
machine of GRASP?
Dean Bogdavic: this is use case by use case basis. Time range is so
wide, how do you specify a specific time.
Sheng: I guess the conclusion would be that it's not the GRASP's
responsibility to set up the repeat period.
Open issue no30: random delay in discovery response
Sheng: I think random delay is bad. But we do need mechanism to limit
the responses number in a very short period. E.g. no more than 3
responses from the same responder.

**Security open issues**
New open issue: mandatory run in ACP?
Michael B.: I suggest default is over ACP. other cases are exceptions.
Toerless Eckert: go even further: there can be different instances of
the signaling protocol. The default one that we want to leverage is
in the ACP.
Bing: then do we need to distinguish the instances in the specification by
different messages, or it is just an implementation (operational) issue.
Toerless: that would come out of the use cases, I don't think we need
anything new in the protocol. There could be a separated instance in
the data plane that used for ACP setup; it is also welcomed for other
use cases if they want to use the data plane GRASP. But the ANIMA
use cases are using the GRASP instances in the ACP.
Max Pritikin: agree with Michael. separate the cases, because
implementations may consider GRASP is secure while in the
exceptional cases it is not.
Toerless Eckert: the hop-by-hop flooding would have additional security
issue if the GRASP instance is out of ACP.

**Other issues**
Open issue no31: Anything else needed for sleeping nodes
Sheng: don't think it's the GRASP business to tell what the sleeping
nodes should do. But from the perspective of Autonomic Network,
such behaviors do need some kind of definition/design somewhere,
maybe in the Reference model draft.
Michael: (linked to the previous discussion). not part of GRASP.
Laurent: if GRASP is agnostic to "clients, then some issues are out
of scope of GRASP, otherwise we need knowledge about what's
above GRASP and how it may impact the design/behavior of GRASP.
Toerless: there is some generic concern arising around reception of
multicast packets within power-saving devices. To extend that in
GRASP, we need to receive multicast packets which may need to
wake us up. With ACP, there is one way to circumvent (ACP will map
to unicast message).
New open issue: are URL locators really needed?
Joel Halpern: ASA may have identities but they don't have URLs, I don't
know what it means to put a ULR locator in What does it mean to put
a URL locator into a request, maybe they are attached via an
autonomic function, but there needs to be a better explanation.
Brian: it could be potentially used in some sort of restful protocol expects
to use URL(not used by GRASP itself). I completely understand your
question.
Open issue: Selective flooding
Pierre: would you expect GRASP layer itself to identify whom the flooding
goes to; or would you expect the originator decide to whom.
Bing: current thought is that there needs to be a function which is built
upon GRASP, but not up to the ASA layer, and could be re-used by
various ASAs. We call it Distribution Function.
Sheng called for more feedback for -01 draft version on mailing list.

3. ANIMA Auto Bootstrapping (Design team) - 25 min
13:35 - 14:00, by Max Pritikin, draft-ietf-anima-bootstrapping-keyinfra
https://www.ietf.org/proceedings/94/slides/slides-94-anima-8.pdf

Toerless/Max: use GRASP to carry bootstrap messages?
Should start reusing everything that exists: what is missing for RFC
7030(EST) ?
Max: RFC7030 has everything needed for bootstrap - except explicit
UDP support.
TCP and UDP discussion:
Carsten Borman: new to discussion If you really want to use UDP
(unclear why), then you may want to use COMI (..Management
Interface - using CoAP. CoAP handles segmentation to replace
UDP fragmentation).
Toerless: issue is for the proxy?
Max: not impacting the proxy
Sheng: your role is to compare based on your scenarios, and come with
a suggestion. cannot keep it open.
Max: will do.

Bootstrap sequence: Picture is missing to describe case of finding proxy via
(insecure) DHCP/DNS info (DNS prefix).
Max: Was implied to be part of existing block, will be fixed.
Discussion about discovery mechanism (s3.1.1):
- options 2 and 3. are likely equivalent: DNS-SD with .local is
mostly link-local == what GRASP can discover as well.
- option 4: example.com has to be learned by some mechanism, eg:
DHCP.
Max: cf. points 3-5.
Michael: everything starts with the adjacency table (build up with
GRASP), then for neighbors with no domains, start secure bootstrap.

4. Autonomic Control Plane & Addressing - 20 min
14:00 - 14:20, by Michael Behringer, draft-ietf-anima-autonomic-control-plane
https://www.ietf.org/proceedings/94/slides/slides-94-anima-10.pdf

Max Pritikin: wrt. previous discussion, GRASP not indicated as requirement
for ACP. so GRASP/ACP should not be in the draft.
Michael: there is a discovery then an adjacency table. need to discuss
more and document.
Sheng: slide 6: concerned with term intent, not defined.
Michael: rfc7575 - policy language is called intent, eg: claims the
term can be used.
John Strassner: Define intent in a particular way, but not bothered by the use
of the word intent here.
Jefferson: even though it is unclear how exactly defined, it is nice to use it
here. We can use the term (as per RFC7575), not good to change
current word
Hannes Tschofening: since the "intent" came out from Google for Android,
lots of people began to use this word. For Android people, they'll be
confused by the "intent" here.
Toerless: event if don't know how intent will work network wide.
good to keep possibility to negotiate capabilities.
Michael Richardson: sequence of events setting up channel.
Would like to not see domain-name to be exchanged in the clear.
what is the minimum information to be exchanged ? Privacy
considerations. Maybe need some more guidance to make the right
choices.
Toerless: looking for what's best/recommended in IETF for privacy
and to my knowledge this is TLS.
Sheng: appoint 2 reviewers, Michael Richardson, Jason Coleman for the
draft.
Sheng: first tried to make autonomic concept independent of IP. ACP is IPv6.
not fully convinced we don't need ipv4...
Michael: section in the draft about why IPv6. AN is new, so coded in IPv6
(the ACP). what runs inside the ACP (ASA) can run whatever.

5. Reference model - 30 min
14:20 - 14:50, by Michael Behringer, draft-behringer-anima-reference-model
https://www.ietf.org/proceedings/94/slides/slides-94-anima-9.pdf

Laurent: listen to what? GRASP? autonomic messages only?
Michael: yes. GRASP. nodes speaking autonomic language.

Max: does this mean the value of the certificate field would come from a
successful ACP establishment?
Michael: correct. this builds up over time.
Tim Carey: big concern about run unsecured can be an issue (think DoS
attack, SPAM adjancency, then build the invalid table).
Toerless: table is ok from a data structure viewpoint but flow-chart
might be more helpful for understanding.

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

Tuesday (November 3^rd, 2015) 1.5-hour session:

15:20-16:50 Afternoon Session II, Room 303

1. Autonomic Prefix Management in Large-scale Networks - 10 min
14:50 - 15:00, by Sheng Jiang, draft-jiang-anima-prefix-management
https://www.ietf.org/proceedings/94/slides/slides-94-anima-3.pdf
no question

2. Using Autonomic Control Plane for Stable Connectivity of Network
OAM - 10 min
15:20 - 15:30, by Toerless Eckert, draft-eckert-anima-stable-connectivity
https://www.ietf.org/proceedings/94/slides/slides-94-anima-12.pdf
no question

3. Information Distribution over GRASP- 15 min
15:30 - 15:45, by Bing Liu, draft-liu-anima-grasp-distribution
https://www.ietf.org/proceedings/94/slides/slides-94-anima-4.pdf

Michael: confused, distributed on non-ACP interfaces, why? ACP
defines the domain boundaries.
Bing: ACP not mandatory for GRASP at current stage, might change later
according to the GRASP default in ACP approach.
Michael: Previous ANIMA session concluded otherwise (default: GRASP
runs over ACP).
Pierre: nature of information? the nature of information is
attached to the message (if understood correctly). what the info is:
e.g. the link of the load, and the value.
Bing: relates to where the intelligence is located. GRASP is "just"
messaging. does not deal with the content.
Pierre: disagree. the need is not to understand what the
information means, but to attach the description of the information
with the value of the information in the message.

4. Addressing in the ACP - 15 min
15:45 - 16:00, by Michael Behringer,
draft-behringer-anima-autonomic-addressing
https://www.ietf.org/proceedings/94/slides/slides-94-anima-11.pdf

Max: consistency with bootstrap draft, domain defines the hash
key... different from the domain string.
Jason Coleman: GRASP routed between domains, how to handle that in a
sub-domain hand of view. Normally sub-domain will handle it to the
parent domain, but with random prefix, it would be difficult to do so.
Michael R.: differentiate between AS domain name, version
sub-domain names. case when you want separate ACPs, or want
different authorities for subsidiaries. not necessarily different address
space., find a better term than "sub-domains".
...really want only one prefix for ACP (not different random prefixes for
sub-domains)
Michael B.: need to think more.

5. Call WG consensus on documents management
Chairs asked for adoption hums:
for reference model draft: hum is favor. no hum against.
for the two validation drafts: hum in favor. no hum against.

Laurent: other options on the table (charter explicitly cite
these two use cases, no other allowed)?
Toerless: if there is clear rejection, we can have the discussion.

Chairs raised the questions on whether the WG wants to continue the work
that are considered as chartered work items without current milestones.
Michael B: addressing is in part of ACP. It should be considered have
milestone.
Terry (AD): already part of the charter. can split the milestones. Chairs
could ask adoption call.
Chars asked for adoption hums:
for addressing in ACP draft: hum is favor. no hum against.
for distribution over GRASP draft: hum is favor. slight hum against.
for addressing:

for GRASP distribution:
Laurent: what is the criteria to decide what could be considered/could
become WG chartered items
Terry (Resp. AD): individual IDs encouraged, don’t boil ocean.
Joel J. (OPS AD): can discuss. not necessarily WG documents. AD may
sponsor some work. The ANIMA WG should focus on and complete
the chartered work items.
Sheng: one solution could be these two drafts being merge back to their
main drafts.
Toerless: cannot do ACP without addressing, so need to have it as
chartered work item. Flooding may be good improvement, but may
not be necessary.
Jeferson: ok but different situation for GRASP distribution (not part of
GRASP initial goals).

6. * Autonomic Network Intent Concept and Format - 25 min
16:00 - 16:25, by Jeferson C Nobre, draft-du-anima-an-intent
https://www.ietf.org/proceedings/94/slides/slides-94-anima-5.pdf

Toerless (as WG co-chair): requirements from Intent reflections if
suitable/not to GRASP
Michael B: not very at ease with your definition of low level Intent. Intent is
high level concept. Maybe another term for the low level concept.
Jeferson: agree, maybe the use of the term is overloaded.
Max: bootstrapping, need encryption...?

7. * A Day in the Life of an Autonomic Function - 20 min
16:25 - 16:45, by Pierre Peloso, draft-peloso-anima-autonomic-function
& draft-ciavaglia-anima-coordination
https://www.ietf.org/proceedings/94/slides/slides-94-anima-6.pdf

... no time for comment on the mic.
several feedback received at the end of the session and support from the
chairs to progress the identified requirements/extension in the signaling
design team and GRASP ID.

8. Closing by Co-Chairs - 5 min
16:45 - 16:50, by co-chairs

See you in Buenos Aires!

* mean the non-chartered work items.