from:"Michael H. Behringer"

Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt

2020-06-29 Thread Michael H. Behringer


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] Brian/anima: trust notion of ASA communications

2020-02-10 Thread Michael H. Behringer


On 08/02/2020 20:05, Brian E Carpenter wrote:

On 08-Feb-20 23:36, Michael H. Behringer wrote:

Brian, I'm not sure I understand your phrase "the private key will be
scattered around the autonomic domain." Are you suggesting to create a
key pair for a role, and if several nodes have the same role, they will
have the same private key?!? That strikes me as very unusual...

Yes. But if you're a network operator, you're very pragmatic and if you have
an updated binary of an ASA that you need to install on 500 nodes, you won't 
want
to add a complex key management task to the installation.

Indeed it's bad security to share a key. I just think that it will happen, if
we propose an alternative that is perhaps as complex as BRSKI itself but is
applied at the ASA level instead of the node level.
OK, I think we agree: let's make sure that doesn't happen! :-)   In any 
case, if the goal is to prevent a potential hacker to spin up any ASA on 
a hacked node, then a key delivered with the ASA won't do the job, 
right? Because that could potentially be found on another hacked node, 
and copied as well.


We need to first define the problem statement precisely. (Maybe it's 
just me who doesn't have it clear?)


The problem is that a node runs an ASA which it shouldn't. Right?

There is however more than one way to get to this situation:
1) A node may be hacked, have all sorts of ASAs installed manually by 
the hacker, and use those in ways not intended by the operator. 
("malicious case")
2) Autonomic nodes may well decide by themselves to run certain 
functions if needed. ("Erroneous case")


I agree with Toerless: The concept with a special bit in the certificate 
isn't all that bad. If it's a pretty static function, it's perfectly 
appropriate. (Like a diplomatic passport). Let's not throw this out.


As Toerless said: "crowd intelligence based on client measured service 
performance experience" would be a solution to the 2nd case. But that's 
to me for further study, not a short-term goal. And that may well be 
different for different types of ASA.


The middle way would be a centrally controlled directory, that nodes can 
query. Needs more thinking. Do we want to check permissions for all 
types of ASAs? How long can you cache permissions? Do we want to define 
different "security levels" of ASAs, to distinguish between "to be 
checked at each usage" and "trust crowd intelligence" and "trust 
implicitly"? Should we just re-use an existing scheme for that? (AAA?) 
This isn't going to happen in a rush...


Michael





I think we're back to really old concepts of security:

A node has an identity and a role. The identity is proven by a
certificate. The role (ex: Prefix Manager) is assigned to an identity.
And a role may require a specific ASA to fulfil its function.

Make that plural. A node may have mutltiple roles and a role may
multiple ASAs.

Yes. The word "a" was not meant as an enumeration.

As Toerless points out, we CAN (and do) assign roles statically in a
certificate. In the "real" world a diplomatic passport is exactly that:
It's an identity of a person, plus a role (diplomat). But that only
makes sense for fairly static roles, and I would not suggest that for
things like Prefix Manager.

There are two alternatives:
1 - We come up with a consensus model (see Toerless' mail). In a
distributed model such as ANI very interesting, but I think needs a lot
more work. Much more common though:

2 - We maintain a directory (read: a secured database), where we assign
roles to identities. This is "normal" in standard security. Role based
access control for example, Active Directory, etc.

I would vote for a directory type of solution at first. This way an
administrator can assign and change roles quite easily. Later we can
look into consensus models.

I agree entirely, but it wasn't obvious that Toerless was heading in that
direction.
  

I'd need a lot more convincing that certificates for roles (or ASAs) are
a good idea. And shared private keys (actually: Contradiction in terms,
I probably misunderstood Brian there) definitely not.

Again, I agree. I was simply speculating about what I expect operators would
do if presented with too much complexity.

 Brian


Michael


On 08/02/2020 00:04, Brian E Carpenter wrote:

On 08-Feb-20 03:58, Toerless Eckert wrote:


Sure, and i am going to run a hacked ACP node thats announcing in GRASP
to be the "best-ever" node to provide that service ;-) How to you
prohibit me to happen ? -> Anser: i dont have a fitting certificate, or
there is some ACP crowd intelligence that says i am untrustworthy.

I don't see how you can get away from asymmetric crypto to do that. An ASA
comes up and says 'I support "DANGER"', which

Re: [Anima] Brian/anima: trust notion of ASA communications

2020-02-08 Thread Michael H. Behringer

Brian, I'm not sure I understand your phrase "the private key will be 
scattered around the autonomic domain." Are you suggesting to create a 
key pair for a role, and if several nodes have the same role, they will 
have the same private key?!? That strikes me as very unusual...


I think we're back to really old concepts of security:

A node has an identity and a role. The identity is proven by a 
certificate. The role (ex: Prefix Manager) is assigned to an identity. 
And a role may require a specific ASA to fulfil its function.


As Toerless points out, we CAN (and do) assign roles statically in a 
certificate. In the "real" world a diplomatic passport is exactly that: 
It's an identity of a person, plus a role (diplomat). But that only 
makes sense for fairly static roles, and I would not suggest that for 
things like Prefix Manager.


There are two alternatives:
1 - We come up with a consensus model (see Toerless' mail). In a 
distributed model such as ANI very interesting, but I think needs a lot 
more work. Much more common though:


2 - We maintain a directory (read: a secured database), where we assign 
roles to identities. This is "normal" in standard security. Role based 
access control for example, Active Directory, etc.


I would vote for a directory type of solution at first. This way an 
administrator can assign and change roles quite easily. Later we can 
look into consensus models.


I'd need a lot more convincing that certificates for roles (or ASAs) are 
a good idea. And shared private keys (actually: Contradiction in terms, 
I probably misunderstood Brian there) definitely not.


Michael


On 08/02/2020 00:04, Brian E Carpenter wrote:

On 08-Feb-20 03:58, Toerless Eckert wrote:


Sure, and i am going to run a hacked ACP node thats announcing in GRASP
to be the "best-ever" node to provide that service ;-) How to you
prohibit me to happen ? -> Anser: i dont have a fitting certificate, or
there is some ACP crowd intelligence that says i am untrustworthy.

I don't see how you can get away from asymmetric crypto to do that. An ASA
comes up and says 'I support "DANGER"', which is a GRASP objective for doing
something very dangerous. Take a concrete example: 'I support "PrefixManager"',
which is defined in draft-ietf-anima-prefix-management and will be in an
RFC one day soon. So this ASA needs to be trusted to allocate or assign
IP address space.

How can we check this is OK? As far as I can see, only if we have previously
decided to trust any PrefixManager ASA that can prove possession of a given
private key, or more precisely one of a given set of private keys.

In practical reality, I'm sure operators will want to install identical
binaries of a given ASA on multiple autonomic nodes. So the private key
will be scattered around the autonomic domain. My guess is that a lot of
operators would not see this as any better than just trusting the nodes,
not the individual ASAs.

 Brian


___
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] Fwd: New Version Notification for draft-ietf-anima-reference-model-10.txt

2018-11-22 Thread Michael H. Behringer


This version addresses one review comment from Deborah Brungard.

Michael


 Forwarded Message 
Subject: 	New Version Notification for 
draft-ietf-anima-reference-model-10.txt

Date:   Thu, 22 Nov 2018 23:48:20 -0800
From:   internet-dra...@ietf.org
To: 	anima-cha...@ietf.org, Michael H. Behringer 
, Jeferson Campos Nobre 
, Laurent Ciavaglia , 
Laurent Ciavaglia , Michael Behringer 
, Toerless Eckert , Brian 
Carpenter , Jeferson Nobre 





A new version of I-D, draft-ietf-anima-reference-model-10.txt
has been successfully submitted by Michael H. Behringer and posted to the
IETF repository.

Name:   draft-ietf-anima-reference-model
Revision:   10
Title:  A Reference Model for Autonomic Networking
Document date:  2018-11-23
Group:  anima
Pages:  30
URL:
https://www.ietf.org/internet-drafts/draft-ietf-anima-reference-model-10.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/
Htmlized:   https://tools.ietf.org/html/draft-ietf-anima-reference-model-10
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-10

Abstract:
   This document describes a reference model for Autonomic Networking
   for managed networks.  It defines the behaviour of an autonomic node,
   how the various elements in an autonomic context work together, and
   how autonomic services can use the infrastructure.

  



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.

The IETF Secretariat

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Fwd: New Version Notification for draft-ietf-anima-reference-model-09.txt

2018-11-06 Thread Michael H. Behringer


This new version addresses the comments received by the IESG.

We believe that all outstanding comments have been addressed, and that 
the document is ready for publication.


Michael


 Forwarded Message 
Subject: 	New Version Notification for 
draft-ietf-anima-reference-model-09.txt

Date:   Tue, 06 Nov 2018 00:55:15 -0800
From:   internet-dra...@ietf.org
To: 	anima-cha...@ietf.org, Michael H. Behringer 
, Jeferson Campos Nobre 
, Laurent Ciavaglia , 
Laurent Ciavaglia , Michael Behringer 
, Toerless Eckert , Brian 
Carpenter , Jeferson Nobre 





A new version of I-D, draft-ietf-anima-reference-model-09.txt
has been successfully submitted by Michael H. Behringer and posted to the
IETF repository.

Name:   draft-ietf-anima-reference-model
Revision:   09
Title:  A Reference Model for Autonomic Networking
Document date:  2018-11-06
Group:  anima
Pages:  30
URL:
https://www.ietf.org/internet-drafts/draft-ietf-anima-reference-model-09.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/
Htmlized:   https://tools.ietf.org/html/draft-ietf-anima-reference-model-09
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-09

Abstract:
   This document describes a reference model for Autonomic Networking
   for managed networks.  It defines the behaviour of an autonomic node,
   how the various elements in an autonomic context work together, and
   how autonomic services can use the infrastructure.

  



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.

The IETF Secretariat

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

2018-10-25 Thread Michael H. Behringer


On 25/10/2018 14:01, Alissa Cooper wrote:

--
COMMENT:
--

