Subject: [Anima] weekly call #1 - minutes

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 20 Aug 2014 14:53:23 +0200

Dear all,

the minutes of our first weekly call have been posted on the wiki:
http://trac.tools.ietf.org/bof/anima/trac/attachment/wiki/PrepMeetings/ANIMA%20weekly%20call%201%20-%20minutes.txt

and are attached to this message for your convenience.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 NOZAY | France

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 20 Aug 2014 22:34:44 +0000

Laurent, all,

Many thanks for the minutes and keeping us informed. Reading v06 of the charter is that the text still gives the impression of avoiding some critical aspects directly related to this effort:

1) Which information dissemination model(s) is/are missing preventing self-configuration to operate: take OSPF as this group considers it is autonomic (while it isn't, cf. previous post) its mode of information distribution is push-based -> question which case(s) require pulling information to operate with OSPF, which case(s) do not require that all nodes (not only neighbors) be informed by a flooding of information (would a MT approach be suited instead), etc.

2) The charter refers to "generic discovery/negotiation protocols" though it would be more appropriate to refer to unified protocols (otherwise the goal of functions have their own discovery, transport, messaging and security mechanisms could not be achieved), in the solution targeted by the charter we already see the difficult compromise/tradeoffs in between unification and "security" by isolation ("a secure and logically seperated communications channel" ... why not separate processes/memory segments in that case ?) this coins at one important element is it possible to target only self-configuration without self-protection related aspects.

3) Let's assume such unified protocol can be defined is it expected to run across routing partitions or not, administrative partitions or not ? the notion of "guidance" classically known as the objective opens the question of whether or not autonomics aims at modifying the  boundaries of current autonomous systems (it can be at the sub-scale but also the super-scale).
Further, are the head-/tail-end of these interfaces co-resident with the forwarding/routing engine ("nodes") or not ? could we assume some of the interfaces would end on entities which are not currently part of the routing system ?
 
4) The charter mentions " Future work may include a more detailed systems architecture to support the development of autonomic service agents" and further "In addition, autonomic service agents will need to be defined to solve specific use cases." ... a priori contradictory but pointing at one of the most fundamental questions imho: is integration of autonomics going to be "per node and cross-function" or "per-function and cross-nodes" or a combination. 

5) As surprising as it looks like, little is said about the input to the autonomic process is it limited to the information protocols currently operate or other sources of information are also in scope (example: feeding 'automatically' routing decision process with traffic monitoring or forwarding monitoring).

Many thanks,
-dimitri.

From: Anima [mailto:[email-masked]] On Behalf Of Laurent Ciavaglia
Sent: Wednesday, August 20, 2014 2:53 PM
To: anima
Subject: [Anima] weekly call #1 - minutes

Dear all,

 
Laurent Ciavaglia
 
phone: +33 160 402 636 
email: [email-masked]
linkedin: laurentciavaglia
address: Route de Villejust | 91620 NOZAY | France

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Aug 2014 11:08:47 +1200

Dimitri,

Some personal opinions follow:

On 21/08/2014 10:34, Papadimitriou, Dimitri (Dimitri) wrote:
> Laurent, all,
> 
> Many thanks for the minutes and keeping us informed. Reading
> v06 of the charter is that the text still gives the
> impression of avoiding some critical aspects directly related
> to this effort:
> 
> 1) Which information dissemination model(s) is/are missing
> preventing self-configuration to operate: take OSPF as this
> group considers it is autonomic (while it isn't, cf. previous
> post) 

We've modified that phrase in the draft charter.

> its mode of information distribution is push-based ->
> question which case(s) require pulling information to operate
> with OSPF, which case(s) do not require that all nodes (not
> only neighbors) be informed by a flooding of information
> (would a MT approach be suited instead), etc.

I don't understand why we need a general answer to that. As far
as I personally have an answer, the essential point is indeed
that AN functions require two-way communication to form some
sort of closed loop system, neither push nor pull and certainly
not flooding. Where an AN function interfaces to an existing
function, the details are different for each case and have to be
managed by the AN service agent.

> 
> 2) The charter refers to "generic discovery/negotiation
> protocols" though it would be more appropriate to refer to
> unified protocols (otherwise the goal of functions have their
> own discovery, transport, messaging and security mechanisms
> could not be achieved), 

Each AN service agent will have to solve some subset of the
general problems, won't it? So we can provide a generic toolset
for this. But we must co-exist with everything that already
exists, so I would expect the service agents to mix and match
between legacy and AN tools to achieve their goals.

