Subject: Re: [Anima] AN and I2RS

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 5 Aug 2014 15:45:02 +0000

Brian,

I was the one suggesting to look into synergies with i2rs, as I'm active in the i2rs wg and have interest in UCAN BoF.

Please see inline comments

Dean

On Jul 30, 2014, at 12:50 AM, Jéferson Campos Nobre <[email-masked]> wrote:

> Hi,
> Inline comments.
> Cheers.
> Jéferson
> 
> On Sat, Jul 26, 2014 at 9:59 AM, Brian E Carpenter
> <[email-masked]> wrote:
>> Hi,
>> 
>> It was mentioned during the UCAN BOF that we should consider any
>> relationship to I2RS. While waiting to check out of the hotel
>> later this morning, I have quickly glanced at the I2RS architecture
>> (http://tools.ietf.org/html/draft-ietf-i2rs-architecture-05).
>> 
>> One aspect is how a future I2RS instance could interact with AN.
>> I2RS says:
>> 
>>>   Routing Element:   A Routing Element implements some subset of the
>>>      routing system.  It does not need to have a forwarding plane
>>>      associated with it.  Examples of Routing Elements can include:
>>> 
>>>      *  A router with a forwarding plane and RIB Manager that runs
>>>         ISIS, OSPF, BGP, PIM, etc.,
>>> 
>>>      *  A BGP speaker acting as a Route Reflector,
>>> 
>>>      *  An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a
>>>         forwarding plane and associated RIB Manager,
>>> 
>>>      *  A server that runs ISIS, OSPF, BGP and uses ForCES to control a
>>>         remote forwarding plane,
>>> 
>>>      A Routing Element may be locally managed, whether via CLI, SNMP,
>>>      or NETCONF.
>> 
>> So, I suppose we could argue that an I2RS Routing Element could act
>> as an Autonomic Networking Service Agent, i.e. it could act as an
>> interface between the routing system and AN, instead of being
>> traditionally managed.
> 
> 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.

> 
>> 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.
> 
> 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. 
> 
>> 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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 6 Aug 2014 16:50:13 +0000

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. 

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. 

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? 

Does the above make sense? Should we maybe include a statement like this in the ANIMA charter? 

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
> 
[...]
> > 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. 
 
> >> 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? 

> 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

> >> I2RS and AN have overlapping protocol requirements. I2RS has a line
> >> its charter:
> >>
> >> 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
> >>

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 27 Aug 2014 13:28:00 +0000

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.

Please see more inline

Dean

> 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.

> 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…

:-)

> 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 figur…
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.
> 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 h…

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.
> 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…

that makes sense. please see my above comment on this.

Dean

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 27 Aug 2014 17:04:21 +0000

> From: Dean Bogdanovic [mailto:[email-masked]]
> Sent: 27 August 2014 06:28
> To: Michael Behringer (mbehring)
> Cc: Jéferson Campos Nobre; [email-masked]
> 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. 
 
> > - 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
 
> > 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:
> > 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)
> 
> :-)
> 
> >
> > [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
> 
> >>> 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.
> >>
> >> 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?
> 
> >>> (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
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Aug 2014 08:10:16 +1200

> 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

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 28 Aug 2014 15:36:52 +0000

> of requirements for its protocol choice?

I'm just working on that draft what is needed from netmod and netconf wg, but we are thinking about using RESTCONF for I2RS and we have to figure out what would be the best way  for notification mechanism, as agents have to notify clients about changes in the routing system.

Dean

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 30 Aug 2014 16:49:28 +0000

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.

> 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)
> >> 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.
> 
> That perhaps needs to be further developed. Does I2RS have a statement of
> requirements for its protocol choice?
> 
>    Brian
> 
> >> Please see more inline
> >>
> >> Dean
> >>
> >>> To me, the difference is simple, and relates to the interface
> >>> between what
> >> I2RS calls the agent and the client :
> >> 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.
> >
> >> 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.
> >>> 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."
> >> 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-
> >> 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
> >>
> >> We have to think about how the intent is communicated to the device
> >> and how to store the result of the intent.
> >>> More inline...
> >>>
> >>>>> 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.
> >> 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.
> >>>> 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.
> >> 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?
> >>
> >>>>> 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.
> >> 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.
> >> 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
> >> a northbound method like i2rs, because it's exactly about deriving
> >> the key material to establish this northbound communication in the
> first place.
> >>>>>> 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:
> >>>>>>
> >>>>> ANIMA. For example, an alternative for CDNP was mentioned during
> >>>>> the BoF, thus at least the IETF alternatives protocols/mechanisms
> >>>>> (if they
> >>>>>> protagonists during the IETF. If anybody here can comment
> >>>>>> further, please do so.
> >>>>>>
> >>>>>> Regards
> >>>>>>   Brian
> >>>>>>