Since draft-ietf-anima-bootstrapping-keyinfra is a normative reference in this
document, IDevID seems like it should be as well. That is, it seems to be used
in a normative way in the same manner as the other normative references in this
document. If the document were not going to have any normative references, then
I think IDevID could be informative.


I have no problem moving IDevID to the normative references. In 
draft-ietf-anima-bootstrapping-keyinfra it is also in the normative 
section, so it would make sense to do this here as well.


Will do. (Unless I hear an objection)

Michael

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

2018-10-25 Thread Michael H. Behringer

On 25/10/2018 05:21, Spencer Dawkins at
  IETF wrote:

  Hi, Brian,

On Wed, Oct 24, 2018 at 10:16 PM Brian E
  Carpenter 
  wrote:

Hi
  Spencer,
  On 2018-10-25 15:54, Spencer Dawkins wrote:
  ...

  >
  --
  > COMMENT:
  >
  --
  > 
  > I'm confused here ...
  > 
  >   This document describes a first, simple,
  implementable phase of an
  >    Autonomic Networking solution.  It is expected
  that the experience
  >    from this phase will be used in defining updated
  and extended
  >    specifications over time.  Some topics are
  considered architecturally
  >    in this document, but are not yet reflected in the
  implementation
  >    specifications.  They are marked with an (*).
  > 
  > This is true now, but when this document is approved,
  will it be published
  > immediately (in which case, this is "truth decay",
  because it becomes less true
  > in the unchanging RFC every time a topic is reflected
  in implementation
  > specifications), or will it be held until all the
  (*)s are stable?

  The intention is to publish it now; the (*) items are FFS
  (for further study)
  in ITU or ISO speak. Should we make the last sentence
  explicit?:

  They are marked with an (*) and are intended for further
  study.

Thanks for the quick reply. 

I think that would be an improvement, but if it was
  clear that there's a reason to include them in a document
  being published now, that might be useful to include. 

If it's possible that some of these items might be
  significantly re-thought after further study, or even
  dropped, that seems unhelpful to a reader in five years. 

Thanks for the thoughts, Spencer. I sort of see that we might end up
with a situation where one of those (*) topics completely disappears
in 5 years, in which case it might indeed look odd. 

However, the RFCs come with a publication date. I think it'll then
be clear that 5 years ago, we were thinking in a different
direction, but that over time, the views changed. 

Personally, I find it very interesting to read in older documents
why certain things were done or not done, considered or not
considered, even if things change later on. 

So, I would trust the future reader to understand that this is
context at the time of publishing the RFC, and might have changed
since. And I think we could well live with that. My suggestion:
Leave. 

Michael

Spencer

     Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

2018-10-25 Thread Michael H. Behringer

Ah, now I understand. Thanks for clarifying. Yes, we really used it as
sort of a "boiler plate" for topics that are not part of this phase of
ANIMA work. I guess we just introduced (informational)^2.

I'm happy to change that "boiler plate" text. What about "This section
discusses a topic for further research".

I guess we can edit that when we get to the RFC Editor queue.

Michael

On 25/10/2018 17:18, Ben Campbell wrote:

Hi Michael,

My real concern is that “informational” is a term of art in the IETF, and the
use of it to label “later phase” sections is a different use than that.

I will leave it to the authors to decide if that would be confusing to the
target audience.

Thanks!

Ben.

On Oct 25, 2018, at 3:43 AM, Michael H. Behringer
wrote:

Hi Ben, thanks for your review!

Yes, we're a bit "verbose" with those topics. There was a consistent worry all through
our work to distinguish phase 1 and phase 2 work, and to not let phase 2 work creep into phase 1.
So we probably erred on the more "explicit" wording, trying to make REALLY sure everybody
understands what's in scope for phase 1 or not.

Unless you have a real concern at some specific points, I would prefer to not
open those debates again. Yes, from a language point of view there is
redundancy, but at least we're being very clear.

Michael

On 25/10/2018 04:33, Ben Campbell wrote:

On Oct 24, 2018, at 8:10 PM, Brian E Carpenter
wrote:

Hi Ben,

On 2018-10-25 12:08, Ben Campbell wrote:

Thanks for the work on this. I just have one editorial comment:

- Several sections describe themselves as being for "informational purposes".
Given that this is an informational document, isn't that true of all sections?

Those sections are among the ones tagged (*) as per:

Some topics are considered architecturally
in this document, but are not yet reflected in the implementation
specifications. They are marked with an (*).

Possibly the (*) is sufficient and the phrase you mention can be removed.

I think that could help. Or alternatively, put a few extra words in the (*)
sections to remind people what it means :-)

Thanks!

Ben.

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

2018-10-25 Thread Michael H. Behringer


Hi Ben, thanks for your review!

Yes, we're a bit "verbose" with those topics. There was a consistent 
worry all through our work to distinguish phase 1 and phase 2 work, and 
to not let phase 2 work creep into phase 1. So we probably erred on the 
more "explicit" wording, trying to make REALLY sure everybody 
understands what's in scope for phase 1 or not.


Unless you have a real concern at some specific points, I would prefer 
to not open those debates again. Yes, from a language point of view 
there is redundancy, but at least we're being very clear.


Michael


On 25/10/2018 04:33, Ben Campbell wrote:



On Oct 24, 2018, at 8:10 PM, Brian E Carpenter  
wrote:

Hi Ben,

On 2018-10-25 12:08, Ben Campbell wrote:



Thanks for the work on this. I just have one editorial comment:

- Several sections describe themselves as being for "informational purposes".
Given that this is an informational document, isn't that true of all sections?

Those sections are among the ones tagged (*) as per:


   Some topics are considered architecturally
   in this document, but are not yet reflected in the implementation
   specifications.  They are marked with an (*).

Possibly the (*) is sufficient and the phrase you mention can be removed.

I think that could help. Or alternatively, put a few extra words in the (*) 
sections to remind people what it means :-)

Thanks!

Ben.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Fwd: I-D Action: draft-ietf-anima-reference-model-08.txt

2018-10-04 Thread Michael H. Behringer


  
  
ANIMA chairs, Christian, 
  
  This new version addresses the comments made in the RTGDIR review
  of Christian Hopps. Other comments were addressed in previous
  versions of the document. 
  
  Christian, could you please review, and see if there are any open
  issues that we overlooked? If not, could you please clear the
  "issues" flag? 
  
  We haven't received any further comments in the Last Call. I
  believe the document is ready for publication. 


  Thanks, 
  Michael
  
  
   Forwarded Message 
  

  
Subject:

[Anima] I-D Action:
  draft-ietf-anima-reference-model-08.txt
  
  
Date: 
Thu, 04 Oct 2018 00:07:53 -0700
  
  
From: 
internet-dra...@ietf.org
  
  
Reply-To:

anima@ietf.org
  
  
To: 
i-d-annou...@ietf.org
  
  
CC: 
anima@ietf.org
  

  
  
  
  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   : A Reference Model for Autonomic Networking
Authors         : Michael H. Behringer
  Brian Carpenter
  Toerless Eckert
  Laurent Ciavaglia
  Jeferson Campos Nobre
	Filename: draft-ietf-anima-reference-model-08.txt
	Pages   : 30
	Date: 2018-10-04

Abstract:
   This document describes a reference model for Autonomic Networking
   for managed networks.  It defines the behaviour of an autonomic node,
   how the various elements in an autonomic context work together, and
   how autonomic services can use the infrastructure.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-reference-model-08
https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-08


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/

___
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] Rtgdir telechat review of draft-ietf-anima-reference-model-07

2018-08-30 Thread Michael H. Behringer


On 30/08/2018 04:06, Brian E Carpenter wrote:

On 2018-08-29 22:39, Michael H. Behringer wrote:

Christian, thanks for the review, my comments inline...

On 26/08/2018 22:57, Brian E Carpenter wrote:

(Ccs trimmed)

Christian,

Thanks for this careful review. I'll comment here on the larger issues:

On 2018-08-27 04:03, Christian Hopps wrote:
...

Minor Major Issues:

- Virtualization is mentioned once in "4.2 addressing" section. To quote:

TEXT: "Support for virtualization: Autonomic Nodes may support Autonomic
Service Agents in different virtual machines or containers. The addressing
scheme should support this architecture."

The special casing of VM/containers here seems to indicate that virtual
devices are not "1st class citizens" in an autonomic network. In particular 
I
could easily imagine virtual machines being full blown autonomic nodes
themselves. Assuming the intent is not to restrict virtual devices in this
manor something needs to be said (somewhere) to make that clear.

I don't think that was the intention. We haven't really explored this in detail,
but I can certainly imagine a deployment (for example) where each tenant in
a data centre has its own virtual autonomic network, and the underlying physical
network is also autonomic. Since the ACP is expected to be implemented as
a VRF, you could even argue that every autonomic network is virtual.

So, yes, we can reword this.

To add to Brian: I agree there was no intention to "downgrade"
virtualization. Nor am I aware of any text that indicates that, also not
what you quote above. We didn't mean this to say "this is not
recommended", only "we haven't explored / documented that further". I am
convinced that the Autonomic architecture will be all over data centers
one day, so OBVIOUSLY virtualization is important.

Happy to re-word, but: What do you suggest we change / add? I'm really
not clear...

A modest suggestion, on the basis that if Christian read the text differently
from the authors' intentions, other people might do so as well.

Support for virtualization: Autonomic functions can exist either at the
level of the physical network and physical devices, or at the level
of virtual machines, containers and networks. In particular, Autonomic
Nodes may support Autonomic Service Agents in virtual entities. The
infrastructure, including the addressing scheme, should be able to
support this architecture.

(Comment: it isn't just addressing. There are software design
implications too, but that is out of scope here, I think.)


OK, sounds good. I'll change that.

I wait for potential further last call comments before making the 
changes and publishing a new version.


Michael

[rest deleted]

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Rtgdir telechat review of draft-ietf-anima-reference-model-07

2018-08-29 Thread Michael H. Behringer


Christian, thanks for the review, my comments inline...

On 26/08/2018 22:57, Brian E Carpenter wrote:

(Ccs trimmed)

Christian,

Thanks for this careful review. I'll comment here on the larger issues:

