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

From: [email-masked]
Date: Tue, 23 Jun 2020 19:31: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 WG of the IETF.

        Title           : An Autonomic Control Plane (ACP)
        Authors         : Toerless Eckert
                          Michael H. Behringer
                          Steinthor Bjarnason
	Filename        : draft-ietf-anima-autonomic-control-plane-25.txt
	Pages           : 160
	Date            : 2020-06-23

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 such a plane and calls it the
   "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 Operations, Administration and Management (OAM)
   communications over a network that provides automatically configured
   hop-by-hop authenticated and encrypted communications via
   automatically configured IPv6 even when the network is not
   configured, or misconfigured.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-25
https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-25

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

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 Richardson <[email-masked]>
Date: Sun, 28 Jun 2020 23:02:13 -0400

yes, I read the diffs :-)

-   This document describes a modular design for a self-forming, self-
-   managing and self-protecting ACP, which is a virtual in-band network
-   designed to be as independent as possible of configuration,

+   This document describes a modular design for a self-forming, self-
+   managing and self-protecting ACP, which is a virtual out-of-band
+   network designed to be as independent as possible of configuration,

This change from being a virtual in-band network to a virtual 
out-of-band network must have been in response to some comments... It 
seems a big change in some ways.  I guess it makes this text consistent 
with the abstract which has said virtual out-of-band for awhile now.

But, I do have to wonder if we are creating confusion by claiming that 
this is an out-of-band mechanism, even though it's really an in-band 
mechanism.  It's just virtually-out.

I actually do want to start a bike-shed issue here?
Are we describing ourself wrong?  Maybe there is some portmanteau that 
would be more accurate?  I think that the above sentence is essentially 
the elevator pitch for all of ANIMA.

There is also a bunch of other text that has been added to the 
Introduction, which I think confuses more than it enlightens.
Or at least needs a better copy-edit.

A number of other new sections (9.4..) need a copy-edit to fix some 
missing words.  I will try to help Toerless with that via github.

---

From: William Atwood <[email-masked]>
Date: Mon, 29 Jun 2020 08:45:38 -0400

Is "overlay" the right word?

I agree that it is physically in-band, and virtually out-of-band.  Isn't
that the definition of "overlay"?

  Bill

On 2020-06-28 11:02 p.m., Michael Richardson wrote:
> Attention This email originates from outside the concordia.ca domain. //
> Ce courriel provient de l'exterieur du domaine de concordia.ca
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
> 

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 29 Jun 2020 15:59:43 +0200

Thanks, Michael, inline

On Sun, Jun 28, 2020 at 11:02:13PM -0400, Michael Richardson wrote:
> This change from being a virtual in-band network to a virtual out-of-band
> network must have been in response to some comments... It seems a big change
> in some ways.  I guess it makes this text consistent with the abstract which
> has said virtual out-of-band for awhile now.
> 
> But, I do have to wonder if we are creating confusion by claiming that this
> is an out-of-band mechanism, even though it's really an in-band mechanism.

Its in-band with the physcial component, it is out-of-band with the
configuration of the Data-Plane. Go figure how you compress that
into a single term that most logically captures this. I have been
using virtual out-of-band network forever for this, and Joels review
pointed out that it was not done consistently in the text.

> It's just virtually-out.

With a question mark. Does that mean you do or you do not ?

> Are we describing ourself wrong?  Maybe there is some portmanteau that would
> be more accurate?  I think that the above sentence is essentially the
> elevator pitch for all of ANIMA.

I am not sure if i would elevate it to "all of ANIMA", but i agree that it is
an elevator term for ACP. It is mostly focussed on operators that would
at least heart of actual out-of-band network or have one themselves.

> There is also a bunch of other text that has been added to the Introduction,
> which I think confuses more than it enlightens.

Sure, please propose better text.

> A number of other new sections (9.4..) need a copy-edit to fix some missing
> words.  I will try to help Toerless with that via github.

Thanks

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jun 2020 10:06:51 +1200

Say "secure overlay" to emphasise the point, but yes.

The draft I submitted yesterday "describes a simple method of forming an ACP immediately above the transport layer" which is indeed precisely a secure overlay.

Regards
   Brian

---

From: "Michael H. Behringer" <[email-masked]>
Date: Tue, 30 Jun 2020 08:27:14 +0200

