Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt
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" On Tue, Jun 30, 2020 at 09:27:30PM +1200, Brian Carpenter wrote: > 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) > > On Tue, 30 Jun 2020, 18:27 Michael H. Behringer, < > michael.h.behrin...@gmail.com> wrote: > > > 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 > > > > On 30/06/2020 00:06, Brian E Carpenter wrote: > > > 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 > > > > > > On 30-Jun-20 00:45, William Atwood wrote: > > >> 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 > > >>> On 2020-06-23 10:31 p.m., internet-dra...@ietf.org wrote: > > A diff from the previous version is available at: > > > > >>> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 > > >>> > > >>> > > >>> 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. > > >>> > > >>> ___ > > >>> Anima mailing list > > >>> Anima@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/anima > > >>> > > > ___ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > ___ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt
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) On Tue, 30 Jun 2020, 18:27 Michael H. Behringer, < michael.h.behrin...@gmail.com> wrote: > 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 > > On 30/06/2020 00:06, Brian E Carpenter wrote: > > 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 > > > > On 30-Jun-20 00:45, William Atwood wrote: > >> 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 > >>> On 2020-06-23 10:31 p.m., internet-dra...@ietf.org wrote: > A diff from the previous version is available at: > > >>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 > >>> > >>> > >>> 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. > >>> > >>> ___ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >>> > > ___ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt
Hi, Am 30.06.20 um 08:27 schrieb Michael H. Behringer: > 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. > 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. Regards Roland > Michael > > On 30/06/2020 00:06, Brian E Carpenter wrote: >> 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 >> >> On 30-Jun-20 00:45, William Atwood wrote: >>> 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 On 2020-06-23 10:31 p.m., internet-dra...@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 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. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt
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 On Behalf Of Michael H. Behringer > Sent: Tuesday, June 30, 2020 8:27 AM > To: anima@ietf.org > Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP- > number comments on Action: draft-ietf-anima-autonomic-control-plane- > 25.txt > > 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 > > On 30/06/2020 00:06, Brian E Carpenter wrote: > > 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 > > > > On 30-Jun-20 00:45, William Atwood wrote: > >> 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 On 2020-06-23 10:31 p.m., internet-dra...@ietf.org wrote: > A diff from the previous version is available at: > > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control > >>> -plane-25 > >>> > >>> > >>> 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. > >>> > >>> ___ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >>> > > ___ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt
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 On 30/06/2020 00:06, Brian E Carpenter wrote: 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 On 30-Jun-20 00:45, William Atwood wrote: 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 On 2020-06-23 10:31 p.m., internet-dra...@ietf.org wrote: A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 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. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt
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 On 30-Jun-20 00:45, William Atwood wrote: > 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 >> On 2020-06-23 10:31 p.m., internet-dra...@ietf.org wrote: >>> A diff from the previous version is available at: >>> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 >> >> >> 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. >> >> ___ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt
Thanks, Michael, inline On Sun, Jun 28, 2020 at 11:02:13PM -0400, Michael Richardson wrote: > On 2020-06-23 10:31 p.m., internet-dra...@ietf.org wrote: > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 > > 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. 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. > > I actually do want to start a bike-shed issue here? 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. > Or at least needs a better copy-edit. 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 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt
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 > On 2020-06-23 10:31 p.m., internet-dra...@ietf.org wrote: >> A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25 > > > 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. > > ___ > Anima mailing list > Anima@ietf.org > 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:william.atw...@concordia.ca 1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