> in the solution targeted by the
> charter we already see the difficult compromise/tradeoffs in
> between unification and "security" by isolation ("a secure
> and logically seperated communications channel" ... why not
> separate processes/memory segments in that case ?) 

(that would be an implementation choice)

Yes, unification of tools where possible and isolation where
desirable. I don't see a conflict there.

> this coins
> at one important element is it possible to target only
> self-configuration without self-protection related aspects.

They are orthogonal I think. But the AN service agents and
protocols themselves MUST be strongly protected, which is why
cryptographic identity is vital.

> 3) Let's assume such unified protocol can be defined is it
> expected to run across routing partitions or not,

Yes. It may even have to survive NAT.

> administrative partitions or not ? 

I think that's an open question for now. By default, not,
because of the scope of the trust anchor. But I could imagine
scenarios where we might want to cross admin boundaries.

> the notion of "guidance"
> classically known as the objective opens the question of
> whether or not autonomics aims at modifying the  boundaries
> of current autonomous systems (it can be at the sub-scale but
> also the super-scale). 

Do you mean AS in the BGP-4 sense, or something else?

> Further, are the head-/tail-end of
> these interfaces co-resident with the forwarding/routing
> engine ("nodes") or not ? could we assume some of the
> interfaces would end on entities which are not currently part
> of the routing system ?

Definitely. I would expect hosts, firewalls and load balancers
to play, for example. Any device in a SFC environment could play.

> 4) The charter mentions " Future work may include a more
> detailed systems architecture to support the development of
> autonomic service agents" and further "In addition, autonomic
> service agents will need to be defined to solve specific use
> cases." ... a priori contradictory but pointing at one of the
> most fundamental questions imho: is integration of autonomics
> going to be "per node and cross-function" or "per-function
> and cross-nodes" or a combination.

Personally I would say that if a given node (physical or
virtual) deals with N autonomic functions, it will logically
contain N autonomic service agents. However, why should we
exclude cases where different functions are in fact coupled
operationally, so would naturally be managed by the same service
agent? I don't see why we need to answer this question in the
abstract.

> 5) As surprising as it looks like, little is said about the
> input to the autonomic process is it limited to the
> information protocols currently operate or other sources of
> information are also in scope (example: feeding
> 'automatically' routing decision process with traffic
> monitoring or forwarding monitoring).

I don't think there are any limits. The answer will vary from
case to case.

All IMHO,

    Brian
> 
> Many thanks, -dimitri.
> 
> 
> From: Anima [mailto:[email-masked]] On Behalf Of
> Laurent Ciavaglia Sent: Wednesday, August 20, 2014 2:53 PM 
> To: anima Subject: [Anima] weekly call #1 - minutes
> 
> Dear all,
>

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 21 Aug 2014 01:06:49 +0000

Brian,

Here below answers/clarifications:

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, August 21, 2014 1:09 AM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: CIAVAGLIA, LAURENT (LAURENT); anima
> Subject: Re: [Anima] weekly call #1 - minutes
> 
> Dimitri,
> 
> > v06 of the charter is that the text still gives the impression of
> > avoiding some critical aspects directly related to this effort:
> >
> > 1) Which information dissemination model(s) is/are missing preventing
> > self-configuration to operate: take OSPF as this group considers it is
> > autonomic (while it isn't, cf. previous
> > post)
> 
> > its mode of information distribution is push-based -> question which
> > case(s) require pulling information to operate with OSPF, which
> > case(s) do not require that all nodes (not only neighbors) be informed
> > by a flooding of information (would a MT approach be suited instead),
> > etc.
> 
> I don't understand why we need a general answer to that. 

The charter doesn't state why there is a need for other communication channels and modes between nodes (via examples at this stage). The only argument comes from the observation "each protocol has its own interface/messaging" (yes indeed this is known), the charter doesn't motivate the need for building new generic one/why existing ones can't be used.

--Just to be clear: I am not arguing in favor or against, I just consider motivations should be explicit in a charter and that such kind of statement is already an outcome (a working assumption that would have to be validated).

> As far as I
> personally have an answer, the essential point is indeed that AN functions
> require two-way communication to form some sort of closed loop system,
> neither push nor pull and certainly not flooding. 

Not sure why pull couldn't be part of it but if you assume the communication channels and associated transactions run "on top of" (as it is the case apparently) this has two main consequences: how will a local agent know with which other agents it can communicate with --this is an instance of the unknown adjacency problem of overlay systems (manual configuration is not an answer since it is often not possible to anticipate with which other nodes this communication has to happen), another due to separation is oscillations and inconsistencies (the underlying protocol still processes information independently of information received from service agents).