On 2018-08-27 04:03, Christian Hopps wrote:
...

Minor Major Issues:

- Virtualization is mentioned once in "4.2 addressing" section. To quote:

   TEXT: "Support for virtualization: Autonomic Nodes may support Autonomic
   Service Agents in different virtual machines or containers. The addressing
   scheme should support this architecture."

   The special casing of VM/containers here seems to indicate that virtual
   devices are not "1st class citizens" in an autonomic network. In particular I
   could easily imagine virtual machines being full blown autonomic nodes
   themselves. Assuming the intent is not to restrict virtual devices in this
   manor something needs to be said (somewhere) to make that clear.

I don't think that was the intention. We haven't really explored this in detail,
but I can certainly imagine a deployment (for example) where each tenant in
a data centre has its own virtual autonomic network, and the underlying physical
network is also autonomic. Since the ACP is expected to be implemented as
a VRF, you could even argue that every autonomic network is virtual.

So, yes, we can reword this.


To add to Brian: I agree there was no intention to "downgrade" 
virtualization. Nor am I aware of any text that indicates that, also not 
what you quote above. We didn't mean this to say "this is not 
recommended", only "we haven't explored / documented that further". I am 
convinced that the Autonomic architecture will be all over data centers 
one day, so OBVIOUSLY virtualization is important.


Happy to re-word, but: What do you suggest we change / add? I'm really 
not clear...





- Robust programming techniques. I think the intention here is to say that the
   design of ASAs must have robustness as a top design principle. I think in
   doing that it should talk about what being robust means; however, it should
   not be talking about how to accomplish that as there are multiple ways to
   achieve this goal.

   In particular I feel saying that restarting is the *last* thing an ASA should
   do is way overreaching into engineering the solution rather than specifying
   the requirement. Indeed plenty of people think that overly complex recovery
   mechanisms that try everything under the sun to *not* restart often have more
   bugs and are less robust than KISS solutions that "fail" simply but recover
   quickly with minimal or no disruption.

   I feel this section reads a bit more like someones idea of how to design a
   robust system instead of talking about what robust means which is the intent 
I
   believe.

   Perhaps better is just to focus on robust design ideas (some are already
   stated in the text):

   - must deal with discovery and negotiation failure as routine.
   - recovering from failures should be minimally disruptive.
   - must not leak resources.
   - must monitor for and deal with hung code.
   - must include security analysis

OK. Since I drafted that text, I will leave the document editor to fix
it. (Some of the detail probably belongs in another draft specifically
about ASAs, which I am editing.)


Brian: Haha, that's called "passing on the ball" I believe... :-)
Christian: With your input above, I suggest to reword that paragraph to:

Since autonomic systems must be self-repairing, it is of great 
importance that ASAs are
coded using robust programming techniques. All run-time error conditions 
must be caught,
leading to suitable >>> minimally disruptive <<< recovery actions, >>> 
also considering a complete restart of the ASA.<<<


The other bullets are covered in the text.




- 7.4: When text talks about feedback loop, it mentions "allow the intervention"
   of human admin or control system; however, it then describes the feedback 
loop
   as presenting default actions and allowing for override. This is fine, but it
   seems to leave out the common case where something is misbehaving and would
   not be presenting any choices to the administrator (using the feedback loop),
   so the admin must forcefully intervene.

Yes. I think the word "feedback" is a bad choice. For engineers raised on
Nyquist diagrams it is part of a closed loop; for other people it means
feedback to humans. The text needs clarifying.
Christian: Right. I think this may be clearer when we distinguish (more 
explicitly than is the case now) that there are two different systems 
involving the NOC:


1 - a closed loop, called feedback loop at the moment.
2 - a unidirectional error message.

1 works like this: Node detects abnormal condition, informs NOC "here is 
what I see, I will take recovery X at time Y to resolve this". The NOC 
can then do nothing, or override this action.


2 is a simple report, with no suggestion what to do, and no default 
recovery action. It's the NOC engineer's job

[Anima] Fwd: I-D Action: draft-ietf-anima-reference-model-07.txt

2018-08-24 Thread Michael H. Behringer


  
  
This new version addresses all the comments received
  since the last call. It includes the SECDIR, GENART and OPSDIR
  reviews, but we're still awaiting the RTGDIR review. 
  
  Michael

   Forwarded Message 
  

  
Subject:

[Anima] I-D Action:
  draft-ietf-anima-reference-model-07.txt
  
  
Date: 
Fri, 24 Aug 2018 07:57:30 -0700
  
  
From: 
internet-dra...@ietf.org
  
  
Reply-To:

anima@ietf.org
  
  
To: 
i-d-annou...@ietf.org
  
  
CC: 
anima@ietf.org
  

  
  
  
  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   : A Reference Model for Autonomic Networking
Authors     : Michael H. Behringer
  Brian Carpenter
  Toerless Eckert
  Laurent Ciavaglia
  Jeferson Campos Nobre
	Filename: draft-ietf-anima-reference-model-07.txt
	Pages   : 30
	Date: 2018-08-24

Abstract:
   This document describes a reference model for Autonomic Networking
   for managed networks.  It defines the behaviour of an autonomic node,
   how the various elements in an autonomic context work together, and
   how autonomic services can use the infrastructure.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-reference-model-07
https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-07


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/

___
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] Michael: Nit suggestion for draft-ietf-anima-reference-model

2018-07-10 Thread Michael H. Behringer


Hi Toerless, thanks for the feedback.

No problem with me, I'll move contributors before acknowledgements 
(makes sense). Personally I have no problem adding email addresses 
behind contributors, will need to check with everybody which email 
address they want listed.


Are other ID editors doing the same thing? Just, if we're the first to 
do that, maybe we should check with our AD that this is ok?


Michael


On 10/07/2018 04:06, Toerless Eckert wrote:

(not sure which hat i should wear for this email ... i guess it
mostly my personal opinion):

Michael (dear editor)

One nit fix suggestion for whenever you'll do a rev because of IESG feedback:

I have just noticed that some tooling, at least from Jari 
(http://www.arkko.com/tools/allstats)
is also taking contributors into account when listing RFCs. Datatracker does not
(yet) do this, but i want to suggest it to them given how i feel that its
valuable to more explicitly givecredit to the contributor status (aka:
list RFCs someone contributed to on their datatracker personal page).

Wrt. to the anima reference model: If would be good if you
could put the email address of each contributor in parenthesis behind the
contributors name. This should help any parsing tool trying to identify/
match contributors. Also, please move the contributors
section before the Acknowledgements section - unless you disagree that
thats the more appropriate order.

Thanks!
 toerless


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Call for agenda ANIMA @ IETF 101, London

2018-03-07 Thread Michael H. Behringer


OK - will do it :-)

On 07/03/18 02:56, Sheng Jiang wrote:

Hi, Michael,

Even the draft would be with IETF, it is needed to report the changes to WG 
since the last report. 10 mins is fine, remote report is fine, too.

Regards,

Sheng

-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Michael H. Behringer
Sent: Wednesday, March 7, 2018 4:47 AM
To: anima@ietf.org
Subject: Re: [Anima] Call for agenda ANIMA @ IETF 101, London

Hi Sheng,

Not sure we need a slot for the reference model. I guess it should now go to 
the IESG, right?

Up to you. If we have time, I could do a short 10 min update. I won't be in 
person in London, but can present remotely.

Michael


On 28/02/18 06:56, Sheng Jiang wrote:

Hi, all anima,
We have been allocated a session of 2.5-hour for the ANIMA WG meeting
for IETF-101 (London) and are starting to collect agenda items for the
session. Please send your request for agenda by March 8th, Thursday.
Giving that most of our chartered work items have been sent to IESG
for publication by the meeting, we expect short time slots for only
two or three of them. For this coming meeting, we would like to
discuss potential future ANIMA works.
As normal, the priority among these non-charter work items would be:
these that have active discussion in mail list, then these have
submitted drafts, and topics without drafts.
Please send us (anima-chairs at ietf.org<https://ietf.org/>
<http://ietf.org%3Chttps/ietf.org/%3E%29>;) requests for time slot by
March 8th, Thursday and include:
Name of time slot:
Name of draft(s):
Time requested:
Presenter name(s):
More details about the IETF 101, London can be found at:
http://www.ietf.org/meeting/101/index.html
Again, presenters and draft authors please invoke active discussions
in the ANIMA list. Mail list is a very good place to discuss and reach
consensus on technical issues.
Best regards,
Toerless & Sheng



___
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] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

2018-03-06 Thread Michael H. Behringer


Inline...

On 28/02/18 15:36, Sheng Jiang wrote:

Hi Michael,

Thanks for addressing my review comments. Below in lines for my further 
comments regarding to several points. None of them are major. So, I will start 
my document shepherd based on the current 06 version. It is up to you to do a 
quick update soon or addressing them together with the IESG review comments, 
which I am sure will have.

Regards,

Sheng


-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Michael H.
Behringer
Sent: Friday, February 23, 2018 9:10 PM
To: Sheng Jiang ; anima@ietf.org
Cc: anima-cha...@ietf.org
Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-
reference-model-05 - Respond by January 22nd, 2018

On 18/01/18 09:59, Sheng Jiang wrote:

Hi, authors of anima-reference-model,

I have reviewed the draft as the document shepherd, see below
comments. Overall, I feel this document is very useful and it is
almost ready for be published. Please properly address my comments
together with other WGLC comments you may receive. Another revised
version of the document is needed to process the document further if
it passed the WGLC.


Hi Sheng,

First of all thanks for the thorough review. I am now finished with
working your comments into the draft. I am just publishing version -06.

This version should address all your comments. I am not aware of any
other outstanding comments, and believe we have addressed all open issues now.

Details below in line.

Michael


General issues:

1. In section 3.1, it says “The Autonomic Control Plane (ACP) is the
summary of all interactions of the Autonomic Networking
Infrastructure with other nodes and services.” I’m a bit confused by this 
statement.
In my understanding, the ACP itself is mostly a “channel”, although
some ANI functions (signaling, aggregated reporting etc.) are
running within the channel, they should be parallel with ACP
function in the architecture view.

