Subject: Re: [Anima] AN and I2RS

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 2 Sep 2014 18:48:37 +0000

Dimitri,

Autonomic agent has to receive intent, communicate with other devices and device where it is located. All this communication is done via interface. So to communicate with the local device, for notifications and config changes, what is the best way to do it? I2RS is looking to provide an interface over which notifications, as well config  changes can be sent.

>From architectural pov, autonomic agent is I2RS client. It is perfectly fine that both are on the same device.

Dean

On Aug 30, 2014, at 12:49 PM, "Papadimitriou, Dimitri (Dimitri)" <[email-masked]> wrote:

> The goal of I2RS is different as I see its architecture doc. I2RS approach is "information-driven" (link together different information bases, monitoring, topology, routing, etc. descriptors), I2RS agents push descriptions to an entity which relates all this information together. There is an implicit assumption behind IR2S assumes that the structure of a model is fixed
> 
> AN agents do not decide from full information acquisition but based on cooperation logic. This leads to a completely different class of language (or protocol) among agents. Such protocol comprises exchange beliefs, goals, actions, etc.
> 
> Thanks,
> -dimitri.
> 
>> -----Original Message-----
>> From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
>> Sent: Wednesday, August 27, 2014 10:10 PM
>> To: Dean Bogdanovic
>> Cc: Jéferson Campos Nobre; [email-masked]; Michael Behringer (mbehring)
>> Subject: Re: [Anima] AN and I2RS
>> 
>> On 28/08/2014 05:04, Michael Behringer (mbehring) wrote:
>>>> -----Original Message-----
>>>> From: Dean Bogdanovic [mailto:[email-masked]]
>>>> Sent: 27 August 2014 06:28
>>>> To: Michael Behringer (mbehring)
>>>> Cc: Jéferson Campos Nobre; [email-masked]
>>>> Subject: Re: [Anima] AN and I2RS
>>>> 
>>>> Michael,
>>>> 
>>>> I'm back to my normal schedule and catching up with emails, so a
>>>> delayed reply.
>>>> 
>>>> I agree with many of the statements you made and I understand the
>>>> goals of ANIMA, but what protocols will ANIMA use for communication?
>>>> That same question is asked by I2RS. What protocol to use between
>>>> I2RS client and I2RS agent? From I2RS perspective, a single I2RS
>>>> client can talk to multiple I2RS agents, so from a single client you
>>>> can instruct multiple devices. So you can instruct I2RS client to use
>>>> OSPF and I2RS client will instruct all I2RS agents to configure OSPF.
>>> 
>>> Which protocols to pick is the job of the working group. If a suitable
>> protocol exists, we should of course not invent a new one.
>> 
>> My thinking on this is that the nature of communication is a little
>> different in AN than in all traditional management, monitoring or
>> configuration solutions. It is really peer to peer (as mentioned in some
>> recent mail with Dimitri, it is part of a closed-loop process). So the
>> protocol carrying the communication really needs to be symmetrical rather
>> than command-response.
>> 
>> We did some analysis of existing protocols in
>> http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-03#section-3
>> That perhaps needs to be further developed. Does I2RS have a statement of
>> requirements for its protocol choice?
>> 
>>   Brian
>> 
>>>> Please see more inline
>>>> 
>>>> Dean
>>>> 
>>>> On Aug 6, 2014, at 12:50 PM, Michael Behringer (mbehring)
>>>> <[email-masked]> wrote:
>>>> 
>>>>> Dean,
>>>>> 
>>>>> To the relationship between ANIMA and I2RS:
>>>>> 
>>>>> To me, the difference is simple, and relates to the interface
>>>>> between what
>>>> I2RS calls the agent and the client :
>>>>> - I2RS (as well as general SDN approaches) focus on guidance for the
>>>> specific element in question. Example: "node x: for prefix y, set next
>> hop z".
>>>>> - In Autonomics, you do NOT provide guidance for a specific element,
>>>>> but
>>>> to the entire network or a group of nodes. Example: "all BGP speakers:
>>>> Prefer SP 1 over SP2". or "this network runs OSPF".
>>>>> The way I see it, autonomics will set a default for the network,
>>>>> i2rs (and
>>>> other node specific methods, including CLI, SNMP, etc) set a more
>>>> specific guidance on a per node level.
>>>> 
>>>> but you can use I2Rs achieve that. Of course, we can work on a
>>>> completely new way to do it, but I believe that we have to look if
>>>> there are some mechanisms available and improve them.
>>> 
>>> And if there is an existing protocol that meets the specs, let's use it
>> of course.
>>> 
>>> Michael
>>> 
>>>>> This requires conflict resolution.
>>>>> 
>>>>> There are already a large number of ways to influence the behaviour
>>>>> of a
>>>> node: Netconf, CLI, SNMP, i2rs, ...). With autonomics, there are two
>> more:
>>>>> - the autonomic default behaviour of a node
>>>>> - the same, but influenced by intent, which is a network wide policy
>>>>> Anything node specific (above list) overrides the network wide
>> behaviour.
>>>>> 
>>>>> This way, autonomics can set a network wide default behaviour,
>>>>> possibly
>>>> controlled by intent, and i2rs and the other mechanisms define
>>>> exceptions where needed.
>>>> 
>>>> in i2rs you have two layers one if i2rs client and one is i2rs agent.
>>>> So I can see that i2rs client translates intent into actions that are
>>>> enforced by i2rs agent on the device.
>>>>> This is similar to the behaviour of an IGP: The default IGP sets the
>>>>> general routing, a local static route for example provides a local
>>>>> override. (Note well: ... and is a really good way to mess up an
>>>>> otherwise stable and deterministic network)
>>>> :-)
>>>> 
>>>>> See also what I wrote in NMRG:
>>>>> http://www.ietf.org/mail-archive/web/nmrg/current/msg01580.html
>>>>> 
>>>>> [side question: To me it is clear that autonomics / intent are
>>>>> overridden by all node specific mechanisms. But I don't have clear
>>>>> how those are prioritised between themselves? The i2rs architecture
>>>>> doc makes a vague statement that " policy can determine whether
>>>>> Local Config overrides a particular I2RS client's request or vice
>> versa."
>>>>> Personally I think there should be a pre-defined priority list, but
>>>>> that's for another discussion.]
>>>>> 
>>>>> Now, autonomics as well as i2rs needs an agent for this messaging.
>>>>> So far, I
>>>> see that as a separate agent, since the interactions may be
>>>> different; but, need to think more about that. Compare figure 1 of
>>>> draft-ietf-i2rs-
>>>> architecture-05 with figure 1 of draft-irtf-nmrg-autonomic-network-
>>>> definitions-01. The autonomic user agent is similar to the i2rs
>>>> agent. It interprets intent, and does the messaging for external
>>>> feedback loops. How would you see that?
>>>> Yes, I agree with that, but how will the autonomic agent communicate
>>>> the intent to the device? Autonomic agent will have to configure the
>>>> device. Do you see that autonomic agent will write into persistent
>>>> data storage on the device or transient
>>>> 
>>>>> Does the above make sense? Should we maybe include a statement like
>>>> this in the ANIMA charter?
>>>> We have to think about how the intent is communicated to the device
>>>> and how to store the result of the intent.
>>>>> More inline...
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Anima [mailto:[email-masked]] On Behalf Of Dean
>>>>>> Bogdanovic
>>>>>> Sent: 05 August 2014 17:45
>>>>>> To: Jéferson Campos Nobre
>>>>>> Cc: [email-masked]
>>>>>> Subject: Re: [Anima] AN and I2RS
>>>>>> 
>>>>> [...]
>>>>>>> Do you mean the I2RS agent? For me it seems the Autonomic
>>>> Networking
>>>>>>> Service Agent is closer to the I2RS agent (not the routing element
>>>>>>> as a whole). However, considering this means that the AN agent
>>>>>>> would need to speak the I2RS protocol.
>>>>>> Adding intelligence to I2RS agent is something very desirable, as
>>>>>> the multiple I2RS clients will talk to the same I2RS agent and the
>>>>>> agent will have to make decisions, without having always connection
>>>>>> to the client. For I2RS we are considering NETCONF/RESTCONF as a
>> protocol.
>>>>>> Another protocol that is interesting for AN is DLEP
>>>>>> (draft-ietf-manet-dlep- 05). It provides discovery and information
>>>> collection mechanism about links.
>>>>> I'm not sure whether the agent should do conflict resolution.
>>>>> Conflicts
>>>> have to be resolved between a wide range of "configuration" models,
>>>> should thus sit logically below all those agents. In my head, there
>>>> is an agent per approach, one for i2rs, one for AN, one for CLI, ...
>>>> and below that is conflict resolution.
>>>> 
>>>> I'm not sure about one agent per approach. I see more that AN can use
>>>> I2RS agent or some other agent to change the behavior of the device.
>>>>>>>> We could also wonder whether I2RS isn't a nice AN use case, but
>>>>>>>> it's very complex - the I2RS WG itself is deep into multiple use
>>>>>>>> case analysis and information model development - to say it
>>>>>>>> bluntly, ANIMA doesn't need that much complexity right now ;-).
>>>>>> Well, AN needs to talk to routing system to collect information. So
>>>>>> instead of creating a parallel mechanism, why not to join forces
>>>>>> with I2RS and find if other requirements are needed to satisfy AN use
>> cases.
>>>>> I can see an autonomic service agent having to get routing info from
>>>>> the
>>>> box, but that is an internal mechanism. I do not right now see a case
>>>> where an autonomic service agent would talk to an i2rs agent on
>>>> another box. I would rather see the AN agents on both boxes talk to
>>>> each other, and the interface to the routing system being internal to
>> that box. Thoughts?
>>>> 
>>>> that makes sense. please see my above comment on this.
>>>> 
>>>> Dean
>>>> 
>>>>>>> BTW, I think the I2RS use case requirements I-D
>>>>>>> (http://tools.ietf.org/html/draft-hares-i2rs-usecase-reqs-summary-
>>>>>>> 00
>>>>>>> ) can be an example for an integrated use case I-D for ANIMA. They
>>>>>>> also have several use cases and this I-D gives a consistent view
>>>>>>> of them regarding the WG (e.g., classes of use cases).
>>>>>> I agree with Jeferson on this and based on such a draft we can see
>>>>>> if there is any overlap with I2RS requirements.
>>>>> Need to read that draft. But I would return to my previous
>>>>> statement: AN
>>>> is not about direct node programming, but to a large extent about
>>>> horizontal interfaces, with a minimal northbound interface. Many use
>>>> cases can be solved in either way. AN is specifically looking at use
>>>> cases where horizontal communication is a MUST or a big advantage.
>>>>> Expressed differently: If i2rs has a use case and a good, generally
>>>>> accepted
>>>> solution for that use case, then maybe it's not a good use case for
>>>> AN to start with. AN should focus on use cases where distribution (ie
>>>> horizontal
>>>> communication) is a big advantage or even a MUST.
>>>>> The AN bootstrap use case is a good example: you can't solve that
>>>>> through
>>>> a northbound method like i2rs, because it's exactly about deriving
>>>> the key material to establish this northbound communication in the
>> first place.
>>>> ANIMA should focus on that type of use case initially, I think.
>>>>> Michael
>>>>> 
>>>>>>>> I think it is far too soon to even hypothetically consider
>>>>>>>> whether I2RS and AN have overlapping protocol requirements. I2RS
>>>>>>>> has a line its charter:
>>>>>>>> 
>>>>>>>>> - An analysis of existing IETF and other protocols and encoding
>>>>>>>>> languages against the requirements.
>>>>>>>> but I don't see any sign of an active draft on that topic.
>>>>>>> Probably it would be also good to have this kind of analysis for
>>>>>>> ANIMA. For example, an alternative for CDNP was mentioned during
>>>>>>> the BoF, thus at least the IETF alternatives protocols/mechanisms
>>>>>>> (if they
>>>>>>> exist) should be cited in the ANIMA I-Ds.
>>>>>>> 
>>>>>>>> Unfortunately I didn't get a chance to talk with any of the I2RS
>>>>>>>> protagonists during the IETF. If anybody here can comment
>>>>>>>> further, please do so.
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>>  Brian
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Anima mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>>>> _______________________________________________
>>>>>>> Anima mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>>> _______________________________________________
>>>>>> Anima mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/anima
>>> 
>>> _______________________________________________
>>> Anima mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/anima
>>> 
>> 
>> _______________________________________________
>> Anima mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/anima