Subject: [Supa] Slide set

From: Tina TSOU <[email-masked]>
Date: Tue, 3 Feb 2015 16:10:19 +0000

Dear all,

The slide set needs some work.

Regarding option 1, Raghu's opinion is added in the attached slide, pl. let us know your thoughts.

BTW, we need to choose between option 1 or 2, only use one. Any thoughts?

Wrt policy, I think we can do some use case specific policy, for example, Site Position Based Policy.

Thank you,
Tina

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Feb 2015 18:09:16 +0100

> BTW, we need to choose between option 1 or 2, only use one. Any thoughts?

This is a more detailed version of option 1, clarifying that the
policy interpretation happens at the network manager. Of course, this
raises the question how service and policy data models will be
accessed by the policy agent: Is the data "pushed" to the agent,
"pulled" by the agents, is there "pub/sub" mechanism, ...? And of
course, which component is dealing with policy conflicts? These
questions were more clearly hidden in the original simplified version
of option 1 (but then having these questions and trying to answer them
is actually forward progress and thus goodness). So I would move
forward Raghu's version.

I am, however, still unsure what the SUPA arrow is supposed to
mean. It may be read as "we want to do protocol work", an impression
which I think we should try to avoid as much as possible.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Tina TSOU <[email-masked]>
Date: Tue, 3 Feb 2015 17:18:04 +0000

Dear Juergen,

Comments are in line...

Thank you,
Tina

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2015 1:09 AM
To: Tina TSOU
Cc: [email-masked]; Masaki Fukushima; [email-masked]; [email-masked]; Keisuke Kuroki
Subject: Re: [Supa] Slide set

> BTW, we need to choose between option 1 or 2, only use one. Any thoughts?

This is a more detailed version of option 1, clarifying that the policy interpretation happens at the network manager. Of course, this raises the question how service and policy data models will be accessed by the policy agent: Is the data "pushed" to the agent, "pulled" by the agents, is there "pub/sub" mechanism, ...? And of course, which component is dealing with policy conflicts? These questions were more clearly hidden in the original simplified version of option 1 (but then having these questions and trying to answer them is actually forward progress and thus goodness). So I would move forward Raghu's version.

I am, however, still unsure what the SUPA arrow is supposed to mean. It may be read as "we want to do protocol work", an impression which I think we should try to avoid as much as possible.

[TT] When we have YANG models, the APIs are almost there, no?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Feb 2015 18:28:07 +0100

> [TT] When we have YANG models, the APIs are almost there, no?

I am not sure what you refer to. Traditional NETCONF/RESTCONF assumes
a push model. There are pub/sub extensions brewing in I2RS, there is
the NETCONF mount proposal. This is all not worked out. Looking back
into last century, we talked about policy decision points and policy
repositories and to some extend the 'Network Manager' with an embedded
policy agent looks like a policy decision point receiving input from a
policy repository. Back in those days, people assumed that there is a
push mechanism or a directory-enabled mechanism to access the
repository. For those who missed those days, it might be useful to
read RFC 3198 (and there is of course the question whether we want to
borrow terminology from there or whether we have to use better / more
fancy terms these days).

/js

---

From: Tina TSOU <[email-masked]>
Date: Tue, 3 Feb 2015 17:30:46 +0000

Dear Juergen,

In line...

Thank you,
Tina

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2015 1:28 AM
To: Tina TSOU
Cc: [email-masked]; Masaki Fukushima; [email-masked]; [email-masked]; Keisuke Kuroki
Subject: Re: [Supa] Slide set

On Tue, Feb 03, 2015 at 05:18:04PM +0000, Tina TSOU wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

I am not sure what you refer to. Traditional NETCONF/RESTCONF assumes a push model. There are pub/sub extensions brewing in I2RS, there is the NETCONF mount proposal. This is all not worked out. Looking back into last century, we talked about policy decision points and policy repositories and to some extend the 'Network Manager' with an embedded policy agent looks like a policy decision point receiving input from a policy repository. Back in those days, people assumed that there is a push mechanism or a directory-enabled mechanism to access the repository. For those who missed those days, it might be useful to read RFC 3198 (and there is of course the question whether we want to borrow terminology from there or whether we have to use better / more fancy terms these days).

[TT1] I refer to "> I am, however, still unsure what the SUPA arrow is supposed to mean. It may be read as "we want to do protocol work", an impression which I think we should try to avoid as much as possible."
Is API a "protocol work"?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Feb 2015 18:40:49 +0100

In line...

> Is API a "protocol work"?

We propose to do data models. They reflected in the figure. I believe
the arrow has no purpose and it can trigger questions we do not
want. I do not understand why you want an API discussion. I though we
decided we do data models.

/js

---

From: <[email-masked]>
Date: Tue, 3 Feb 2015 17:45:15 +0000

Hi Jorgen/Tina,

You are right, I was initially tempted to include some of these aspects but left off those details.

Following are just my thoughts, please feel free to comment/disagree on  it.

- Service layer express its intent from a service point of view over the interface (currently marked as SUPA), say provision a service with certain service attributes.

