Re: [Supa] Slide set

["Eric Voit (evoit)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail], February 03, 2015 12:45 PM
> 
> 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.

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.
> 
> ________________________________________
> From: Juergen Schoenwaelder <[e-mail]>
> Sent: Tuesday, February 3, 2015 5:09 PM
> To: Tina TSOU
> Cc: [e-mail]; Masaki Fukushima; Raghavendra Rao T (WT01 - Global Media
> & Telecom); [e-mail]; Keisuke Kuroki
> Subject: Re: [Supa] Slide set
> 
> On Tue, Feb 03, 2015 at 04:10:19PM +0000, Tina TSOU wrote:
> > 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?
> >
> 
> 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: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> Supa mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/supa