Re: [Anima] Self-Managed Networks

[Brian E Carpenter <[e-mail]>]

On 17/10/2015 04:35, Toy, Mehmet wrote:
> 
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]] 
> Sent: Friday, October 16, 2015 2:02 AM
> To: Toy, Mehmet; Michael Behringer (mbehring); [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.)

> MT:  Does that mean that ACP is for one AS? If it is, how do we deal with a network of multiple ASs?

An ACP is for one autonomic domain. If that isn't clear in the ACP draft, I'm sure
Michael will fix it.

> 
>> 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.
> MT:  Does this mean Autonomous nodes are part of a layer above "infrastructure (i.e. operational data plane)"?  If it is what is that layer? Is it part of a control plane?

AutonomIC Nodes form a control plane, indeed. We expect that it will co-exist with
traditional control planes in the real world.

>>
>> 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.
> MT: OK, then why are not we using "infrastructure" terminology? Is ACP above the infrastructure? 

Does it matter? It's a virtual layer that happens to run over link-local
packets, so doesn't depened on the data plane layer 3.

    Brian

>> 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.
> MT: I will talk to Toerless this afternoon to make sure I fully understand the approach.  However, it could be useful to pick a network of 4 nodes (2 PEs and 2Ps) and clearly  indicate what functions constitute an ACP and what functions constitute ASs,
> 
> 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
> 
>