- Network management layer interprets the service request with the help of Policy Agent and translates it into network configuration using the network topology information it has and provisions the request to the network.

- It is assumed here that the Policy Agent itself is able to communicate with the Policy Manager (my opinion is that SUPA interface also defines this exchange of policies, potential conflict detection and resoution interface). More on the below...

- Other triggers could also be change in policies which impact already provisioned services, in such a case the policy manager broadcasts the changed policy (pub-sub model) to all policy agents and then they inform the network manager to take appropriate actions. Apart from pub/sub there might be a need to have a sync interface to query specific policy instance information from the agent towards the manager.

- There can be other triggers as well, a fault in the network that impacts a service etc, but the propagation of such triggers and associated analysis is out of scope of SUPA as it is part of regular fault management and serivce impact analysis.

- With respect to the scope, i think we should focus on defining a information model for the policy exchange between the policy manager and policy agent and a corresponding data model based on yang. The protocol specific aspects can be deferred to respective implementations. Also interms of the model we can define certain foundational concepts and leave it open for extension while we could provide a concrete example for a specific network technology and service, as what constitutes a policy could itself vary depending ont he context where it is used e.g. there could be tenant specific policies, site specific, network domain specific etc...

Br,
Raghu.

________________________________________
From: Juergen Schoenwaelder <[email-masked]>
Sent: Tuesday, February 3, 2015 5:09 PM
To: Tina TSOU
Cc: [email-masked]; Masaki Fukushima; Raghavendra Rao T (WT01 - Global Media & Telecom); [email-masked]; Keisuke Kuroki
Subject: Re: [Supa] Slide set

/js

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 4 Feb 2015 19:24:55 +0800

IMHO, there is another opinion on the position of policy data model in the
SUPA framework:

The policy data model is located in the "Service Management", and it is
mapped into service management data model in "Service Management", which
means the policy data model will not be sent to network manager/controller.

One reason for this is, the policy model may be very flexible and complex,
if it is sent to network manager/controller, the network manager/controller
will have to be more complex and intelligent.

Any thoughts?

Thanks,
Jun Bi

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 4, 2015 1:45 AM
To: Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Hi Jorgen/Tina,

You are right, I was initially tempted to include some of these aspects but
left off those details.

- Service layer express its intent from a service point of view over the
interface (currently marked as SUPA), say provision a service with certain
service attributes.

- Network management layer interprets the service request with the help of
Policy Agent and translates it into network configuration using the network
topology information it has and provisions the request to the network.

- It is assumed here that the Policy Agent itself is able to communicate
with the Policy Manager (my opinion is that SUPA interface also defines this
exchange of policies, potential conflict detection and resoution interface).
More on the below...

- Other triggers could also be change in policies which impact already
provisioned services, in such a case the policy manager broadcasts the
changed policy (pub-sub model) to all policy agents and then they inform the
network manager to take appropriate actions. Apart from pub/sub there might
be a need to have a sync interface to query specific policy instance
information from the agent towards the manager.

- There can be other triggers as well, a fault in the network that impacts a
service etc, but the propagation of such triggers and associated analysis is
out of scope of SUPA as it is part of regular fault management and serivce
impact analysis.

- With respect to the scope, i think we should focus on defining a
information model for the policy exchange between the policy manager and
policy agent and a corresponding data model based on yang. The protocol
specific aspects can be deferred to respective implementations. Also interms
of the model we can define certain foundational concepts and leave it open
for extension while we could provide a concrete example for a specific
network technology and service, as what constitutes a policy could itself
vary depending ont he context where it is used e.g. there could be tenant
specific policies, site specific, network domain specific etc...

Br,
Raghu.

________________________________________
From: Juergen Schoenwaelder <[email-masked]>
Sent: Tuesday, February 3, 2015 5:09 PM
To: Tina TSOU
Cc: [email-masked]; Masaki Fukushima; Raghavendra Rao T (WT01 - Global Media
& Telecom); [email-masked]; Keisuke Kuroki
Subject: Re: [Supa] Slide set

> BTW, we need to choose between option 1 or 2, only use one. Any thoughts?

This is a more detailed version of option 1, clarifying that the policy
interpretation happens at the network manager. Of course, this raises the
question how service and policy data models will be accessed by the policy
agent: Is the data "pushed" to the agent, "pulled" by the agents, is there
"pub/sub" mechanism, ...? And of course, which component is dealing with
policy conflicts? These questions were more clearly hidden in the original
simplified version of option 1 (but then having these questions and trying
to answer them is actually forward progress and thus goodness). So I would
move forward Raghu's version.

I am, however, still unsure what the SUPA arrow is supposed to mean. It may
be read as "we want to do protocol work", an impression which I think we
should try to avoid as much as possible.

/js

_______________________________________________
Supa mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/supa

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Feb 2015 12:34:38 +0100

> will have to be more complex and intelligent.