At the same time, there are indeed some functions considered as
sub-functions of the ACP, e.g. the addressing and routing, which are
necessary to make the ACP runnable.

So, my questions to the co-authors:

1) Do you see ACP as an individual function as I understood (mostly
a channel), or a summary of a suite of functions running inside the ACP?

2) What functions are sub-functions of ACP, and what are in parallel
with ACP?


There are really two meanings to the term "ACP". This has caused quite
some confusion, and I agree it needs to be nailed once and for all.
Thanks for raising it here.

1) The general term "control plane" refers to the sum of all protocols
that control network behaviour. Like, in a traditional network, routing 
protocols, etc.
Consequently, an "Autonomic Control Plane" is the sum of all protocols
that controls the behaviour of an autonomic network. In
draft-ietf-anima-stable- connectivity we now use the term "Generalized ACP" for 
this abstract concept.

2) In the ANIMA context, we use the term "ACP" also to describe a very
specific implementation of the generic concept of an "Autonomic Control Plane".

I now cleared up the naming in the reference draft. Where we mean the
abstract concept (3.1 for example), I now use "GACP", where we mean
the implementation, I now use "ACP" and refer to the ACP draft.

Specifically, I changed in 3.1 from ACP to GACP. And re-worded section
4.6, which is all about the implementation of the ACP.

[Sheng] My original comment implied two aspects:
1. As you explained, the "General" control plane vs. the "specific" 
implementation (ACP). So, as I understood, the ACP is an instance of GACP. I have no problem on 
this.
2. The specific ACP actually serves as a management channel for the underlay network, in this 
sense, the ACP could be seen as a "management plane" for the underlay network; in other 
words, the ACP is a "Virtual DCN(Data communication network)". Thus, there could be a 
summary of management functions running inside the ACP, and this summary doesn't belong to ACP 
itself. If you agree with it, I think this also needs to be clarified.


Yes, of course I agree with it! :-)  I'm however worried that this will 
confuse readers a lot. I suggest in this document to stick to the 
autonomic aspect of the ACP only. And in section 4.6 we already say "See 
[I-D.ietf-anima-stable-connectivity 
<https://tools.ietf.org/html/draft-ietf-anima-reference-model-06#ref-I-D.ietf-anima-stable-connectivity>] 
for uses cases for the ACP." which describes in detail what you're 
saying above. I suggest we leave it with this in the reference model.



2. I’m confused by the whole purpose of Section 3. The first
sub-clause is describing the architecture of an Autonomic Network
Element, while the rest sub-clauses (adjacency table, state machine
etc.) seems more like “implementation consideration

Re: [Anima] Call for agenda ANIMA @ IETF 101, London

2018-03-06 Thread Michael H. Behringer


Hi Sheng,

Not sure we need a slot for the reference model. I guess it should now 
go to the IESG, right?


Up to you. If we have time, I could do a short 10 min update. I won't be 
in person in London, but can present remotely.


Michael


On 28/02/18 06:56, Sheng Jiang wrote:

Hi, all anima,
We have been allocated a session of 2.5-hour for the ANIMA WG meeting 
for IETF-101 (London) and are starting to collect agenda items for the 
session. Please send your request for agenda by March 8th, Thursday.
Giving that most of our chartered work items have been sent to IESG 
for publication by the meeting, we expect short time slots for only 
two or three of them. For this coming meeting, we would like to 
discuss potential future ANIMA works.
As normal, the priority among these non-charter work items would be: 
these that have active discussion in mail list, then these have 
submitted drafts, and topics without drafts.
Please send us (anima-chairs at ietf.org 
;) requests for time slot by 
March 8th, Thursday and include:

Name of time slot:
Name of draft(s):
Time requested:
Presenter name(s):
More details about the IETF 101, London can be found at:
http://www.ietf.org/meeting/101/index.html
Again, presenters and draft authors please invoke active discussions 
in the ANIMA list. Mail list is a very good place to discuss and reach 
consensus on technical issues.

Best regards,
Toerless & Sheng



___
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] "professionally managed" and the reference model

2018-02-27 Thread Michael H. Behringer

In principle I'm happy with that, and I agree that it would be a good 
idea. However, I hope we can avoid another WGLC with this change? (Sheng?)


Looking...

Actually, the intro has this paragraph, which I think pretty much covers 
this case:


   As discussed in [RFC7575], the goal of this work is not to focus
   exclusively on fully autonomic nodes or networks.  In reality, most
   networks will run with some autonomic functions, while the rest of
   the network is traditionally managed.  This reference model allows
   for this hybrid approach.

Isn't that even a better description than "professionally managed", 
which has itself raised a lot of questions?


My vote for now: We're good! No changes needed.

Michael



On 26/02/18 22:21, Brian E Carpenter wrote:

While looking at Pascal's ACP review, I noticed that although ANIMA
scope is limited by charter to "professionally managed" networks,
we do not mention that scope in draft-ietf-anima-reference-model.
It seems like something to be added to the Introduction.

Comments?

Regards
Brian Carpenter


___
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] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

2018-02-23 Thread Michael H. Behringer


On 18/01/18 09:59, Sheng Jiang wrote:


Hi, authors of anima-reference-model,

I have reviewed the draft as the document shepherd, see below 
comments. Overall, I feel this document is very useful and it is 
almost ready for be published. Please properly address my comments 
together with other WGLC comments you may receive. Another revised 
version of the document is needed to process the document further if 
it passed the WGLC.




Hi Sheng,

First of all thanks for the thorough review. I am now finished with 
working your comments into the draft. I am just publishing version -06.


This version should address all your comments. I am not aware of any 
other outstanding comments, and believe we have addressed all open 
issues now.


Details below in line.

Michael


General issues:

1. In section 3.1, it says “The Autonomic Control Plane (ACP) is the 
summary of all interactions of the Autonomic Networking Infrastructure 
with other nodes and services.” I’m a bit confused by this statement. 
In my understanding, the ACP itself is mostly a “channel”, although 
some ANI functions (signaling, aggregated reporting etc.) are running 
within the channel, they should be parallel with ACP function in the 
architecture view.


At the same time, there are indeed some functions considered as 
sub-functions of the ACP, e.g. the addressing and routing, which are 
necessary to make the ACP runnable.


So, my questions to the co-authors:

1) Do you see ACP as an individual function as I understood (mostly a 
channel), or a summary of a suite of functions running inside the ACP?


2) What functions are sub-functions of ACP, and what are in parallel 
with ACP?




There are really two meanings to the term "ACP". This has caused quite 
some confusion, and I agree it needs to be nailed once and for all. 
Thanks for raising it here.


1) The general term "control plane" refers to the sum of all protocols 
that control network behaviour. Like, in a traditional network, routing 
protocols, etc. Consequently, an "Autonomic Control Plane" is the sum of 
all protocols that controls the behaviour of an autonomic network. In 
draft-ietf-anima-stable-connectivity we now use the term "Generalized 
ACP" for this abstract concept.


2) In the ANIMA context, we use the term "ACP" also to describe a very 
specific implementation of the generic concept of an "Autonomic Control 
Plane".


I now cleared up the naming in the reference draft. Where we mean the 
abstract concept (3.1 for example), I now use "GACP", where we mean the 
implementation, I now use "ACP" and refer to the ACP draft.


Specifically, I changed in 3.1 from ACP to GACP. And re-worded section 
4.6, which is all about the implementation of the ACP.


2. I’m confused by the whole purpose of Section 3. The first 
sub-clause is describing the architecture of an Autonomic Network 
Element, while the rest sub-clauses (adjacency table, state machine 
etc.) seems more like “implementation considerations” or “procedures”. 
I think both are useful content, but they are in two different 
dimensions, maybe separate them into different sections?




Well, the section is about the network element. I find it quite logic 
that you first discuss the architecture of the element, then how it 
behaves in a network. However, I added an explanatory intro at the 
beginning of that section to make it clearer. Thanks for pointing out 
that this wasn't clear!


3. Some texts (e.g. paragraph 4 of Section 1) are directly bind to the 
WG’s charter, I’m not sure it is a good approach that an RFC 
normatively refer the WG charter which is dynamically changed along 
with the work going on in the WG. Maybe just simply re-phrase the 
“chartered work” as “Phase 1/near term work”, and “non-chartered” as 
“Phase 2 long-term”?




Agree that needs to be fixed. Did some editorial changes for that. The 
sections with an (*) now start with a sentence like this:
    ... is not covered in the current implementation specifications. 
This section is for informational purposes, for following phases of 
standardization. 


As part of that fix, I also re-worded the abstract. It now reads:

This document describes a reference model for Autonomic Networking. It 
defines the behaviour of an autonomic node, how the various elements in 
an autonomic context work together, and how autonomic services can use 
the infrastructure.


Now, the word "charter" is no longer in the text at all.

Comments?

4. The whole Section 7 seems too theoretical and abstract. The 
described concepts are valuable, I’d suggest to have more texts 
mapping these concepts into the ANI/AN.




I made the changes described above, to point out very explicitly that 
these sections are essentially for future study. I would prefer NOT to 
do any more editing beyond that. That should be done in a subsequent 
document, I think.



Specific comments:

Section 1 Introduction

- Paragraph 3 claims “This reference model allows for this hybrid 
approach.” I thin

Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

2018-01-29 Thread Michael H. Behringer

OK, the time for the last call is over.
  I'll produce a -06 version, working through the following issues:

  - Sheng's review from 18 Jan (Thanks Sheng)
  - Michael's response to Sheng's mail.
  - the author issue. I think I'll follow Brian's suggestion,
  listing me as editor and all other co-authors under contributors.
  At least I see no better way...

  I think those are all the open comments I saw. Did I miss
  anything? 

  Michael

  On 18/01/18 19:34, Michael Richardson wrote:

Sheng Jiang  wrote:
> Hi, authors of anima-reference-model,

{contributor speaking}

> General issues:

> 1. In section 3.1, it says "The Autonomic Control Plane (ACP) is the
> summary of all interactions of the Autonomic Networking Infrastructure
> with other nodes and services.

