Re: [Anima] Self-Managed Networks

[John Strassner <[e-mail]>]

I for one think that these are just examples. It is a **control plane**,
so it should not be **limited** to those functions.

Toerless, can you elaborate?

regards,
John

On Sun, Oct 18, 2015 at 8:13 AM, Toy, Mehmet <[e-mail]>
wrote:

> Michael,
> Yes there was.
> Discussion with Toerless made it clear to me that the model is for "auto
> routing and auto discovery".
> Mehmet
>
>
> -----Original Message-----
> From: Michael Behringer (mbehring) [mailto:[e-mail]]
> Sent: Friday, October 16, 2015 4:44 AM
> To: Brian E Carpenter; Toy, Mehmet; [e-mail]
> Subject: RE: Self-Managed Networks
>
> Adding to Brian's response (which I agree with), and up-levelling the
> discussion a bit:
>
> Mehmet, I think there is a simple misunderstanding here. The ACP is a
> control plane for *device* management. A device can hold many contexts, as
> in NFV, but they are all managed in a single way. My feeling is we have a
> disconnect somewhere on this level, right?
>
> Michael
>
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:[e-mail]]
> > Sent: 16 October 2015 08:02
> > To: Toy, Mehmet <[e-mail]>; Michael Behringer
> > (mbehring) <[e-mail]>; [e-mail]
> > Subject: Re: Self-Managed Networks
> >
> > On 16/10/2015 16:36, Toy, Mehmet wrote:
> > > Michael,
> > >
> > > Before I pick each of your statement and express my thoughts, I
> > > would like
> > to ask more questions by picking your  statement " There is *one* ACP,
> > there are *many* autonomic functions on top.".   Assume we  start
> building
> > on this to see how far we can go, whether this holds for all cases or
> > not, I don't know.
> > >
> > > If we have two or more ACPs, what could go wrong?
> >
> > Why would a domain need more than one ACP? (Certainly there might be a
> > transient situation after a temporary network partition where two ACPs
> > would "meet" and then need to merge; indeed the ACP needs to be self-
> > repairing in such cases.)
> >
> > > What is it that you are trying to do here? What is the purpose
> > > behind this
> > model?
> >
> > Provide a secure L3 between all autonomic nodes that is strictly
> > independent of the operational data plane. The purpose is to allow
> > autonomic operations to work regardless of anything else.
> >
> > >
> > > Furthermore, I suggest you to think about ETSI NFV model,
> > > "infrastructure" and "VNF" division of networks.  What is wrong in
> > > using that kind of model here which is a reasonable breakdown,
> >
> > We aren't reinventing NFV, as far as I can tell. If there is a recent
> > technical overview of NFV, that would be interesting to see. But I
> > don't believe that Autonomic Service Agents are at all the same thing as
> VNFs.
> >
> > > instead of sticking with ACP  that is becoming very difficult to
> define?
> >
> > Huh? draft-ietf-anima-autonomic-control-plane is still work in
> > progress but it seems very clearly defined to me. In sketching out how
> > GRASP will be implemented, I haven't hit any conceptual problems with
> > the ACP, and its main API will just be socket calls. The only
> > complication I found is that it will need to support the Advanced
> > Socket API because of some special requirements for link-local
> > multicasts. Otherwise, it's just another virtual
> > (loopback) network interface.
> >
> > Regards
> >    Brian
> >
> > >
> > > Thanks
> > > Mehmet
> > >
> > > -----Original Message-----
> > > From: Michael Behringer (mbehring) [mailto:[e-mail]]
> > > Sent: Thursday, October 15, 2015 4:57 AM
> > > To: Toy, Mehmet; Brian E Carpenter; [e-mail]
> > > Subject: RE: Self-Managed Networks
> > >
> > > Toy, thanks for raising those questions. Obviously, we're not doing
> > > a good
> > job yet in describing what the ACP is, and that needs to be fixed. And
> > obviously, we all need the same view to progress further. So this is a
> > very important discussion, and I really welcome it.
> > >
> > > Before formalising better text, let me see whether we get agreement
> > > on
> > the fundamental idea.
> > >
> > > In my head, there are two layers: The ACP, and on top of that the
> > Autonomic Functions:
> > >
> > > * The ACP is the "tool kit". It comprises various "mechanics", such
> > > as
> > negotiation, synchronisation, discovery of various sorts, messaging, etc.
> > Those are all based on a common addressing and naming concept.
> > >
> > > * Autonomic Functions use that tool kit to do something clever. In
> > > other
> > words, the true autonomic "intelligence" sits on that level.
> > >
> > > There is *one* ACP, there are *many* autonomic functions on top.
> > >
> > > One way to decide to which layer something belongs is to ask: "is
> > > this (1) a
> > generic functionality which many functions require, or is this (2) one
> > specific function?". If the answer is (1), it belongs into the ACP, if
> > (2) it belongs into an autonomic function.
> > >
> > > So, in this light, my understanding (!) of fault management is that
> > > this is an autonomic function, and would use common blocks of the
> > > underlying ACP. Conversely, it would not offer services to other
> > > autonomic functions on top. This is my way of thinking when I write
> > > "this is an autonomic function".  And I'm not 100% certain I
> > > understand what you're suggesting, so please chime in here! (And I
> > > haven't read your draft fully yet, sorry)
> > >
> > > Look at
> > > http://tools.ietf.org/id/draft-jiang-anima-prefix-management-01.txt
> > > This draft describes "intelligence". In that case, a way to
> > > automatically
> > manage address space. Sections 2.2 and 2.3 explain which parameters
> > and information exchanges such a function would require. Sheng wrote
> > this document to explain how an autonomic function would use a common
> ACP.
> > >
> > > Probably we should take some off-line time in Yokohama to discuss
> > > this in a
> > small team?
> > >
> > > Michael
> > >
> > >
> > >> -----Original Message-----
> > >> From: Anima [mailto:[e-mail]] On Behalf Of Toy,
> > Mehmet
> > >> Sent: 15 October 2015 04:26
> > >> To: Brian E Carpenter <[e-mail]>; Michael
> > >> Behringer
> > >> (mbehring) <[e-mail]>; [e-mail]
> > >> Subject: Re: [Anima] Self-Managed Networks
> > >>
> > >> Michael and Brian,
> > >> Per Toerless suggestion, I am including ANIMA group into the
> discussion.
> > >>
> > >> I re-read the "A Reference Model for Autonomic Networking" document
> > >> and I am not clear about the definitions.
> > >>
> > >> a)  In the "A Reference Model for Autonomic Networking", ACP is
> > >> defined as "The Autonomic Control Plane is the summary of all
> > >> interactions of the Autonomic Networking Infrastructure with other
> > nodes and services.".
> > >>
> > >> b) Brian, you write as " The ACP is common infrastructure for all
> > >> autonomic functions.(The ACP needs to be self-repairing, of
> > >> course.) The signaling protocol is also common infrastructure."
> > >>
> > >> Question: What is ACP? a or b or combination?
> > >>
> > >> c) Section 4 in the reference model document , "The Autonomic
> > >> Networking Infrastructure provides a layer of common  functionality
> > >> across an Autonomic Network.  It comprises "must implement"
> > >> functions and services, as well as extensions."
> > >> Question: What are the "must implement" functionalities?  How do
> > >> you define "must implement" functionalities?
> > >>
> > >> Thanks
> > >> Mehmet
> > >> -----Original Message-----
> > >> From: Brian E Carpenter [mailto:[e-mail]]
> > >> Sent: Wednesday, October 14, 2015 5:25 PM
> > >> To: Michael Behringer (mbehring); Toy, Mehmet
> > >> Cc: '[e-mail]'; '[e-mail]'; 'anima-
> > >> [e-mail]'
> > >> Subject: Re: Self-Managed Networks
> > >>
> > >> I agree with Michael. The ACP is common infrastructure for all
> > >> autonomic functions.
> > >> (The ACP needs to be self-repairing, of course.) The signaling
> > >> protocol is also common infrastructure.
> > >>
> > >>    Brian
> > >> On 15/10/2015 05:43, Michael Behringer (mbehring) wrote:
> > >>> I would argue they are part of an autonomic function, which runs
> > >>> on top of
> > >> the ACP.
> > >>> There are really two different pieces here, and this is I think
> > >>> the confusion
> > >> here:
> > >>>
> > >>> -          The ACP is self-managing. It needs to do self-healing, and
> > >> automatically adapt to new situations. But to me, this isn’t fault
> > >> management or performance management as an operator understands
> > it.
> > >>>
> > >>> -          The network has FM and PM function. Those could be (and
> should
> > >> be, imo) autonomic functions. Those run on top of the ACP.
> > >>> Bottom line: I’d like to keep the ACP itself as minimalistic and
> > >>> simple as we
> > >> possibly can. Functions like FM / PM belong into an autonomic
> > >> function,
> > IMO.
> > >>> What do you think?
> > >>> Michael
> > >>> From: Toy, Mehmet [mailto:[e-mail]]
> > >>> Sent: 14 October 2015 18:30
> > >>> To: Michael Behringer (mbehring) <[e-mail]>
> > >>> Cc: '[e-mail]' <[e-mail]>;
> > >> '[e-mail]'
> > >>> <[e-mail]>; '[e-mail]'
> > >>> <[e-mail]>; '[e-mail]'
> > >>> <[e-mail]>
> > >>> Subject: RE: Self-Managed Networks
> > >>>
> > >>> Michael,
> > >>> Instead of answering the question as Yes or No, let me give
> > >>> examples to
> > >> see what makes sense.
> > >>> Let’s say in a data path, a router port is failed.  The router
> > >>> generates an AIS
> > >> (Alarm Indication Signal) and the receiving  end generates RDI
> > >> (remote Defect Indicator).  Both messages are generated by the
> > hardware, not by a
> > >> software or ACP.   As a result of this failure,  there would be
> packet loss.
> > The
> > >> hardware counts these losses, an ACP does not.
> > >>> For the FM and PM functions above, can we say they are part of an
> ACP?
> > >>> Thanks
> > >>> Mehmet
> > >>> From: Michael Behringer (mbehring) [mailto:[e-mail]]
> > >>> Sent: Wednesday, October 14, 2015 11:34 AM
> > >>> To: Toy, Mehmet
> > >>> Cc: '[e-mail]'; '[e-mail]'; 'anima-
> > >> [e-mail]'; '[e-mail]'
> > >>> Subject: RE: Self-Managed Networks
> > >>>
> > >>> Hi Toy,
> > >>> To understand better: To me, fault management *uses* the functions
> > >>> of
> > >> the AN infrastructure. It uses the ACP to communicate, maybe GRASP
> > >> for some signalling, might be influenced by Intent, etc. Right?  So
> > >> to me, this is a logical component of an autonomic network that
> > >> sits on top of the AN infrastructure.
> > >>> Do we agree?
> > >>> Michael
> > >>>
> > >>> From: Toy, Mehmet [mailto:[e-mail]]
> > >>> Sent: 13 October 2015 23:46
> > >>> To: Michael Behringer (mbehring)
> > >>> <[e-mail]<mailto:[e-mail]>>
> > >>> Cc: '[e-mail]'
> > >>> <[e-mail]<mailto:[e-mail]>>;
> > >>> '[e-mail]'
> > >>> <[e-mail]<mailto:[e-mail]>>;
> > >>> '[e-mail]'
> > >>> <[e-mail]<mailto:[e-mail]>>;
> > >>> '[e-mail]'
> > >>> <[e-mail]<mailto:[e-mail]>>
> > >>> Subject: RE: Self-Managed Networks
> > >>>
> > >>> Michael,
> > >>> Appreciate the reply.
> > >>> FM is part of data plane and control plane (i.e. ANI in your
> diagram).
> > >>> My plan is to add a short paragraph for now either to section 2 to
> > >>> expand
> > >> the description  of ANI or to section 4 to add a sub-section for
> > >> Fault Management.
> > >>>
> > >>> It is also possible too add a Performance Management section to
> > >>> describe
> > >> what types of measurements and where and how are used.  Although
> > >> there is a control feedback related measurement in the document, I
> > >> don’t know if it is adequate.
> > >>>
> > >>> Regards,
> > >>> Mehmet
> > >>> From: Michael Behringer (mbehring) [mailto:[e-mail]]
> > >>> Sent: Tuesday, October 13, 2015 12:27 PM
> > >>> To: Toy, Mehmet
> > >>> Cc: '[e-mail]'; '[e-mail]'; 'anima-
> > >> [e-mail]'; '[e-mail]'
> > >>> Subject: RE: Self-Managed Networks
> > >>>
> > >>> Sorry for the delay, it’s very busy at the moment here.
> > >>> To me, fault management refers generally to faults on the data
> > >>> plane, ie for
> > >> user traffic. I see that happening at some point as an autonomic
> > >> function (or several, for different aspects). Would you agree? Or
> > >> do you see that as a function inside the AN infrastructure?
> > >>> So my feeling is that function would reside on top of the
> > >>> infrastructure that
> > >> we’re currently defining. So, please have a look whether your
> > >> thoughts can be described as an autonomic function. I think they
> > >> probably
> > can.
> > >>> Then I suggest we do the same that we’re planning to do with the
> > >>> NMS
> > >> section, the model discussion, etc: Have a short paragraph describe
> > >> the overall topic briefly, and point to an external doc for now,
> > >> i.e., probably your draft.
> > >>> If you agree, can you suggest where in the reference model you
> > >>> would add
> > >> a short paragraph about fault management, and I suppose we’d point
> > >> to your draft, right?
> > >>> Michael
> > >>>
> > >>>
> > >>> From: Toy, Mehmet [mailto:[e-mail]]
> > >>> Sent: 13 October 2015 03:53
> > >>> To: Michael Behringer (mbehring)
> > >>> <[e-mail]<mailto:[e-mail]>>
> > >>> Cc: '[e-mail]'
> > >>> <[e-mail]<mailto:[e-mail]>>;
> > >>> '[e-mail]'
> > >>> <[e-mail]<mailto:[e-mail]>>;
> > >>> '[e-mail]'
> > >>> <[e-mail]<mailto:[e-mail]>>;
> > >>> '[e-mail]'
> > >>> <[e-mail]<mailto:[e-mail]>>
> > >>> Subject: RE: Self-Managed Networks
> > >>>
> > >>> Mike,
> > >>> I am waiting for your response.
> > >>> Thanks
> > >>> Mehmet
> > >>>
> > >>> From: Toy, Mehmet
> > >>> Sent: Friday, October 09, 2015 8:13 PM
> > >>> To: '[e-mail]'
> > >>> Cc: '[e-mail]'; '[e-mail]'; 'anima-
> > >> [e-mail]'; '[e-mail]'
> > >>> Subject: RE: Self-Managed Networks
> > >>>
> > >>> Mike,
> > >>> I can send you some text to include in section 2 and 4 of  “A
> > >>> Reference
> > >> Model for Autonomic Networking,   draft-behringer-anima-reference-
> > >> model-03”,  per Sheng’s suggestion.
> > >>> Should I just do that?
> > >>> Thanks
> > >>> Mehmet
> > >>>
> > >>>
> > >>> From: Toy, Mehmet
> > >>> Sent: Thursday, October 08, 2015 7:53 AM
> > >>> To: '[e-mail]'; '[e-mail]';
> > >> '[e-mail]'; '[e-mail]'
> > >>> Cc: '[e-mail]'
> > >>> Subject: Re: Self-Managed Networks
> > >>>
> > >>> Sheng,
> > >>> Appreciate a quick response.
> > >>> I will work on your suggestion.
> > >>> Mehmet
> > >>>
> > >>>
> > >>> From: Sheng Jiang [mailto:[e-mail]]
> > >>> Sent: Thursday, October 08, 2015 06:08 AM Eastern Standard Time
> > >>> To: Toy, Mehmet;
> > >>> [e-mail]<mailto:[e-mail]>
> > >>> <[e-mail]<mailto:[e-mail]>>;
> > >>> [e-mail]<mailto:[e-mail]>
> > >>> <[e-mail]<mailto:[e-mail]>>;
> > >>> [e-mail]<mailto:[e-mail]>
> > >>> <[e-mail]<mailto:[e-mail]>>
> > >>> Cc: Romascanu, Dan (Dan)
> > >>> ([e-mail]<mailto:[e-mail]>)
> > >>> <[e-mail]<mailto:[e-mail]>>
> > >>> Subject: RE: Self-Managed Networks
> > >>>
> > >>> Hi, Toy,
> > >>> First of all, for my understanding, your work is in the scope of
> > >>> the WG
> > >> charter. However, we do not have work item or milestone for it. It
> > >> looks like an upper-layer autonomic service agent for me. In our
> > >> plan, autonomic service agents are mainly for the next period,
> > >> which is after re-charter (this is the same with your suggestion of
> > >> modifying the charter, but it cannot happen until we deliver the
> > >> current milestones). For now, the best may be try to add some
> > >> description, maybe mainly abstracted functionality, into the
> > >> reference
> > model document.
> > >>> Best regards,
> > >>> Sheng
> > >>>
> > >>> From: Toy, Mehmet [mailto:[e-mail]]
> > >>> Sent: Tuesday, October 06, 2015 1:14 AM
> > >>> To:
> > >>> [e-mail]<mailto:[e-mail]>;
> > >>> [e-mail]<mailto:[e-mail]>;
> > >>> [e-mail]<mailto:[e-mail]>
> > >>> Cc: Romascanu, Dan (Dan)
> > >>> ([e-mail]<mailto:[e-mail]>)
> > >>> Subject: Self-Managed Networks
> > >>>
> > >>> Dear All:
> > >>> I couldn’t attend the Prague meeting, but luckily Dan was able to
> > >>> present
> > >> my slides on “Self-Managed Networks with Fault Management
> > Hierarchy”.
> > >> The feedback was to position the work in the ANIMA WG scope and
> > >> framework.
> > >>>
> > >>> ANIMA charter in “M. Behringer, et. al., A Reference Model for
> > >>> Autonomic
> > >> Networking
> > >>> draft-behringer-anima-reference-model-03” refers to “self-healing”.
> > >> RFC7575,  “M. Behringer, et al.,   Autonomic Networking: Definitions
> and
> > >> Design Goals”,  refers to “self-management”. However, both
> > >> documents do not  articulate fault management aspect of the
> self-management.
> > >> It is possible to interpret the fault management aspect of
> > >> autonomic networks as part of “self-healing” and therefore as part
> > >> of the ANIMA charter.  In that case, the “Architectural Framework
> > >> for Self-Managed Networks with Fault Management Hierarchy,
> > >> draft-mtoy-anima-self-faultmang-framework-
> > >> 00.txt” contribution can target to fill that gap.  The control
> > >> plane aspect of self-healing is addressed by “M. Behringer, et al.,
> > >> An Autonomic Control Plane,
> > >> draft-behringer-anima-autonomic-control-plane-03”.  I believe these
> > >> contributions are complementary to each other. I can try to address
> > >> that
> > in the contribution.
> > >>>
> > >>> Please let me know if you agree with me. If not, I suggest to
> > >>> modify the
> > >> charter since without covering fault management aspect of the
> > >> autonomic networks, the concept of autonomic network will be
> > incomplete.
> > >>>
> > >>> Regards,
> > >>> Mehmet
> > >>>
> > >>>
> > >>
> > >>
> > >> _______________________________________________
> > >> Anima mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/anima
>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>



-- 
regards,
John