Yes, this is more or less what I had in mind first. The policy-driven
service manager would essentially communicate requests for network
topology changes down to the network manager (controller). A benefit
of this approach is that conflict detection and resolution happens at
a single place while in the other model you have a certain risk that
the policy engines generate incompatible interpretations of the
policies.

Unfortunately, we do not have much time to decide...

/js

---

From: Tina TSOU <[email-masked]>
Date: Wed, 4 Feb 2015 11:46:47 +0000

Dear all,

AFAIK, Microsoft Lync case is closer to what Jun described.

Pascal you could correct me if I am wrong.

Thank you,
Tina

On Feb 4, 2015, at 7:34 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

/js

---

From: <[email-masked]>
Date: Wed, 4 Feb 2015 13:10:22 +0000

Hi,

True that this 'was' and to some extent still 'is' the general approach in the industry. 

But considering evolving aspects like SDN, the network controller is going to me more intelligent, so i still believe that we should consider passing only the intent to the network management/controller layer and enable it to take decisions on how to provision it by sharing the network wide policies that are relevant.

Also if service management has to apply the policy and only convey what needs to be done to the network controller, just the topology information may not be sufficient, it might also need a subset of the CM and probably also PM information (which typically resides in Network management layer). Especially when QoS based policies need to be applied these have to be factored in.

Anyway, this is just my opinion and if the larger group thinks otherwise, i'm fine with it.

Br,
Raghu.

________________________________________
From: Juergen Schoenwaelder <[email-masked]>
Sent: Wednesday, February 4, 2015 11:34 AM
To: Jun Bi
Cc: Raghavendra Rao T (WT01 - Global Media & Telecom); 'Tina TSOU'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Feb 2015 14:17:45 +0100

> Also if service management has to apply the policy and only convey what needs to be done to the network controller, just the topology information may not be sufficient, it might also need a subset…

But then, do the policy data model and the service data model not
actually reside in this advanced network controller?

/js

---

From: <[email-masked]>
Date: Wed, 4 Feb 2015 13:59:17 +0000

Hi Juergen,

Yes, the policy data model should reside in the network controller but it could be a subset of the policy model in the service management layer i.e. say there are 3 network domains with a controller each, the service management could provision on that subset of policy information relevant to a particular domain to the network controller. 

Similarly, only the information related to the service relavent to the network control domain can resside in the network controller, for example if we have a VPN service and say there are 3 service offerings gold, silver, bronze. Then all the network controller needs to know is that a "silver" category VPN service needs to be provisioned and the policy model will provide (just an example) the QoS parameters associated with a "silver" VPN service, and the network controller should then be intelligent to choose the right configuration for the network resources in its control domain accordingly. 

Br,
Raghu.

________________________________________
From: Juergen Schoenwaelder <[email-masked]>
Sent: Wednesday, February 4, 2015 1:17 PM
To: Raghavendra Rao T (WT01 - Global Media & Telecom)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Feb 2015 15:07:52 +0100

> Similarly, only the information related to the service relavent to the network control domain can resside in the network controller, for example if we have a VPN service and say there are 3 service…

But this sounds like a second step to me, optimizing the distribution
of service and policy information among a set of network managers
(controllers). We first need to find agreement how services and
policies are defined, which I think is what SUPA in the first phase is
trying to work out.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 4 Feb 2015 14:34:15 +0000

> From: [email-masked], February 03, 2015 12:45 PM
> 
> Hi Jorgen/Tina,
> 
> - Service layer express its intent from a service point of view over the interface
> (currently marked as SUPA), say provision a service with certain service
> attributes.
> 
> - It is assumed here that the Policy Agent itself is able to communicate with the
> Policy Manager (my opinion is that SUPA interface also defines this exchange of
> policies, potential conflict detection and resoution interface). More on the
> below...
> 
> provisioned services, in such a case the policy manager broadcasts the changed
> policy (pub-sub model) to all policy agents and then they inform the network
> manager to take appropriate actions. Apart from pub/sub there might be a need
> to have a sync interface to query specific policy instance information from the
> agent towards the manager.

I2RS is currently in WG Adoption call for the adoption of Pub/Sub requirements for YANG Datastores
(draft-voit-i2rs-pub-sub-requirements-00)

Some of the requirements here might be useful in a SUPA context.  Would there be interest in a similar SUPA draft contribution based on the needs of the evolving Topology, Service, and Policy models?

Eric

> - There can be other triggers as well, a fault in the network that impacts a service
> etc, but the propagation of such triggers and associated analysis is out of scope
> of SUPA as it is part of regular fault management and serivce impact analysis.
> 
> - With respect to the scope, i think we should focus on defining a information
> model for the policy exchange between the policy manager and policy agent and
> a corresponding data model based on yang. The protocol specific aspects can be
> deferred to respective implementations. Also interms of the model we can
> define certain foundational concepts and leave it open for extension while we
> could provide a concrete example for a specific network technology and service,
> as what constitutes a policy could itself vary depending ont he context where it
> is used e.g. there could be tenant specific policies, site specific, network domain
> specific etc...
> 
> 
> Br,
> Raghu.
> 
> simplified version of option 1 (but then having these questions and trying to
> answer them is actually forward progress and thus goodness). So I would move
> forward Raghu's version.
> 
> I am, however, still unsure what the SUPA arrow is supposed to mean. It may be
> read as "we want to do protocol work", an impression which I think we should
> try to avoid as much as possible.
> 
> /js
> 
> --