> In my understanding, the ACP itself is mostly a "channel", although
> some ANI functions (signaling, aggregated reporting etc.) are running
> within the channel, they should be parallel with ACP function in the
> architecture view.

I concur with you, I'm also confused by the word "summary"
While we think of the ACP as the channel on which control functions occur, I
can also see that more generically (at the Dilbert's boss' level), the ACP is
the channel + all the interactions.  Perhaps we need a new term.

> 1) Do you see ACP as an individual function as I understood (mostly a
> channel), or a summary of a suite of functions running inside the ACP?

I also think it's worth thinking of the ACP as being a very special ASA that
creates the secure channel.  Maybe that's too recursive for some people, but
I think that doing so will encourage us to design the right management
functions for the ACP itself.

> 2) What functions are sub-functions of ACP, and what are in parallel
> with ACP?

That's a good question.
(/me looks distantly and tries to change the subject :-)

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-

  ___
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] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

2018-01-10 Thread Michael H. Behringer

I guess I've made my point before, but
  just in case: I'm also co-author, and also think this doc is ready
  to move forward. 

  Michael

  On 10/01/18 22:06, Jéferson Campos Nobre wrote:

  Dear Anima.
I am also a co-author of this draft and I think it is in a
  good shape to advance. Besides that, I believe the publication
  of the reference model is an important step for the WG.
Best.
Jéferson

Em ter, 9 de jan de 2018 às 19:32, Brian E
  Carpenter 
  escreveu:

Hi,

  I am a co-author of this draft. I do believe that it is
  ready to advance, and that it's useful to get it published
  soon so that it can indeed act as a reference model. We
  know that a second edition will probably be needed to
  include future work.

  (At least one minor correction is pending in the XML
  source:
  https://github.com/mbehring/ANIMA-Reference-Model/commit/163999c1d03599
  )

  Regards
     Brian Carpenter

  On 09/01/2018 19:26, Sheng Jiang wrote:
  > Hi all,
  >
  > This message starts the two-week ANIMA Working Group
  Last Call to advance draft-ietf-anima-reference-model-05,
  A Reference Model for Autonomic Networking. This
  document's intended status is Informational. At present,
  there is no IPR file against this document.
  >
  > Please send your comments by January 22nd, 2018. If
  you do not feel this document should advance, please state
  your reasons why.
  >
  > Sheng JIANG is the assigned document shepherd.
  >
  > Regards,
  >
  > Sheng (co-chair, Toerless who as a co-author stayed
  neutral on the content side)
  >
  >
  >
  >
  > ___
  > 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] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017

2017-12-07 Thread Michael H. Behringer


I also support the adoption of this document.

Michael

On 29/11/2017 6:35 AM, Sheng Jiang wrote:

During the IETF100, there was a consensus that draft-liu-anima-grasp-api
is fully consistent with the current ANIMA charter, under the condition
it intends to be an Informational document. After the meeting, the
authors have updated the document. The current intended status is
Informational. There was an adoption call on this document as a ANIMA
working group document in the ANIMA session, IETF100. There were
supports and no objection as far as chairs heard. As an official
procedure, we now confirm the adoption in the ANIMA mailing list. This
message starts a two-week adoption call on draft-liu-anima-grasp-api.

 


  Title:  Generic Autonomic Signaling Protocol Application Program
Interface (GRASP API)

  Authors :   Liu, et al.

  Filename:   draft-liu-anima-grasp-api

  https://tools.ietf.org/html/draft-liu-anima-grasp-api-06

 


Please express your support or rejection. If you think this document
should _not_ be adopted, please also explicitly indicate the reasons.

 


This adoption call will end on December 12, 2017.

 


Regards,

 


Sheng + Toerless

 




___
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


   References:

 * [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec.
   12, 2017
   
   Sheng Jiang 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-reference-model-05.txt

2017-10-19 Thread Michael H. Behringer


Chairs,

Having incorporated the last comments, I believe this document is ready 
for WGLC. There is an outstanding question on John's sections, but I 
think we can resolve that at the same time.


Michael


On 19/10/17 15:23, internet-dra...@ietf.org wrote:

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   : A Reference Model for Autonomic Networking
 Authors     : Michael H. Behringer
   Brian Carpenter
   Toerless Eckert
   Laurent Ciavaglia
   Peloso Pierre
   Bing Liu
   Jeferson Campos Nobre
   John Strassner
Filename: draft-ietf-anima-reference-model-05.txt
Pages   : 29
Date: 2017-10-19

Abstract:
This document describes a reference model for Autonomic Networking.
The goal is to define how the various elements in an autonomic
context work together, to describe their interfaces and relations.
While the document is written as generally as possible, the initial
solutions are limited to the chartered scope of the WG.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-reference-model-05
https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-05


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/

___
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] Reference draft: New Security Considerations Section

2017-10-19 Thread Michael H. Behringer

On 18/10/17 15:01, Artur Hecker wrote:

Please find below some short additional comments, hopefully on time :-)
Michael, these things are indeed a pain to formulate correctly, so please feel
free to disregard, if it becomes too bulky.

Artur, thanks for the comments, I'm very happy to get feedback! :-)

Somehow I was afraid someone would say this. :-( It's not easy to explain, in
simple terms...

How does this sound:

"In an outsider attack all network elements and protocols are securely managed
and
operating, and an outside attacker can sniff packets in transit, inject and
replay packets.
In an insider attack, the attacker has access to an autonomic node, or can
insert packets
directly into the protected ACP."

[[AH] ] Minor point: as an attack is a practical instantiation of potential threats exploiting some vulnerabilities, I believe
that what we describe here is better called a "threat model". We can still call those presumed actors "inside
attacker" and "outside attacker" respectively, both being "threat agents", but I wouldn't talk about
"inside attack". (Rationale: a specific attack could be an arbitrary combination of all these.)

Well, a threat model is more comprehensive than what we have right now,
and would result in a bigger analysis than I think we want here. Maybe
we should spin off another document on this some time. But I'm a bit
hesitant in using this term in the current version.

Besides, I would suggest addition of "destroy/suppress packets", to fully cover MitM
capabilities of an "on the wire" attacker.

Good point. I'll use the term "drop packets", I think that's the
generally used term. Added: "and that the AN protocols are robust
against packet drops."

For the second phrase, I would add something like: "<...> access to an autonomic
node or any other means (e.g. remote code execution in the node by exploiting ACP-independent
vulnerabilities in the node platform) that would allow the attacker to produce arbitrary
payloads of the protected ACP channels".

Changed (with a few small edits).

Finally, probably it would be good to categorize these "arbitrary payloads": if
the inside attackers only produce some twisted packets and wrong syntax, we can discover
them by sanity checks of ACP related protocols. But for more complex scenarios, we would
seem to need behavioural node analysis or majority votes, etc., which imo still have too
many false positives / negatives. I guess we cannot require TC/TPM with remote
attestation? Especially, because all this is somehow orthogonal to ANIMA...

For now, I suggest we leave it as it is, essentially: "an insider can do
anything". Again, a deeper analysis should go into a separate document,
in my view.

o protected against modification.

o authenticated.

o protected against replay attacks.

o encrypted."
- I'd rather be consistent using "protection on Confidentiality,
Integrity, Availability, and Non-repudiation".

That's not the same :-) You don't cover re-play attacks.

[[AH] ] I would agree with Michael here. C.I.A. refers to data protection, we
talk about a protocol. I would even add MitM specifically in the list above, as
it very probably will be the first choice... (See KRACK).

So now I added a bullet combining both of the comments received: "and
that the AN protocols are robust against packet drops and
man-in-the-middle attacks."

These were all the comments received so far, and I tried to address them
appropriately.

I'll now update the github repo, and publish the new version. The chairs
should decide whether we're good for a WGLC, I think that would be a
good next step. Surely there will be more comments during that process.

Thanks Artur for your comments!

Michael

Greetings
artur

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Reference draft: New Security Considerations Section

2017-10-18 Thread Michael H. Behringer

I think I've incorporated all the comments I got so far, and the latest
version on github addresses all open issues.

Tomorrow I'm planning on pushing version -05. If you still have
comments, I'd appreciate them in the next 24h (or a quick note that I
should still expect comments).

Again, goal is WGLC.

Michael

On 16/10/17 03:15, Jéferson Campos Nobre wrote:

Hi Michael.
I think the security section looks good, but I have some comments, to
clarify some passages

My comments:

In Section 9:
"... transit, inject and replay packets "on the wire". In an insider
attack, the attacker has access to an autonomic node, or can insert
packets directly into the ACP."
- I understand the difference between "on the wire" and "directly into
the ACP", but I think this should be better explained.

In Section 9.1:
"...as well as mechanisms specific to
an autonomic network (such as a secured MASA server)."
- I believe "secured MASA server" can be replaced by "MASA service".

"AN specific protocols and methods must also follow traditional
security methods, in that all packets that can be sniffed or injected
by an outside attacker are:

o protected against modification.

o authenticated.

o protected against replay attacks.

o encrypted."
- I'd rather be consistent using "protection on Confidentiality,
Integrity, Availability, and Non-repudiation".

"Most AN messages run inside the cryptographically protected ACP. The
not protected AN messages outside the ACP are limited to a simple
discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]:
The "Discovery Unsolicited Link-Local (DULL)" message, with detailed
rules on its usage."
- Since it is a important exception, I think the usage rules should be
replicated here instead of just using a reference to the GRASP I-D.

Cheers.
Jéferson

Em qui, 12 de out de 2017 às 06:23, Michael H. Behringer
mailto:michael.h.behrin...@gmail.com>>
escreveu:

As mentioned before, the Security Considerations section needed
work. I
have now restructured and to a large extent re-written that section.

The main focus is on the fact that while AN is auto-protecting, in the
case of a vulnerability, protocol design error, operational error, the
attack surface is huge.

All, especially co-authors: Please read the new section and comment!

Right now only on github:

https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model.txt

Other than that:
- on sections 7.6 and 7.7 I'm waiting for feedback from John.
- otherwise, to my knowledge, all other input received has been taken
into account.

Once 7.6, 7.7 and the security considerations are stable, I'll push a
new version. Co-authors: Comment now! :-)

Michael

