Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-01.txt

From: [email-masked]
Date: Tue, 06 Oct 2015 09:04:08 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Autonomic Networking Integrated Model and Approach Working Group of the IETF.

        Title           : An Autonomic Control Plane
        Authors         : Michael H. Behringer
                          Steinthor Bjarnason
                          Balaji BL
                          Toerless Eckert
	Filename        : draft-ietf-anima-autonomic-control-plane-01.txt
	Pages           : 22
	Date            : 2015-10-06

Abstract:
   Autonomic functions need a control plane to communicate, which
   depends on some addressing and routing.  This Autonomic Control Plane
   should ideally be self-managing, and as independent as possible of
   configuration.  This document defines an "Autonomic Control Plane",
   with the primary use as a control plane for autonomic functions.  It
   also serves as a "virtual out of band channel" for OAM communications
   over a network that is not configured, or mis-configured.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 6 Oct 2015 16:24:10 +0000

ANIMA WG, 

The below draft went through quite a few changes, in line with the discussions at the last IETF. 

Following the discussions and Sheng's suggestions, I have re-organised the content across the reference model, addressing and ACP drafts a bit. The reference draft will cover the overall flow, "the life of an autonomic device". Previously the ACP draft held a lot of that info. Now the ACP draft just explains how you set up  the ACP, and nothing else. That section (5) had quite some changes, so I recommend to re-read it. In brief: we now start from the adjacency table, where we see all autonomic neighbors. From that we let Intent select "candidate neighbors", or a default policy is "from the same domain". Then, we establish the ACP with those candidates. 

Addressing: This material has been going back and forth a few times. At the last IETF we agreed that the reference model is finally NOT the right place for the full addressing discussion. So, the split is now: Reference does the overall goals, requirements; ACP draft just explains the prefix creation, which is something I think we can agree on pretty quickly, as it's fairly high level. The sub-address schemes now go back into the addressing doc, and Sheng has agreed that while this is part of the ACP milestone, we can have that particular point in a separate draft. I expect some lively discussions about the sub-address schemes, which is why I think it makes sense to keep it separate. 

I have taken the NMS systems out of the ACP creation section. In the end, NMS systems will (hopefully) be autonomic as well, and can join the ACP as described in section 5. So I created a new section 6 on "workarounds" with non-autonomic things. I think it's cleaner this way. 

Sections 7 and 8 are new. One is for the actual protocol to negotiate the ACP, one is for the channel types we want to support, with a suggestion for the first one (IPsec / GRE), which I believe we have agreement on. 

As agreed in the last ANIMA session, the data-plane ACP is out of scope, and we define only a virtually separate ACP, since it's more or less the same effort, but has significant advantages. This model went into an appendix, and will be removed at the next version (as discussed). 

We were asked to provide some reasoning on the choice of routing protocol, that is now in an appendix as well. 

Currently working on the new version of the reference model and the addressing draft. May I remind the folks that have volunteered to do a section of the reference model, to please get going ;-) 

Undoubtedly, there will be many comments / questions, and undoubtedly there will be more work on this draft. But I hope that the structure is now starting to stabilise. Comments? 

Michael

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: 06 October 2015 18:04
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-01.txt
> 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Oct 2015 08:11:35 +1300

This looks like good progress to me. One comment:

>    o  It determines, following a policy, a candidate peer list.  This is
>       the list of nodes to which it should establish an autonomic
>       control plane.  Default policy is: To all adjacent nodes in the
>       same domain.  Intent can override this default policy.

I see a bootstrap issue there: how does the node acquire Intent securely
before forming its ACP adjacencies?

The answer is presumably to run GRASP in non-ACP mode, i.e. establishing
GRASP sessions over TLS. That seems compatible with the new section 7.
I don't currently see any basic issue with the assumption in section 7
that GRASP can be used; the definition of a GRASP objective is intentionally
very flexible. However, all nodes will need to support TLS, which means
that the security bootstrap has to result in the necessary certificates
being available.

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 6 Oct 2015 19:30:41 +0000

> On Oct 6, 2015, at 1:11 PM, Brian E Carpenter <[email-masked]> wrote:
> 

One could include some intent distribution during bootstrapping but is that even necessary? I don’t see the problem with the device using the above default policy (hypothetically it’ll fail to communicate with some nodes) until the true policy is obtained?

> GRASP sessions over TLS.

This just moves the problem to bootstrapping GRASP sessions over TLS. 

- max

> That seems compatible with the new section 7.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 6 Oct 2015 19:55:11 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Max Pritikin
> (pritikin)
> Sent: 06 October 2015 21:31
> To: Brian E Carpenter <[email-masked]>
> Cc: Anima WG <[email-masked]>
> Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-
> 01.txt
> 
> 
> > I see a bootstrap issue there: how does the node acquire Intent
> > securely before forming its ACP adjacencies?
> 
> One could include some intent distribution during bootstrapping but is that
> even necessary? I don’t see the problem with the device using the above
> default policy (hypothetically it’ll fail to communicate with some nodes) until
> the true policy is obtained?

I second Max here. At time of first bootstrap, you follow default policies. Let's not make life too complicated ;-) 
 
Michael

> > The answer is presumably to run GRASP in non-ACP mode, i.e.
> > establishing GRASP sessions over TLS.
> 
> > that GRASP can be used; the definition of a GRASP objective is
> > intentionally very flexible. However, all nodes will need to support
> > TLS, which means that the security bootstrap has to result in the
> > necessary certificates being available.
> >
> >    Brian
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Oct 2015 15:05:15 +1300

> I second Max here. At time of first bootstrap, you follow default policies. Let's not make life too complicated ;-) 

I have no problem with that, so I suggest removing the ambiguity
by adding a note that this override can only take place after
an initial ACP has been formed.

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 7 Oct 2015 07:00:20 +0000

> >> One could include some intent distribution during bootstrapping but
> >> is that even necessary? I don’t see the problem with the device using
> >> the above default policy (hypothetically it’ll fail to communicate
> >> with some nodes) until the true policy is obtained?
> >
> > I second Max here. At time of first bootstrap, you follow default
> > policies. Let's not make life too complicated ;-)
> 
> I have no problem with that, so I suggest removing the ambiguity by adding a
> note that this override can only take place after an initial ACP has been
> formed.

Good point, I'll do that! Thanks Brian!

Michael