I still prefer the definition "virtual out of band".

An "overlay" (secure or not) depends on correct configuration of the 
underlay. The ACP does NOT depend on configuration in the underlay, that 
is what makes it special.

I haven't seen the definition "virtual out of band" anywhere else, and 
it is the most precise way to describe it.

Michael

---

From: Artur Hecker <[email-masked]>
Date: Tue, 30 Jun 2020 07:13:41 +0000

Hi

I support Michael's view below. "Virtually out of band" is not (anymore) the same as "overlay". Overlays are usually "blind" with regard to the infrastructure and exhibit considerable stretch.

With SDN and programmable infrastructures (and idem with ASAs on every node), it's possible to deploy ACP virtually out of band (secure or not) in parallel to any other traffic and yet with distinctly different structure, forwarding rules, queues, etc. This is a powerful concept to resolve problems with radically different densities that we face when mixing virtual and physical nodes.

Regards
Artur

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Michael H. Behringer
> Sent: Tuesday, June 30, 2020 8:27 AM
> To: [email-masked]
> Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-
> number comments on Action: draft-ietf-anima-autonomic-control-plane-
> 25.txt
> 
> underlay. The ACP does NOT depend on configuration in the underlay, that is
> what makes it special.
> 
> I haven't seen the definition "virtual out of band" anywhere else, and it is the
> most precise way to describe it.
> 
> Michael
> 
> > The draft I submitted yesterday "describes a simple method of forming an
> ACP immediately above the transport layer" which is indeed precisely a
> secure overlay.
> >
> > Regards
> >     Brian
> >
> >> I agree that it is physically in-band, and virtually out-of-band.
> >> Isn't that the definition of "overlay"?
> >>
> >>    Bill
> >>
> >>> Attention This email originates from outside the concordia.ca
> >>> domain. // Ce courriel provient de l'exterieur du domaine de
> >>> concordia.ca On 2020-06-23 10:31 p.m., [email-masked] wrote:
> >>> +   This document describes a modular design for a self-forming,
> >>> +self-
> >>> +   network designed to be as independent as possible of
> >>> +configuration,
> >>>
> >>> out-of-band network must have been in response to some comments...
> >>> It seems a big change in some ways.  I guess it makes this text
> >>> consistent with the abstract which has said virtual out-of-band for awhile
> now.
> >>>
> >>> But, I do have to wonder if we are creating confusion by claiming
> >>> that this is an out-of-band mechanism, even though it's really an
> >>> in-band mechanism.  It's just virtually-out.
> >>>
> >>> Are we describing ourself wrong?  Maybe there is some portmanteau
> >>> that would be more accurate?  I think that the above sentence is
> >>> essentially the elevator pitch for all of ANIMA.
> >>>
> >>>

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 30 Jun 2020 10:33:34 +0200

Hi,

> I still prefer the definition "virtual out of band".

Me, too.
Especially, if one reads RFC8368 it clearly makes the
point that the DCN/OAM networks are normally out-of-band,
whereas the GACP is realized as _in-band_ solution.
So GACP and ACP are "virtually out-of-band". I think that
the editorial change Michael Richardson referred to just
fixed that, because "virtually in-band" would not be
correct.

An overlay is a very generic concept (e.g., IP is an overlay
on top of layer 2 networks) and you can stack
them on top of each other nearly infinitely. So overlays
are nearly everywhere and I think it's also clear that ACP
is a establishing a control overlay.

> it is the most precise way to describe it.

Regards
 Roland

>> The draft I submitted yesterday "describes a simple method of forming
>> an ACP immediately above the transport layer" which is indeed
>> precisely a secure overlay.
>>
>> Regards
>>     Brian
>>
>>>> domain. //

---

From: Brian Carpenter <[email-masked]>
Date: Tue, 30 Jun 2020 21:27:30 +1200

Hi Michael,
To be clear, I don't feel at all strongly about this. If people accept
'virtual out of band', I certainly don't object.

Regards
    Brian
    (via tiny screen & keyboard)

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jun 2020 18:12:32 +0200

Thanks to everbody chiming in for "virtual out of band" ;-)
I would have hated anything with "overlay", i think Arthur correctly described it with "blind"

-- 
---
[email-masked]