---

From: Dan Martin <[email-masked]>
Date: Wed, 4 Feb 2015 15:19:00 +0000

You have problems on both sides.  The dumber the controller, the more state whatever is making decisions for it needs to have, as you point out.  The smarter the controller the less state the MDSC has to maintain.  For example, say I want a path with 5 gigs and not more than 20 ms delay one way between two points. If the MDSC wants to send the controller a set of hops and ports it has to know just how much bandwidth is available and just how many hops are good.  If the MDSC doesn't want to know all those details, and given a network of some size and some diameter it may be difficult.  Also given a certain kind of network it may be difficult for some upper layer thing to know enough to make a good decision.   If the policy, 5 gigs, no more than 20 ms, can be delivered to the controller as a constraint, then the controller would have to be able to pick from a list of eligible hops, which would save on the upper layer thing having to know all that stuff, but the controller would have to be able to do some kind of best fit thing?  

There may be some 3rd way and that is to have something on the coordinator level that can be smart enough to ask the right questions of a controller, hey, give me the list of hops that meets this criteria, 20ms, 5 gig, between here and here.  Ok, mr. controller, I want this one. 

So, 
More state on the mdsc level, which could work, but may, at some point, as the network grows in size, not work.
More brains on the controller level, which would allow you to deliver policy not as a commands but as constraints, and you point out the problems with that approach.
Some interpreter on the mdsc level that would let you ask the right questions of a controller and sort of self constrain? Keeping the controller simple and the state knowledge less?

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Jun Bi
Sent: Wednesday, February 04, 2015 6:25 AM
To: [email-masked]; Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

IMHO, there is another opinion on the position of policy data model in the SUPA framework:

The policy data model is located in the "Service Management", and it is mapped into service management data model in "Service Management", which means the policy data model will not be sent to network manager/controller.

One reason for this is, the policy model may be very flexible and complex, if it is sent to network manager/controller, the network manager/controller will have to be more complex and intelligent.

Any thoughts?

Thanks,
Jun Bi

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 4, 2015 1:45 AM
To: Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

Hi Jorgen/Tina,

- It is assumed here that the Policy Agent itself is able to communicate with the Policy Manager (my opinion is that SUPA interface also defines this exchange of policies, potential conflict detection and resoution interface).
More on the below...

Br,
Raghu.

> BTW, we need to choose between option 1 or 2, only use one. Any thoughts?

This is a more detailed version of option 1, clarifying that the policy interpretation happens at the network manager. Of course, this raises the question how service and policy data models will be accessed by the policy
agent: Is the data "pushed" to the agent, "pulled" by the agents, is there "pub/sub" mechanism, ...? And of course, which component is dealing with policy conflicts? These questions were more clearly hidden in the original simplified version of option 1 (but then having these questions and trying to answer them is actually forward progress and thus goodness). So I would move forward Raghu's version.

/js

---

From: <[email-masked]>
Date: Wed, 4 Feb 2015 15:38:24 +0000

Hi Dan,

I don't think introducing a thrid level (or an intermediate mdsc) is a good solution, because it only translates the problem with MDSC to the interpreter as the network scales.

Instead providing more intelligence to the controller is a scalable approach, obviously there will be ambiguous situations and the policy model should allow providing information to resolve such ambiguities. 

Essentially, the controller knows the lower level details and it is the right one to act on those, all it needs is what are the constraints to be applied and if there is ambiguity in applying those constraints how to deal with them, for example in the below scenario if 5gig capacity is not available, the policy could mention the priority of this service over others so that the controller can decide if it can compromise on the bandwidth of other services or it just informs the MDSC that only 4gig capacity is available and then the operator is notified so that he/she adds more capacity to the network.

Br,
Raghu.

________________________________________
From: Dan Martin <[email-masked]>
Sent: Wednesday, February 4, 2015 3:19 PM
To: Jun Bi; Raghavendra Rao T (WT01 - Global Media & Telecom); Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Supa] Slide set

So,

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Jun Bi
Sent: Wednesday, February 04, 2015 6:25 AM
To: [email-masked]; Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

Any thoughts?

Thanks,
Jun Bi

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 4, 2015 1:45 AM
To: Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

Hi Jorgen/Tina,

Br,
Raghu.

/js

---

From: <[email-masked]>
Date: Wed, 4 Feb 2015 15:40:16 +0000

Hi Juergen,

Yes, I agree, sorry for jumping on to the next step. As you said let's focus on the first phase.

Br,
Raghu.

Sent: Wednesday, February 4, 2015 2:07 PM

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Feb 2015 12:26:30 +0100

MDSC == Myeloid-derived Suppressor Cell [1] ?

http://en.wikipedia.org/wiki/Myeloid-derived_Suppressor_Cell

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: JF Tremblay <[email-masked]>
Date: Thu, 5 Feb 2015 10:36:59 -0500

