Subject: Re: [Anima] I-D Action: draft-boucadair-network-automation-requirements-04.txt

From: <[email-masked]>
Date: Fri, 12 Sep 2014 13:13:54 +0000

Hi Brian,

I'm sharing this discussion in the list fwiw.

Cheers,
Med

>-----Message d'origine-----
>De : Brian E Carpenter [mailto:[email-masked]]
>Envoyé : mardi 9 septembre 2014 21:56
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : JACQUENET Christian IMT/OLN; draft-boucadair-network-automation-
>[email-masked]
>Objet : Re: I-D Action: draft-boucadair-network-automation-requirements-
>04.txt
>
>Med and Christian,
>
>Thanks for your comments. Of course it's understood that management
>control is needed and that's why the "policy intent" is included
>in our ideas. There is a big open question about the granularity
>of that - personally I view it as very similar to setting
>defaults and limits as a starting point for autonomic operations,
>but I'm not sure everyone agrees to that.
>
>You mention two interesting points - rigid algorithms in the
>devices that might be a problem later, and deskilling of the staff.
>I think those risks can be limited, but they are definitely worth
>discussion.
>
>We are trying to avoid "boiling the ocean" in the charter and
>that means limiting our ambitions. Any help in converging on
>a realistic charter would be most helpful, in public or in private.
>
>Regards
>   Brian
>
>On 09/09/2014 21:40, [email-masked] wrote:
>> Hi Brian,
>>
>> FWIW, attached a short text about the importance of determinism in
>network automation.
>>
>> You will see a diagram that tries to captures the main steps in the
>service lifecycle. Tuning the network to deliver a service that meet the
>service objectives is not so that obvious. Adopting an incremental approach
>to graft autonomic techniques in an operational network seems to be a key
>requirement.
>>
>> There are tasks that can be delegated easily compared to others. A
>typical example would be the discovery of network topology, network
>elements capabilities, connectivity provisioning of the underlying network
>while ensuring that only authorized devices are allowed to be part of the
>underlying automated/autonomic infrastructure. There were some proposals
>that distribute for instance prefix delegation but those IMHO are not
>stable, lead to a waste of addressing resources, or may even lead to
>failure if the delegated pools are not sufficient to cover a hierarchical
>network. We already documented proposals for automated and distributed
>network configuration and topology discovery that relies on one or many
>centralized entity.
>>
>> We investigated in the past to what extent autonomous techniques
>(autonomous systems was the term used in that time can be helpful for
>service supervision with a focus on VoIP. My conclusions at that time is
>that there are some points that may be a barrier for the service
>evolutions. For example in order to deploy autonomic service supervision,
>the service logic should be "hardcoded" somewhere and any change of the
>service delivery logic would lead to error in the autonomic supervision
>unless that update/change is reflected in the "hardcoded" part of the
>service supervision. Another item we considered is the impact on skills and
>how to exit from an autonomous behavior to a human-driven approach for
>service diagnosis and troubleshooting purposes...I have published some of
>the proposals to include more autonomous behavior, for example,
>http://rd.springer.com/chapter/10.1007%2F978-0-387-89828-5_7
>>
>> Saying that, it is really promising to see this topic socialized within
>IETF.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : [email-masked]
>[mailto:[email-masked]]
>>> Envoyé : mardi 9 septembre 2014 11:11
>>> À : [email-masked]
>>> Cc : [email-masked]
>>> Objet : TR: I-D Action: draft-boucadair-network-automation-requirements-
>>> 04.txt
>>>
>>> Dear Brian,
>>>
>>> Med forwarded your message yesterday (I didn't receive the message sent
>to
>>> [email-masked], for some
>>> reason). A couple of comments inline from my side.
>>>
>>> [snip]
>>> I would like to ask you how you situate your draft against the emerging
>>> work on autonomic networking. In particular, you say
>>>
>>>>    Configuration information must be provided to the participating
>>>>    devices by means of a protocol to be used between such devices and a
>>>>    presumably centralized manager entity.  The latter can be seen as a
>>>>    decision point where configuration information is stored, maintained
>>>>    and updated whenever required.
>>> whereas in the draft charter for the proposed Anima WG we say
>>>
>>>> Autonomic Networking focuses on self-management of network elements,
>>>> often involving closed-loop control. An autonomic function works in a
>>>> distributed way across various network elements, but allowing central
>>>> guidance and reporting, and co-existence with non-autonomic methods of
>>> management.
>>> ...
>>>> Autonomic networking is intended
>>>> to mitigate ... duplication of similar mechanisms and heavy dependency
>>>> on human actions, in particular by facilitating secure closed-loop
>>>> interaction directly between network elements to satisfy management
>>> intent.
>>>
>>> Now this may seem radically different,
>>> [CJ] I think the " but allowing central guidance and reporting, and co-
>>> existence with non-autonomic methods of management" part of the current
>>> anima draft charter suggests some commonality with what we documented in
>>> our requirements draft so far. from an operational standpoint, I believe
>a
>>> smart combination of autonomic networking features with PDP capabilities
>>> makes sense, depending on the nature (and presumably the range) of
>>> connectivity services supported by the (autonomic) networking
>>> infrastructure. In addition, the ability to progressively introduce
>>> autonomic features in a network composed of legacy routing systems also
>>> suggests the need for some (logically) centralized decision point to
>>> facilitate the introduction of a high level of automation in the overall
>>> service delivery procedure.
>>>
>>> but your list of "Issues Raised by Configuration Operations" is exactly
>>> the motivation for autonomic networking. Wouldn't you prefer the network
>to
>>> manage itself in detail, rather than having a centralised decision point
>>> (that rather reminds me of SNA sys-gen, for those with long memories)?
>>>
>>>
>>> [CJ] We're some kind of control freaks :-) Leave the network manage
>itself
>>> is not sufficient to address service fulfillment and assurance
>>> considerations for one: I believe there is a need to make sure that the
>>> resources that have been allocated (possibly in an autonomic fashion),
>and
>>> the (service-derived) policies that are enforced by the network devices
>>> comply with what may have been dynamically negotiated with the customer
>>> (see RFC 7297 for more the details about the scope of such negotiation).
>>> For that reason (but there may be other reasons that are specific to the
>>> operational procedures enforced by a service provider), I think there is
>a
>>> need for coordination and consistency between autonomic devices (and the
>>> decisions they make) and some kind of centralized intelligence we call
>PDP.
>>> I also believe determinism is key to minimize the risk of mad robot
>>> situations.
>>>
>>> I'd be interested in your opinions.
>>>
>>> (I don't see any of you subscribed to the Anima list:
>>> https://www.ietf.org/mailman/listinfo/anima.
>>> There is also a wiki:
>>> http://trac.tools.ietf.org/bof/anima/trac/wiki/WikiStart)
>>> [CJ] I have subscribed yesterday and had the opportunity to briefly
>review
>>> one of the drafts (Jiang's) mentioned in the draft charter. I think
>anima
>>> is very interesting initiative which I will support.
>>>
>>> Kind regards,
>>>
>>> Christian.
>>>
>>>
>>>
>___________________________________________________________________________
>>> ______________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu
>>> ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>>> electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme
>ou
>>> falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged
>>> information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and
>>> delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have
>been
>>> modified, changed or falsified.
>>> Thank you.
>>