___
Anima mailing list
Anima@ietf.org <mailto: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] Reference draft: New Security Considerations Section

2017-10-18 Thread Michael H. Behringer

On 16/10/17 03:15, Jéferson Campos Nobre wrote:

Hi Michael.
I think the security section looks good, but I have some comments, to
clarify some passages

My comments:

Somehow I was afraid someone would say this. :-( It's not easy to
explain, in simple terms...

How does this sound:

"In an outsider attack all network elements and protocols are securely
managed and operating, and an outside attacker can sniff packets in
transit, inject and replay packets. In an insider attack, the attacker
has access to an autonomic node, or can insert packets directly into the
protected ACP."

In Section 9.1:
"...as well as mechanisms specific to
an autonomic network (such as a secured MASA server)."
- I believe "secured MASA server" can be replaced by "MASA service".

Done.

"AN specific protocols and methods must also follow traditional
security methods, in that all packets that can be sniffed or injected
by an outside attacker are:

o protected against modification.

o authenticated.

o protected against replay attacks.

o encrypted."
- I'd rather be consistent using "protection on Confidentiality,
Integrity, Availability, and Non-repudiation".

That's not the same :-) You don't cover re-play attacks.

I respectfully disagree, this would add a lot of detail, and would make
the section less readable. I think the reference is better here.

Will push the changes onto the git repo in a minute.

Michael

Cheers.
Jéferson

Em qui, 12 de out de 2017 às 06:23, Michael H. Behringer
mailto:michael.h.behrin...@gmail.com>>
escreveu:

As mentioned before, the Security Considerations section needed
work. I
have now restructured and to a large extent re-written that section.

The main focus is on the fact that while AN is auto-protecting, in the
case of a vulnerability, protocol design error, operational error, the
attack surface is huge.

All, especially co-authors: Please read the new section and comment!

Right now only on github:

https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model.txt

Other than that:
- on sections 7.6 and 7.7 I'm waiting for feedback from John.
- otherwise, to my knowledge, all other input received has been taken
into account.

Once 7.6, 7.7 and the security considerations are stable, I'll push a
new version. Co-authors: Comment now! :-)

Michael

___
Anima mailing list
Anima@ietf.org <mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Reference draft: New Security Considerations Section

2017-10-12 Thread Michael H. Behringer

As mentioned before, the Security Considerations section needed work. I 
have now restructured and to a large extent re-written that section.


The main focus is on the fact that while AN is auto-protecting, in the 
case of a vulnerability, protocol design error, operational error, the 
attack surface is huge.


All, especially co-authors: Please read the new section and comment!

Right now only on github:
https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model.txt

Other than that:
- on sections 7.6 and 7.7 I'm waiting for feedback from John.
- otherwise, to my knowledge, all other input received has been taken 
into account.


Once 7.6, 7.7 and the security considerations are stable, I'll push a 
new version. Co-authors: Comment now! :-)


Michael

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Reference draft, version 5

2017-10-12 Thread Michael H. Behringer


On 11/10/17 21:18, Brian E Carpenter wrote:

On 12/10/2017 02:47, Michael H. Behringer wrote:
...> It's finally up to the other drafts (ACP, BRSKI, etc) to specify what is 
MUST

and SHOULD.

Agreed. That's not to say that lower case must, should etc. are forbidden in
an informational document where they fit naturally in the text, but we should
not accidentally make the reference model normative.
...

There are different ways of flooding,

Yes. It has sometimes been interpreted to simply mean broadcast (like ARP) but
I don't see it as a misleading word in this case.

...

Information distribution is implemented as an ASA

That isn't entirely consistent with draft-liu-anima-grasp-distribution.
I know that's not a WG document, but it's what we have so far.
I think a better statement is:
   Information distribution is implemented as an ASA function.
The subtle difference is that it might be built into an existing
ASA. For example, in draft-ietf-anima-prefix-management we have
an objective "PrefixManager.Params" for distributing information.

However, I expect generic information such as Intent will be
handled by a generic ASA.

I think this can be fixed with a little wordsmithing of 6.3.3.


Brian, completely agree with you, will fix that in the text. Thanks for 
the note!


Michael


 Brian



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Reference draft, version 5

2017-10-11 Thread Michael H. Behringer

Just incorporated the comments from Artur into the draft (on github for now),
FYI:

On 26/07/17 19:55, Artur Hecker wrote:

Dear community, dear Authors,

I reread the draft-ietf-anima-reference-model-04. I hope it's not arriving at
an inappropriate moment, but please find some notes and remarks below:

1. Page 6: s/potentiall/potential

Fixed.

2. Page 8: Section 4. The text mentions "must implement" and "other" functions,
but fails to correctly guide the reader as to the MUST or not MUST of the functions in the
following subsections. It is partly not even clear from the semantics of the subsections.

Suggestion: clearly group MUST, SHOULD and MAY IMPLEMENT functions in the
subsections.

In re-reading this section, and considering it's an informational document,
I agree this is misleading. For a while I was playing around with various
"must" and "should" ideas, but abandoned this idea.

The draft is too generic to even start to indicate what is "must" or "should".
So I now completely removed the "musts" etc in the intro of this section.
With that change, I think it reads correctly for an informational document.

It's finally up to the other drafts (ACP, BRSKI, etc) to specify what is MUST
and SHOULD.

3. Page 12: Information Distribution - consider rewriting parts of this section
entirely. Several problems:

a) Remove repetitive text in the beginning:
"Certain forms of information, such as Intent, must be distributed across an
autonomic domain. The distribution of information is also a function of the Autonomic
Control Plane. One form of such information is Intent."

Suggestion: Either remove the first inclusion, or the entire last sentence. I
would rewrite these three, see next point:

b) There seems to be a problem with the statement above, as the "must" is
somehow misleading in a potentially normative text. What is meant here is that some
information requires dissemination, while other might not require that.

Suggestion - please REWRITE e.g. as follows:
"Certain forms of information require per its nature distribution across a (part of)
autonomic domain. Such information distribution is a function of the Autonomic Control
Plane. As an example, Intents require distribution across the whole autonomic domain as
per definitions from RFC7575."

Agree with a) and b) and have changed the text accordingly.

c) Later, the text in this section somehow confuses the high level requirements (=information distribution) with a specific implementation, notably flooding. Note that there is a subtle difference between the requirement to reach all recipients (indeed, the current text seems to equal flooding to that) and flooding, which technically usually means "unconstrained broadcast". [E.g. Wikipedia: "Flooding is a simple computer network routing algorithm in which every incoming packet is sent through every outgoing link except the one it arrived on"]. This will lead to explosive message number growth, as the ACP uses routing - which does not guarantee a tree structure - while the scale of an autonomic domain is, by definitions of RFC7575, only constrained by the Intent as such ("the autonomic domain is the set of nodes, to which the intent needs to be sent"). At the same time, there are better known algorithms for routing, which achieve "distribution to all recipients" without "sending on

l links except the one it arrived on" (e.g. structured broadcast, etc).

Suggestion: stay at the requirements level in the Reference text, which this
draft represents. In other words, remove suggestions of implementations, or
reword if the requirement to reach all nodes is meant.

Disagree in some points with this one. There are different ways of flooding,
and we're not suggesting an implementation here. I think that the phrasing
with "should" is weak enough not to confuse, and I think we *do* want to make
the point that this should be very simple.
BTW, flooding is entirely independent of the routing protocol in our case.
Please re-read. If you really have a problem, shout again! :-)

4. Page 17, Section 6.3.3. The Information Distribution ASA (*).
While the text above (on page 12: Information Distribution) says that
Information Distribution is function of ACP, somehow there is a distinct
section in this draft, talking about an Information Distribution ASA, which is
NOT ACP ASA, and which is not obligatory.

How to read this correctly?

Hmmm...
Information distribution is implemented as an ASA. That is really the main
point of section 6.3.3.
I think the confusion is in the term "is a function of the ACP".
I'll replace that with "runs inside the ACP".
ASAs typically run on the ACP. See also figure 2.

There was a view in the WG that Intent may not be required on all nodes in a
domain. For example, you may have simple sensors at the edge which join the
ACP but don't act on Intent.

Does that make it clearer? Re-Reading 6.3.3, I think it is actually correct as
written... (the change was in t

[Anima] Reference draft, version 5

2017-10-10 Thread Michael H. Behringer


  
  
ANIMA WG, 
  
  I started to work on version -05 for the reference draft. As far
  as I recall, we only needed to work on the security considerations,
  then the document would be ready for WG last call. 
  
  The github repo is up to date (thanks to Brian for fixing
  references, and the should/must lowercasing). 
  
  Authors of related docs, please double-check whether any changes
  you made recently may need to be reflected in the reference model.
  
  
  Co-authors: Please review and update your sections if required.
  Either work directly on github, or let me know what to change. The
  document to edit is 
https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model.xml
  
  Any other issues / comments? 
  
  Michael
  

  


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017

2017-09-20 Thread Michael H. Behringer


Hi Sheng,

I'm not aware of any IPR relating to this document.

Michael


On 20/09/17 02:54, Sheng Jiang wrote:

Hi, Toerless,

Thanks for your hard and fruitful work. Giving the change mount from -03 
version, which is the base for the first WGLC, I feel another WGLC is needed. I 
will launch a short one-week WGLC on this. Meanwhile, I still not receive IPR 
disclosure from all authors. I would not be able to move this document forward 
with the proper IPR disclosures, even after the WGLC passed.

Cheers,

Sheng


-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Toerless Eckert
Sent: Wednesday, September 20, 2017 2:53 AM
To: Brian E Carpenter
Cc: Anima WG
Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 -
Respond by July 28, 2017

Thanks, Brian!

Sheng: i think/hop i am trough all outstanding issues with
stable-connectivity. Please decide what to do next to move to next stage,
eg: another WG last call or pass to IETF/IESG.

Cheers
 Toerless

On Tue, Sep 19, 2017 at 08:11:56AM +1200, Brian E Carpenter wrote:

This is embarassing. For some reason I completely missed the
announcement of draft-ietf-anima-stable-connectivity-05, until today.

I have now looked at the -05 and -06 versions and I'm happy with the

result.

Regards
Brian

On 18/09/2017 17:38, Toerless Eckert wrote:

Thanks, Brian:

The "OLD" paragraph you list was from -04. After your review i had
already changed this in -05 to

NEW:

To connect IPv4 only management plane devices/applications with

the

ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is
necessary.  The basic mechanisms for this are defined in SIIT
([RFC7915]).  There are multiple solutions using this mechanisms.

To

understand the possible solutions, we consider the requirements:


http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.
ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https:/
/tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt

I also did spend a good amount of time because of your -04 review
and prior request by mohammed to detail in the following

parapgraphs

the possible options in more detail.  That text leverages the 'SIIT'
term and discusses the EAM solutions (RFC7757 is best).

Given how this is an informational OPS document, i think it is
helpfull to elaborate on the understood details of requirements and
how known current solutions fit them.

  The fact that none of the
currently defined NAT solutions provides for the most simple
possible configuration (aka: minimum number of prefix EAM's to
configure) is also IMHO a perfectly valid outcome for an OPS

document.

It could mean that users will simply accept the need for longer
mnaual NAT config (long list of 1:1 mappings) or vendors implement a
proprietary EAM (explicit address mapping) CLI to make it simpler.
Or users will move faster to IPv6 on the NOC ;-)