> Where an AN function
> interfaces to an existing function, the details are different for each
> case and have to be managed by the AN service agent.
>
> > 2) The charter refers to "generic discovery/negotiation protocols"
> > though it would be more appropriate to refer to unified protocols
> > (otherwise the goal of functions have their own discovery, transport,
> > messaging and security mechanisms could not be achieved),
> 
> Each AN service agent will have to solve some subset of the general
> problems, won't it? So we can provide a generic toolset for this. But we
> must co-exist with everything that already exists, so I would expect the
> service agents to mix and match between legacy and AN tools to achieve
> their goals.

It boils down to the question whether the term "service agent" means an agent per service or not (the document from nmrg assumes it is per function only, cf. Section 2). By experience, the use of the term agent is a mean to hide complexity of the problem at hand, and such group is expected to address it.

> > charter we already see the difficult compromise/tradeoffs in between
> > unification and "security" by isolation ("a secure and logically
> > seperated communications channel" ... why not separate
> > processes/memory segments in that case ?)
> 

Why enforce separate channels then as part of the solution (cf.charter) ?

> Yes, unification of tools where possible and isolation where desirable. I
> don't see a conflict there.
> 
> > this coins
> They are orthogonal I think. But the AN service agents and protocols
> themselves MUST be strongly protected, which is why cryptographic identity
> is vital.

Is that not the level 1 of protection. I mean is it possible to build foundation for autonomic control plane while looking at such basic problem as it be disconnected from broader objectives associated to self-protection ? 

> > 3) Let's assume such unified protocol can be defined is it expected to
> > run across routing partitions or not,
> 
> I think that's an open question for now. By default, not, because of the
> scope of the trust anchor. But I could imagine scenarios where we might
> want to cross admin boundaries.
> 
> > the notion of "guidance"
> > classically known as the objective opens the question of whether or
> > not autonomics aims at modifying the  boundaries of current autonomous
> > systems (it can be at the sub-scale but also the super-scale).
> 

Yes.

> > these interfaces co-resident with the forwarding/routing engine
> > ("nodes") or not ? could we assume some of the interfaces would end on
> > entities which are not currently part of the routing system ?
> 
> Definitely. I would expect hosts, firewalls and load balancers to play,
> for example. Any device in a SFC environment could play.

OK.
 
> > 4) The charter mentions " Future work may include a more detailed
> > systems architecture to support the development of autonomic service
> > agents" and further "In addition, autonomic service agents will need
> > to be defined to solve specific use cases." ... a priori contradictory
> > but pointing at one of the most fundamental questions imho: is
> > integration of autonomics going to be "per node and cross-function" or
> > "per-function and cross-nodes" or a combination.
> 
> virtual) deals with N autonomic functions, it will logically contain N
> autonomic service agents. However, why should we exclude cases where
> different functions are in fact coupled operationally, so would naturally
> be managed by the same service agent? I don't see why we need to answer
> this question in the abstract.

Absolutely not what I am aiming at: 

- first your own document from nrmg assumes agents per function (look at Section 2) instead of putting both as possible design choices to be investigated (as it would be sensible to do) 
 
- second the distance between use cases and the goal of moving toward a common control plane is huge (as I read it from the charter), and it is difficult to see which of these questions these use cases will help answer (to provide guidance in the control plane document). Taken separately one doesn't need a "common control plane" to realize them --hence the articulation aspects should be part of the common work.

> > 5) As surprising as it looks like, little is said about the input to
> > the autonomic process is it limited to the information protocols
> > currently operate or other sources of information are also in scope
> > (example: feeding 'automatically' routing decision process with
> > traffic monitoring or forwarding monitoring).
> 
> I don't think there are any limits. The answer will vary from case to
> case.

OK. Nothing is stated in the charter concerning the "sources" of information such agents would cover --the reason is because nowadays the routing system is a closed system. Giving examples would certainly provide guidance as what's in scope or not.

> All IMHO,
> 
>     Brian
> >
> > Many thanks, -dimitri.
> >
> >
> > From: Anima [mailto:[email-masked]] On Behalf Of Laurent
> > Ciavaglia Sent: Wednesday, August 20, 2014 2:53 PM
> > http://trac.tools.ietf.org/bof/anima/trac/attachment/wiki/PrepMeetings
> > /ANIMA%20weekly%20call%201%20-%20minutes.txt
> >
> >