[cutting on the CC list]

> On Feb 5, 2015, at 6:26 AM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> 
> http://en.wikipedia.org/wiki/Myeloid-derived_Suppressor_Cell <http://en.wikipedia.org/wiki/Myeloid-derived_Suppressor_Cell>
> /js

MSDC is ACTN’s version of a recursive controller providing topology abstraction: 
See http://tools.ietf.org/html/draft-ceccarelli-actn-framework-06#section-3.2 <http://tools.ietf.org/html/draft-ceccarelli-actn-framework-06#section-3.2>

This is an interesting solution to the problem Dan describes below. That controller can be thought as a “brick” that sits in the middle of a controller “tree”. The top and the bottom interfaces of that “tree” can be specific northbound and southbound interfaces exposing respectively interfaces to apps (think “netconf”) at the top (CNC for ACTN) and to bare network devices (think “openflow” here) at the bottom (PNC for ACTN). The interesting thing is this: if you make the northbound and southbound interfaces the *SAME* for the middle “brick” (MSDC in ACTN), you could in theory "stack up" as many of them as you want to solve your knowledge and computing distribution problems elegantly. 

This idea seems very attractive to me. And not only to solve transport topology, but any kind of topology problem in a distributed and efficient way. I like it and this is the idea I was trying to push as “abstraction levels” in supa at the beginning.  

This could be a way to solve not only the “topology abstraction” problem in a general recursive way but also to solve the resource and computation part if you stick PCE element next to each MSDC. This would provide a distributed way to solve complex topology calculations, if PCEs can contribute together properly. Adrian’s Farrell work on PCE and ABNO has some interesting discussion on this, for example in http://ewsdn.eu/AdrianFarrel-TheRoleOfPCEInAnSDNWorld.pdf <http://ewsdn.eu/AdrianFarrel-TheRoleOfPCEInAnSDNWorld.pdf> and in http://www.olddog.co.uk/farrel_pce_tutorial.ppt <http://www.olddog.co.uk/farrel_pce_tutorial.ppt>. Both are good reads.

In that world, there’s no extremely “dumb” or “fat” controller. You can make any of them as fat or dumb as your deployment, policy boundaries and computing resources requires. 

JF

>> You have problems on both sides.  The dumber the controller, the more state whatever is making decisions for it needs to have, as you point out.  The smarter the controller the less state the MDSC has to maintain.

---

From: JF Tremblay <[email-masked]>
Date: Thu, 5 Feb 2015 10:26:19 -0500

[cutting on the CC list]

> On Feb 5, 2015, at 6:26 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

JF

---

From: Benoit Claise <[email-masked]>
Date: Thu, 12 Feb 2015 14:17:09 +0100

> policies are defined, which I think is what SUPA in the first phase is
[Reading/replying in sequence]

The relates to the point I made earlier today (I guess I don't 
understand the connection between a policy and a service). Do we speak 
about a policy configured in a router (rate-limit this traffic), a 
network-wide policy (traffic take the backup path when ..), or a service 
policy (service configured at time t)?
An explanation or example somewhere would be beneficial. At least to me.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 14:22:49 +0100

On Thu, Feb 12, 2015 at 02:17:09PM +0100, Benoit Claise wrote:
> 
> Do we speak about a policy configured in a router (rate-limit this
> traffic), a network-wide policy (traffic take the backup path when
> ..), or a service policy (service configured at time t)?
>

The later. And it might go beyond a simple service on at time t and
off at time t'.

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 12 Feb 2015 14:27:29 +0100

> The later. And it might go beyond a simple service on at time t and
Understood.
More like (conditions-based) service enablements.

Regards, Benoit

---

From: John Strassner <[email-masked]>
Date: Fri, 20 Feb 2015 00:54:38 +0000

Please see inline...

regards,
John

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 03, 2015 9:45 AM
To: Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

Hi Jorgen/Tina,

- It is assumed here that the Policy Agent itself is able to communicate with the Policy Manager (my opinion is that SUPA interface also defines this exchange of policies, potential conflict detection and resoution interface). More on the below...
<jcs>
There is an old, but still very useful, software engineering principle, called the Single Responsibility Principle. This principle states that every class should have one and only one responsibility, and that this responsibility should be entirely encapsulated within the class.

The above violates this principle. This makes software harder to debug and maintain.

I would urge that we separate the concepts of policy rule communication from policy rule conflict detection from policy rule conflict resolution. Just because they all contain the word policy does not mean that they require the same information. :-)
</jcs>

- Other triggers could also be change in policies which impact already provisioned services, in such a case the policy manager broadcasts the changed policy (pub-sub model) to all policy agents and then they inform the network manager to take appropriate actions. Apart from pub/sub there might be a need to have a sync interface to query specific policy instance information from the agent towards the manager.
<jcs>
Several policy managers that I am familiar with use a pub-sub bus. Sometimes this is implemented as a simple message broker; other implementations use a full-fledged Enterprise Service Bus. However, **none** of the policy serves that I am familiar with have a dedicated "sync" interface, as this is typically done in the implementation.

