Subject: [Supa] Minutes of the 06/01 SUPA Call

From: "Narasimha Rao Vadrevu" <[email-masked]>
Date: Mon, 1 Jun 2015 22:06:16 -0700

Hi,

Please find below the meeting notes from the SUPA call on 6/1. 

I may  have missed out some of the problem statement discussion as audio got
choppy into the first few minutes.

Narasimha

Agenda:

1. Note Well, logistics, agenda bashing (chairs, 0 min)

2. Updated charter (Juergen/John/Scott, 20 min)

3. Q&A Wiki (all, 20 min)

https://github.com/IETF-SUPA/SUPA/wiki

4. BoF wiki (all, 20 min)

http://trac.tools.ietf.org/bof/trac/# <http://trac.tools.ietf.org/bof/trac/>

Charter:

Proble Statement

*         First paragraph is simplified and looks better now. Benoit
incorporated the changes which include comments from Juergen, Benoit and
John

*         SUPA is changed from Generic policy to Generic policy information
model (GPIM).Yang models are proliferating. Information model is needed for
helping implementation to interoperate better.

*         What GPIM maps into needs to be charted out. SUPAs goal is to do
this at network level. 

*         John also agrees that SUPA will incorporate a policy structure.
John wants to improve on diffserve model which is a giant

*         Benoit: Juergen took out some of the text which Benoit had
regarding where SUPA was focusing, i.e. south of the service manager and the
north of the controller how this can be implemented. Benoit's question is,
if the above is the case, can ECA be used within the network element. 

*         John's answer is: Only if it is only a smart network element with
an onboard embedded agent which understands ECA and then convert that into
lower level mechanism. GDP (Global delivery platform) is an example of that.

*         John: It makes more sense to implement the north side of the
interface

*         Benoit is going to take out the text about where SUPA was
focusing: south of Service Manager but north of controller. 

*         Benoit answered Juergen's question about the service instance by
explaining the QOS/SLA use case for VPN  

*         John: from the policy server work I have done, service is a
producer and or a consumer of resources. SUPA is above the controller. SUPA
policies can be injected into or orchestrate the controller. So, SUPA is
living in the device which is outside the controller

Information model

*         John: information model is a model fragment and defines its own
ability to be referenced and incorporated by another model. The work is done
in 3060 and 3460.Information model has 3 parts

1.       Generic policy IM talks about the generic structure independent of
what is a policy (whether it is ECA, utility policy or whatever). 

2.       Action is either an ECA or a logic statement which is a declarative
type of policy

3.       Generic YANG - which provides the ability to reuse the concepts
from the lower level domain specific  YANG

Work items

*         John:  refined the long list into much more manageable set so as
to give an easy start for someone getting into SUPA 

1.       Framework document describes the scope - should include graph,
problem statement which can be merged into one.

2.       Information model  - John is editing

3.       To be written - Mapping document which describes how the Generic
YANG that will result from the IM

4.       Use cases which consolidate a number of  different drafts into a
single draft

5.       Kind of self-explanatory

Interworking

*         Benoit  has question about I2SM Topology models 

*         John: SUPA is an I2RS client and not an I2RSserver and consumer of
the topology that I2RS provides

*         Sue: I2RS uses the term I2RS client and the entity inside the
routing system is an agent.I2RS agent is providing protocol independent
information. I2RS is still working out the service topology. That is the
overlap and the rest is an information source. 

*          

*         Benoit : question everything that is working on a interaction is
hold? The answer is no. The SUPA work is independent

*         John: The coordination is a give and take between different
concurrent working groups that have started work simultaneously. We should
ideally come up with a better verbiage.

*         Benoit: SUPA work if it goes through, cannot put on hold any
existing I2RS/SDO work that is going through

*         Juergen: SUPA cannot delay any of  the work in IETF

*         John: Did the note taker got it

*         I: Yes

*         John: Thanks Narasimha san (I agree my name sounds Japanese :))

Q&A Wiki

John went over the questions, ex: if 3060 and 3460 fail why would SUPA
succeed

*         Benoit suggested that John would answer the questions through
email 

BoF wiki

*         Description is from the charter. Agenda is subject to change

*         There are 3 drafts - with clear problem statement, graph or
Framework, 

*         Tina: only one draft is needed which describes the informational
model to generic YANG 

*         Juergen to prepare the document with the content which  merges the
draft analysis , framework into problem statement

*         Juergen: what about the works?

*         June 6th is the deadline for proposal

*         John: if it is a Framework draft as Juergen suggested, we may as
well include graph analysis

*         Tina proposed the name of the document to be 'SUPA Proposition'
for the interim 

*         Editor for the document: Max Klyus agreed to be the editor and
John will help him

*         This week draft work needs to be concentrated

Regards,

Narasimha Vadrevu

 <http://www.von20.com> www.von20.com

+14087810490