So, for the time being, i just commited -06 with the second fix.

Let me know what you folks think about WG last call status of the
stable connectivity draft.

Cheers
 Toerless

On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote:

To cut a long story short, here's a friendly suggestion. The goal
is to avoid comments during IETF/IESG review that the NAT text is too

vague:

OLD
To bridge an IPv4 only management plane with the ACP, IPv4 to

IPv6

NAT can be used.  This NAT setup could for example be done in

Rt1r1

in above picture to also support IPv4 only NMS hots connected to
NOClan.

NEW
To bridge an IPv4-only management plane with the ACP, IPv4 to

IPv6

translation [RFC 6145] could be used. This could for example be

done in Rt1r1

in the above picture to also support IPv4-only NMS hosts

connected to

NOClan. Details of the address mapping to be used would

depend on

the exact scenario and are not specified here.

And yes, I like this:


i'd suggest to replace the "split-horizon" sentence with:

Operators may therefore need to use a private DNS setup for the
ACP ULA addresses. This is the same setup that would be necessary
for using
RFC1918 addresses in DNS. See for example [RFC1918] section 5,
last paragraph. In [RFC6950] section 4, these setups are discussed in

more detail.

Regards
Brian

On 15/09/2017 09:18, Toerless Eckert wrote:

Hi Brian,

Sorry, for the delay. I have not sen further feedback on
stable-connectivity-05 bside this mail of yours. See answers
below, let me know if you want me to rev with the one possible

textual improvement or if we think -05 is good enough.

Cheers
 Toerless

On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote:

I'm just coming back on a couple of points. Generally -05 is almost

there...

See the rewritten SIIT section. IMHO, there can be no simpler
"network" based address translation. Where network based

means

that the translation happens in some device he network operator

needs to provisi

Re: [Anima] Review draft-ietf-anima-reference-model-04

2017-07-26 Thread Michael H. Behringer

Thanks for your comments, Artur. I'm in the middle of vacations, but
will incorporate your comments when back, in the next version!

Brian, seen your response, too. Will catch up...

Michael

On 26/07/17 19:55, Artur Hecker wrote:

Dear community, dear Authors,

I reread the draft-ietf-anima-reference-model-04. I hope it's not arriving at
an inappropriate moment, but please find some notes and remarks below:

1. Page 6: s/potentiall/potential

Suggestion: clearly group MUST, SHOULD and MAY IMPLEMENT functions in the
subsections.

3. Page 12: Information Distribution - consider rewriting parts of this section
entirely. Several problems:

Suggestion: Either remove the first inclusion, or the entire last sentence. I
would rewrite these three, see next point:

l links except the one it arrived on" (e.g. structured broadcast, etc).

How to read this correctly?

5. Page 17, Section 7.1: "How an AN Network Is Managed"
a) Please consider changing the title. AN is "autonomic network" network
network :-)
b) The first paragraph says that the co-existence is twofold. However, I can think of at
least one other way: the ACP could be used as a transport channel for
"traditional" management. E.g. ACP could be used to transport NETCONF messages,
instead of SSH or BEEP in NETCONF. Not clear, what twofold means here (just an example,
limitation, strong statement, etc).

6. Page 18, Section 7.2: "Intent"
Please reread and correct this phrase: "It is expected Intent definitions from
autonomic function(s) and even from traditional network management elements".
(missing verb)

Later in the text, the section references I-D.liu-anima-grasp-distribution,
which is odd, given that the actual Information Distribution section (see
above) does not. Yet, information distribution in
I-D.liu-anima-grasp-distribution is not limited to intents.

7. Page 19, Section 7.5: "Control loops"
The section talks about an "Autonomic System". Unless I am mistaken, an autonomic system
is not defined (e.g. in RFC7575). This is a minor issue, as we all can imagine what a
"system" is.

8. Page 20, Section 7.6: "APIs"
There is a strong "MUST" requirement in this section (express and preserve semantics across
different domains), which is not as clear as a MUST should be. First, it's not clear what "express and
preserve semantics" mean

[Anima] draft-ietf-anima-reference-model-04

2017-07-04 Thread Michael H. Behringer

As promised, here the new version of the reference model draft. I'll be 
submitting in a minute, the github repo already has it: 
https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model-04.txt. 
The diff is attached for easy consumption.


As suggested by Brian, I re-read the draft, and changed the general 
wording in some places regarding "work in progress", etc. I now call 
this AN phase 1, and explain that there may be more phases.


Changed the security section almost completely, taking into account the 
comments received. Specifically, pointing out the threats on the ACP. I 
was about to add a comparison to the security of the routing system, but 
in the end decided against. Folks - please review and let me know how 
this reads.


In the security section we had the phrase: "AN messages are liable to be 
exposed to third parties on any unprotected Layer 2 link." I think this 
is only true for specific discovery-like messages like GRASP M_FLOOD, 
but by default most AN messages are inside the ACP and thus encrypted. 
So I suggest to change this rather scary sounding sentence, and point 
out that only  specific messages are unprotected, and point to section 
2.5.2 of the GRASP draft.


Updated a few references, editorial stuff, etc.

I suggest the draft is ready for WGLC, and would request the chairs to 
issue that call.


Michael


<<< text/html; charset=UTF-8; name="Diff: draft-ietf-anima-reference-model-03.txt - draft-ietf-anima-reference-model-04.txt.html": Unrecognized >>>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] draft-ietf-anima-reference-model-04

2017-07-04 Thread Michael H. Behringer

As promised, here the new version of the reference model draft. I'll be 
submitting in a minute, the github repo already has it: 
https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model-04.txt. 
The diff is attached for easy consumption.


As suggested by Brian, I re-read the draft, and changed the general 
wording in some places regarding "work in progress", etc. I now call 
this AN phase 1, and explain that there may be more phases.


Changed the security section almost completely, taking into account the 
comments received. Specifically, pointing out the threats on the ACP. I 
was about to add a comparison to the security of the routing system, but 
in the end decided against. Folks - please review and let me know how 
this reads.


In the security section we had the phrase: "AN messages are liable to be 
exposed to third parties on any unprotected Layer 2 link." I think this 
is only true for specific discovery-like messages like GRASP M_FLOOD, 
but by default most AN messages are inside the ACP and thus encrypted. 
So I suggest to change this rather scary sounding sentence, and point 
out that only  specific messages are unprotected, and point to section 
2.5.2 of the GRASP draft.


Updated a few references, editorial stuff, etc.

I suggest the draft is ready for WGLC, and would request the chairs to 
issue that call.


Michael


<<< text/html; charset=UTF-8; name="Diff: draft-ietf-anima-reference-model-03.txt - draft-ietf-anima-reference-model-04.txt.html": Unrecognized >>>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] RPL alternatives in ACP?

2017-06-07 Thread Michael H. Behringer

Bing, I´m afraid that´s a can of worms... Homenet has been stalled for a 
long time, and quite a few IETFs were only about the fight "my routing 
protocol is better than yours". I´m afraid if we enter this discussion, 
we have 2 years of arguments ahead for no obvious benefit.


Let me ask the other way round: With the specs as they are, what will 
NOT work?


My view: Unless we have a real good reason, we should not enter this 
debate...


Michael

On 07/06/2017 06:04, Liubing (Leo) wrote:

Hi ACP co-authors,

(Maybe you missed my last mail "Regarding ACP routing protocol", let me re-post 
it with a clearer title and CC to you.)

When I discuss ACP with some product people, they are always curious about why 
we choosed RPL for routing.
I understand the benefits of RPL in ACP, it is lightweight and much more 
scalable in a single routing area, but most of the non-IoT network devices seem 
lacking the support of RPL.

So, please pardon my iteration on this problem, can we possibly make another 
traditional IGP literally legal in the ACP document? (e.g. ISIS-autoconf or 
OSPFv3-autoconf) I know supporting multiple protocols would potentially cause 
interoperation issues. But in some closed solutions, multi-vendor 
interoperation is not the No.1 consideration for customers. If ACP allows 
ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more widely adopted in 
non-IoT network scenarios.

Any comments/eggs? :)

B.R.
Bing


-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Liubing (Leo)
Sent: Tuesday, May 23, 2017 5:53 PM
To: Anima WG
Subject: [Anima] Regarding ACP routing protocol

Hi all,

When I discuss ACP with some product people, they are always curious
about why we choose RPL for routing.
I understand the benefits of RPL in ACP, it is lightweight and much more
scalable in a single routing area, but most of the non-IoT network devices
seem like lack the support of RPL.

So, please pardon my iteration on this problem, can we possibly make
another more traditional IGP literally legal in the ACP document? (e.g.
ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple protocols
would potentially cause interoperation issue. But in some closed solutions,
multi-vendor interoperation is not the No.1 consideration for customers. If
ACP allows ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more
widely adopted in non-IoT network devices.

Any comments? Or eggs :)

B.R.
Bing

___
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] autonomic framework