Since this is implementation-specific, I also think that this is out of scope of SUPA.
</jcs>

- With respect to the scope, i think we should focus on defining a information model for the policy exchange between the policy manager and policy agent and a corresponding data model based on yang. 
<jcs>
In days of yore in the IETF, a (limited) information model was defined for modeling one type of policy rule (i.e., condition-action (CA), having the semantics "IF condition is TRUE, THEN execute action". Both condition and action could be Boolean clauses. Nowadays, there are several types of policy rules. In particular, the problem with condition-action policy rules is that the triggering of their evaluation (e.g., by an event) is not defined. Note that other SDOs have done more than this.

In addition, I am confused by the term "policy exchange".
   1) I would hope that our policy model was more robust than just a CA policy rule
   2) There is a **significant** difference between
      - modeling the components of a policy rule
      - modeling different architectural components of a policy manager
      - modeling the interaction of said components
   3) Is the above exchange at the information model? Or data model? Or both?

I have more comments, but let me stop here... 
</jcs>

The protocol specific aspects can be deferred to respective implementations. 
<jcs>
I'm not sure why you would want to defer this?
</jcs>

Also interms of the model we can define certain foundational concepts and leave it open for extension while we could provide a concrete example for a specific network technology and service, as what constitutes a policy could itself vary depending ont he context where it is used e.g. there could be tenant specific policies, site specific, network domain specific etc...
<jcs>
Redefining what a policy is dynamically at runtime is very complex. Rather (and probably what you meant), redefining the target of the policy, or the content of the policy, dynamically at runtime makes perfect sense and has been done for a while.

For example, you might find "The Design of a New Context-Aware Policy Model for Autonomic Networking", written for ICAC in 2008, of interest. Context-aware policies were actually part of the FOCALE autonomic architecture first published in 2005 in LANOMS.

This is why I define a policy rule as an intelligent container. This provides the abstraction of being able to change its contents (e.g., different access control for a mobile user vs. a user connected on the Intranet) without having to write thousands of policy rules.
</jcs>

Br,
Raghu.

/js

---

From: John Strassner <[email-masked]>
Date: Fri, 20 Feb 2015 01:04:23 +0000

I have two points to make.

#1. ONE INFO MODEL, N DATA MODELS
The discussion below assumes that Controllers can talk to each other. This fails in the current SDN case, since there is no Controller specification to facilitate this.

A possible workaround is for the Controllers to be able to query the (single) information model, and use the information model as a consensual lexicon. So, if I intent says "forward" and another says "accept", the Controller knows that these are synonyms.

If instead, there are "just" data models, I don't know how to resolve the above problem.

Hence, I believe that we need a single information model to define our terms. Data models can then be developed to interoperate using concepts defined in the information model.

#2.  DOMAINS

The other wrinkle is that policy management systems typically are based around the concept of a "policy domain" - a domain in which all of its constituent components (even other managers) agree to obey a set of rules, but are free to add their own rules as long as those added rules do not conflict with a higher-level domain. A simple example is the United States - there are federal rules which (in theory) all States obey, but two States could have different rules that are not defined at the Federal level.

I am not suggesting we dive into this complexity, just noting it for people to think about. I would prefer we build and gain experience with a simpler solution before diving into this complexity.

regards,
John

John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050
  Office:  +1.408.330.4923
  Email:   [email-masked]

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, February 04, 2015 3:35 AM
To: Jun Bi
Cc: [email-masked]; [email-masked]; Tina TSOU; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

/js

---

From: John Strassner <[email-masked]>
Date: Fri, 20 Feb 2015 01:06:03 +0000

I agree with Juergen here. I don't understand why we are talking about APIs. We should try and do an information model, so that multiple Yang data models can interoperate.

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, February 03, 2015 9:41 AM
To: Tina TSOU
Cc: Keisuke Kuroki; Masaki Fukushima; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

In line...

/js

---

From: John Strassner <[email-masked]>
Date: Fri, 20 Feb 2015 01:55:53 +0000

Sorry JF, you lost me. When you say “The interesting thing is this: if you make the northbound and southbound interfaces the *SAME* for the middle “brick” (MSDC in ACTN), you could in theory "stack up" as many of them as you want to solve your knowledge and computing distribution problems elegantly”, how do these bricks solve the knowledge problem? I’m probably misunderstanding you…

regards,
John

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Thursday, February 05, 2015 7:37 AM
To: Juergen Schoenwaelder; [email-masked]
Cc: Dan Martin
Subject: Re: [Supa] Slide set

[cutting on the CC list]

On Feb 5, 2015, at 6:26 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

MSDC is ACTN’s version of a recursive controller providing topology abstraction:
See http://tools.ietf.org/html/draft-ceccarelli-actn-framework-06#section-3.2