2017-03-27 Thread Michael H. Behringer


  
  
Join proxy is ok with me. 
  
  I find the "Join Registrar" a bit weird, to me "Registrar" itself
  is pretty clear in its purpose. But, never mind, main thing is we
  use the same terms everywhere. 
  
  I don´t really like the term "router" for the proxy. To me a
  "router" takes everything that comes in on one side, and sends it
  out the other. Here we´re talking a single protocol, thus very
  selective. "Proxy" describes that better than "router".
  
  Michael
  
  On 27/03/2017 23:10, Michael Richardson wrote:


  
Michael, some comments driven by the slides:

We changed the name from Join Assistant to Join Proxy, as a consistent
name across netconf,anima and 6tisch.

(Peter wants us to change it to Join Router, because it forwards
packets... but...)


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




  
  
  
  ___
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] New version of draft-ietf-anima-reference-model

2017-03-13 Thread Michael H. Behringer


ANIMA WG,

I just uploaded a new version of the reference model, 
https://tools.ietf.org/html/draft-ietf-anima-reference-model-03.


Below the change log; I believe to have addressed all open issues.

Feedback please!
Michael on behalf of the co-authors.

--

* Added the state machine, as discussed in the last IETF.

* Re-ordered things a bit: Now the state machine, as well as the 
description of the adjacency table (old section 5) are part of section 
3, which has become more important, but I think we now have all elements 
concerning an autonomic node in one section, which looks a lot better to 
me. Also, I dropped the old section 5 "Behavior of an autonomic node", 
that never really fit well. So now it looks like this:

   3.  The Autonomic Network Element . . . . . . . . . . . . . . . .   4
 3.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
 3.2.  The Adjacency Table . . . . . . . . . . . . . . . . . . .   6
 3.3.  State Machine . . . . . . . . . . . . . . . . . . . . . .   8
   3.3.1.  State 1: Factory Default  . . . . . . . . . . . . . .   8
   3.3.2.  State 2: Enrolled . . . . . . . . . . . . . . . . . .   8
   3.3.3.  State 3: In ACP . . . . . . . . . . . . . . . . . . .   9

* Intent distribution: The previous version of the draft only referred 
to intent to be distributed; following our discussions the distribution 
protocol may also transport other "information" (which is the term I use 
now in the draft), which I have now brought out more explicitly in some 
places.


* There was some discussion on whether we should be more explicit in how 
information (e.g., Intent) is flooded. I think we settled on GRASP 
synchronising which node has which version of "information", and where 
to find it (URI). Then another protocol pulls that information block if 
needed.
However, looking at the reference draft right now, I think we should NOT 
enter this level of detail here; this should be dealt with in 
draft-liu-anima-grasp-distribution. I think we're better off if the 
reference draft stays on a high level here. In any case, it's formally 
out of scope in ANIMA right now.


* Dealing with out-of-scope topics: I think we agreed that we must 
include some topics in the draft that are formally out of scope, to 
provide the context for certain decisions. So far I think we universally 
agree. We went back-and-forth a few times whether to mark topics with 
(*) inline, or whether to group them in an appendix. Neither way is 
perfect. My personal preference is to leave them inline, in the sections 
they belong to, because if we group them in an appendix we lose context. 
I think all such topics are clearly marked with a (*) and in each such 
section I wrote explicitly "outside scope for now". I also re-ordered 
some sections such that the (*) topics are always last in each section 
(e.g., I re-ordered 4.6 and 4.7). If anyone has a problem with that, 
please shout!


* Made some changes to (old) section 5, "Behaviour of an autonomic node":
** changed the sequence: First, node joins ACP, THEN it starts bootstrap 
proxy

** added Registrar discovery as a separate step.
** explained that bootstrap proxy is an ASA (as discussed in the ASA 
section)
** condition for the latter is 1) part of ACP, and 2) having discovered 
at least one Registrar.


* some editorial changes; changed a "MAY" to a "may".

* Changed "The Proxy ASA" to "The Join Assistant ASA", and "The 
Registrar" is now "The Join Registrar".



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Factory reset: Do we need two types?

2017-03-13 Thread Michael H. Behringer

Formulating the state machine in the reference draft, I come to the 
conclusion that we should actually *not* mention that "reset to default 
configuration" in it, because it actually has nothing to do with AN at all.

From an AN perspective it´s important to show what happens when:
- we delete the LDevID. A factory reset does that.
- a device loses all ACP tunnels.

The configuration of the device is outside scope, I think! If a config 
change removes the last ACP tunnel (for example), then it's that removal 
that changes the state in the AN machine.

The important thing to mention (and so far missing) is IMO that *only* a 
factory re-set can remove the LDevID, otherwise we may end up with stale 
state at enrollment time. I added that point in my new section.

Please shout if you think I'm missing something.

Michael

On 11/03/2017 21:00, Michael Richardson wrote:

Michael H. Behringer  wrote:
 > worth noting in the reference draft though, to be sure).  - A process
 > where the LDevID remains on the device in my view of the world is
 > therefore NOT a factory reset. I would call this "erase device
 > configuration except the LDevID".

"Reset to default configuration"

 > I therefore suggest to use / define the term "factory reset" as per
 > first bullet above. And NOT define two types of factory reset. It just
 > feels wrong to me.

I agree.

 > What am I missing? Why did we even need a term for the second? Can we
 > not just say "delete config, but leave LDevID"?

I think that this is the activity that one usually wants when some
button is held down.  Deleting the LDevID is probably more than most
operators expect.

Deleting the LDevID brings the device back to "unowned" state.
Some devices should support such a thing, and some simply should not.
Some should require a screwdriver/jumper/etc.

In particular, being able to reset to default configuration may be
something that should be easy to do for a untrusted operator
(i.e. CPE in residential setting), but which shouldn't change the onwership.

  --
Michael Richardson , Sandelman Software Works
  -= IPv6 IoT consulting =-

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Factory reset: Do we need two types?

2017-03-13 Thread Michael H. Behringer

Thanks, Michael, I think we're in sync. I'll take on board your "reset 
to default configuration".

Now I wonder where this idea of the "two types of factory reset" 
actually came from? Never mind... We're all aligned, that's the key.

Michael

On 11/03/2017 21:00, Michael Richardson wrote:

Michael H. Behringer  wrote:
 > worth noting in the reference draft though, to be sure).  - A process
 > where the LDevID remains on the device in my view of the world is
 > therefore NOT a factory reset. I would call this "erase device
 > configuration except the LDevID".

"Reset to default configuration"

 > I therefore suggest to use / define the term "factory reset" as per
 > first bullet above. And NOT define two types of factory reset. It just
 > feels wrong to me.

I agree.

 > What am I missing? Why did we even need a term for the second? Can we
 > not just say "delete config, but leave LDevID"?

I think that this is the activity that one usually wants when some
button is held down.  Deleting the LDevID is probably more than most
operators expect.

Deleting the LDevID brings the device back to "unowned" state.
Some devices should support such a thing, and some simply should not.
Some should require a screwdriver/jumper/etc.

In particular, being able to reset to default configuration may be
something that should be easy to do for a untrusted operator
(i.e. CPE in residential setting), but which shouldn't change the onwership.

--
Michael Richardson , Sandelman Software Works
  -= IPv6 IoT consulting =-

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Factory reset: Do we need two types?

2017-03-10 Thread Michael H. Behringer

There was a discussion about the term factory reset, and what it means. 
Specifically, whether the LDevID (domain certificate) is deleted.


The notes I have taken (from someone's mail) indicate:
  type 1: erase all but LDevID - Device doesn’t need to re-enrol
  type 2: erase all, including LDevID

While trying to work this into the reference draft, I'm getting less and 
less comfortable with the sentiment of "two types of factory re-set".


Here my thinking:
- Factory reset brings a device back to the state it had when it left 
the factory. This is very unambiguous, and clear. The device will keep 
its IDevID and the LDevID will be deleted. (may be worth noting in the 
reference draft though, to be sure).
- A process where the LDevID remains on the device in my view of the 
world is therefore NOT a factory reset. I would call this "erase device 
configuration except the LDevID".


I therefore suggest to use / define the term "factory reset" as per 
first bullet above. And NOT define two types of factory reset. It just 
feels wrong to me.


What am I missing? Why did we even need a term for the second? Can we 
not just say "delete config, but leave LDevID"?


Michael

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] SecDir review of draft-ietf-anima-grasp-09

2017-03-10 Thread Michael H. Behringer


On 09/03/2017 20:37, Brian E Carpenter wrote:

On 10/03/2017 05:53, Barry Leiba wrote:

 > Personal opinion: encryption should be a MUST.

I believe that we will have situations where we have a secured ACP into a NOC
(to an edge router or VM hypervisor), and then we will have some unencrypted,
but secured links to platforms in transition.

It will be easy to add the GRASP daemon to answer resource requests to the
platform, but hard to add the ACP to that platform without a forklift
upgrade.

This is why I think it is a SHOULD, as much as I want it to transition to
being a MUST.

This brings up a common rant that I have:
We should be putting into our protocol specs what we want the protocol
to be, not some compromise that comes from knowing that not everyone
will comply with everything from the start.

If the right thing is to say "MUST encrypt", but we know there'll be a
transition period during which that's not fully practical, then we
should say that.  Something like this added to Section 3.5.1:

NEW
In some cases there will be a transition period, in which it might not
be practical to run with strong encryption right away.  It's important
to keep this period as short as possible, and to upgrade to a fully
encrypted setup as soon as possible.
END

or perhaps more precisely:

During initialization of nodes there will be a transition period...

Whether this is phrased as an exception to the MUST or as the justification
for ignoring the SHOULD is a matter of taste, I think.


Confused about this last comment. MichaelR pointed out the case of a 
legacy network management platform, where you can easily add GRASP, but 
not ACP support. I concur with this view: We saw this a lot in customer 
deployment discussions.


When you say "during initialization of nodes", Brian, do you mean of 
management stations or of nodes out there in the network?


In my understanding I would have written something like "until network 
management systems can be upgraded to full ACP support ..."


What am I missing?
Michael

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

41 matches

Mail list logo