This could be a way to solve not only the “topology abstraction” problem in a general recursive way but also to solve the resource and computation part if you stick PCE element next to each MSDC. This would provide a distributed way to solve complex topology calculations, if PCEs can contribute together properly. Adrian’s Farrell work on PCE and ABNO has some interesting discussion on this, for example in http://ewsdn.eu/AdrianFarrel-TheRoleOfPCEInAnSDNWorld.pdf and in http://www.olddog.co.uk/farrel_pce_tutorial.ppt. Both are good reads.

JF

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 20 Feb 2015 06:27:24 +0000

In the interest of identifying consensus for the AD, Chairs, and activists:
I agree with virtually everything John has been saying on the SUPA and I2NSF lists on this topic ... no need for me to elaborate my own views.

Avanti,
BobN

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, February 19, 2015 8:06 PM
To: Juergen Schoenwaelder; Tina TSOU; John Strassner
Cc: Keisuke Kuroki; [email-masked]; [email-masked]; [email-masked]; Masaki Fukushima
Subject: Re: [Supa] Slide set

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, February 03, 2015 9:41 AM
To: Tina TSOU
Cc: Keisuke Kuroki; Masaki Fukushima; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

In line...

> Is API a "protocol work"?

We propose to do data models. They reflected in the figure. I believe the arrow has no purpose and it can trigger questions we do not want. I do not understand why you want an API discussion. I though we decided we do data models.

/js

---

From: JF Tremblay <[email-masked]>
Date: Fri, 20 Feb 2015 11:06:09 -0500

> On Feb 19, 2015, at 8:55 PM, John Strassner <[email-masked]> wrote:
> 

This is an older thread. Raqhav and Dan were discussing whether multiple levels of controllers are needed and if they are fat or thin, especially in the context of actn (transport controllers). This has an influence on the design of models, because if controllers are stacked, you end up in a situation where “someone’s northbound is always someone else’s southbound”. 

Given this, it would be desirable to design a model generic enough that it can be used a various levels of granularity (levels of details) and both in the southbound and northbound directions. This allows for a split in knowledge (resources) and computing requirements between the layers of controllers. 

This is also what the “intents” people are trying to do. They see this as a continuum of “more abstract” at the top toward “less abstract” at the bottom of the controller stack, but with a common interface linking them. Bottom controllers deal with all the gory implementation details, but only a subset of them, which makes it manageable. The knowledge problem is solved by splitting states horizontally to multiple controllers and aggregating upward with a common interface. 

In my opinion, at a high level view, Intents, ACTN, supa and multi-domain PCE are all trying to solve a knowledge distribution problem in their own way and for their specific needs. Having a model that can be transmitted up and down consistently across layers helps a lot in solving this.  Maybe this is all too theoretical, but in the end, if we want supa to be successful, it’s model (or interface) has to be re-usable southbound in a multi-layer configuration. That was my main point.  

JF

---

From: John Strassner <[email-masked]>
Date: Fri, 20 Feb 2015 12:35:13 -0800

Hi JF,

thank you for the excellent explanation. In general, I agree with you. I'm
just worried that without a formal definition of knowledge, it won't matter
how the architecture is designed or implemented.

The problem with most data models is that they address syntactic (not
semantic) concerns within a small domain. For example, most interfaces do
not defne pre- or post-conditions required to safely execute them in a
distributed environment.

I think a good first step would be to define a more robust representation
of the managed object independent of platform, language, or technology
(i.e., an information model), instead of assuming that a data model is
"good enough".

regards,
John

On Fri, Feb 20, 2015 at 8:06 AM, JF Tremblay <
[email-masked]> wrote:

>  Sorry JF, you lost me. When you say “The interesting thing is this: if
> you make the northbound and southbound interfaces the *SAME* for the middle
> “brick” (MSDC in ACTN), you could in theory "stack up" as many of them as
> you want to solve your knowledge and computing distribution problems
> elegantly”, how do these bricks solve the knowledge problem? I’m probably
> misunderstanding you…
>
>
> This is an older thread. Raqhav and Dan were discussing whether multiple
> levels of controllers are needed and if they are fat or thin, especially in
> the context of actn (transport controllers). This has an influence on the
> design of models, because if controllers are stacked, you end up in a
> situation where “someone’s northbound is always someone else’s southbound”.
>
> Given this, it would be desirable to design a model generic enough that it
> can be used a various levels of granularity (levels of details) and both in
> the southbound and northbound directions. This allows for a split in
> knowledge (resources) and computing requirements between the layers of
> controllers.
>
> This is also what the “intents” people are trying to do. They see this as
> a continuum of “more abstract” at the top toward “less abstract” at the
> bottom of the controller stack, but with a common interface linking them.
> Bottom controllers deal with all the gory implementation details, but only
> a subset of them, which makes it manageable. The knowledge problem is
> solved by splitting states horizontally to multiple controllers and
> aggregating upward with a common interface.
>
> In my opinion, at a high level view, Intents, ACTN, supa and multi-domain
> PCE are all trying to solve a knowledge distribution problem in their own
> way and for their specific needs. Having a model that can be transmitted up
> and down consistently across layers helps a lot in solving this.  Maybe
> this is all too theoretical, but in the end, if we want supa to be
> successful, it’s model (or interface) has to be re-usable southbound in a
> multi-layer configuration. That was my main point.
>
> JF
>
>
>

-- 
regards,
John

---

From: JF Tremblay <[email-masked]>
Date: Fri, 20 Feb 2015 16:46:54 -0500

> On Feb 20, 2015, at 3:35 PM, John Strassner <[email-masked]> wrote:
> 
> Hi JF,
> 
> thank you for the excellent explanation. In general, I agree with you. I'm just worried that without a formal definition of knowledge, it won't matter how the architecture is designed or implemented.

True, “knowledge” can be a fuzzy concept. In an SDN context, I see it as the resources DB and the set of known current network states (for example installed flow or rules in devices). 

> The problem with most data models is that they address syntactic (not semantic) concerns within a small domain. For example, most interfaces do not defne pre- or post-conditions required to safely execute them in a distributed environment.
> 
> I think a good first step would be to define a more robust representation of the managed object independent of platform, language, or technology (i.e., an information model), instead of assuming that a data model is "good enough”.

Right, independent objects are required. Some folks are already discussing this concept, to some level. Endpoint groups are an example of an independent object type supported by ODL and OpenStack. It can represent destination, source or any middle point for an intent and be referred to with names or IP addresses. For example, services in an SFC intent could just be designated as endpoint group names (firewalls, ips, dpis, etc) to be resolved. 

Another independent object I’ve heard discussed are “constrains”. For example time-related constrains (always, between 11:00pm and 2:am, etc), quality constrains (high priority, best effort, low latency), security constrains (access, isolation, monitoring). 

Using these, it would be possible to provide a base language for intents. For example: 
- employees use nat, firewall, ips (service chaining on the “employees” EPG source)
- facebook is blocked between 9:00am and 17:00pm for employees, except for marketing (access constrain between two endpoint groups)
- webex is high priority (quality constrain on a source endpoint group)

As you mentioned in one of your i2nsf post, it remains a challenge to turn these into actionable items and to resolve conflicts. I also remain skeptic that intent-based interfaces can be used at all layers, as some argue. If intents are not everything, then this is where we need supa and other policy models to fill the gap. 

JF

---

From: John Strassner <[email-masked]>
Date: Fri, 20 Feb 2015 21:54:42 +0000

Hi JF,

I completely agree with what you said. I would go a bit further and say that an EPG is one form of **abstraction**, and that we desperately need more. I can also provide a brief overview of Rule-X (proposed for OPNFV and Congress), which is a multi-constraint solver.

Finally, I do think that this could be turned into a DSL (or multiple DSLs). But without an underlying information model, it will be impossible to provide the independent objects that you so elegantly described.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: JF Tremblay [mailto:[email-masked]] 
Sent: Friday, February 20, 2015 1:47 PM
To: John Strassner
Cc: John Strassner; [email-masked]
Subject: Re: [Supa] Slide set

JF

---

From: John Strassner <[email-masked]>
Date: Fri, 20 Feb 2015 01:25:53 +0000

In general, I agree with Dan.

If controllers are dumb, and/or controllers operate as silos (e.g., cannot communicate with each other), then some entity, presumably operating at a higher level of abstraction than the controllers, has to help them.

If controllers are smart, then this still may not be enough, because the controller must also be able to understand "intent". However, that could be mitigated through policy agents that translate the intent to the controller.

If the policy rule is formulated as a constraint, then you have several decades of worth of experience in constraint logic programming to draw on. For example, the Rule-X proposal is a constraint-based solver for network problems.

My own personal preference is the first alternative: assume that the controller cannot understand the policy intent, and define entities that help it do that.

Note that this is something that I2RS, TEAS, etc. are NOT doing, and may help answer some of Benoit's (and others') concerns about duplication of work.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Dan Martin
Sent: Wednesday, February 04, 2015 7:19 AM
To: Jun Bi; [email-masked]; Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

You have problems on both sides.  The dumber the controller, the more state whatever is making decisions for it needs to have, as you point out.  The smarter the controller the less state the MDSC has to maintain.  For example, say I want a path with 5 gigs and not more than 20 ms delay one way between two points. If the MDSC wants to send the controller a set of hops and ports it has to know just how much bandwidth is available and just how many hops are good.  If the MDSC doesn't want to know all those details, and given a network of some size and some diameter it may be difficult.  Also given a certain kind of network it may be difficult for some upper layer thing to know enough to make a good decision.   If the policy, 5 gigs, no more than 20 ms, can be delivered to the controller as a constraint, then the controller would have to be able to pick from a list of eligible hops, which would save on the upper layer thing having to know all that stuff, but the controller woul!
d have to
  be able to do some kind of best fit thing?  

So, 

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Jun Bi
Sent: Wednesday, February 04, 2015 6:25 AM
To: [email-masked]; Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

Any thoughts?

Thanks,
Jun Bi

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 4, 2015 1:45 AM
To: Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] Slide set

Hi Jorgen/Tina,

Br,
Raghu.

/js