Subject: Re: [Supa] MINOR charter revision proposal

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Jun 2015 09:50:49 +0200

Thanks. I have incorporated the suggested changes. Concering your
question, I think we should take out the sentence that talks about
where a policy interpreter is located. I think the sentence does not
add anything important for the charter.

So I have created supa-charter-2015-06-01.txt (attached and uploaded).

/js

On Mon, Jun 01, 2015 at 01:28:51AM +0000, Bradner, Scott wrote:
> some suggestions and a question
> 
> 
> suggestion to replace the 1st two paragraphs of John’s latest draft charter
> (I do not think the traffic amounts are a SUPA issue & I’ve tries to clarify the intent somewhat
> 
> The rapid growth in the variety and importance of traffic flowing over
> increasingly complex enterprise and service provider network architectures
> makes the task of network operations and management applications and
> deploying new services much more difficult.  Two possible mechanisms for
> dealing with this growing difficulty are the use of software abstractions
> to simplify the design and configuration of monitoring and control
> operations and the use of programmatic control over the configuration and
> operation of such networks.
> 
> SUPA (Simplified Use of Policy Abstractions) will define a generic policy
> information model (GPIM) for use in network operations and management
> applications. The GPIM can represent different types of policy rules for
> controlling managed entities throughout the service development and
> deployment lifecycle. The GPIM will be mapped into corresponding YANG data
> models to define interoperable implementations that can exchange and
> modify generic policies using protocols such as NETCONF/RESTCONF.
> 
> the question is in regard ti rte. this paragraph
> SUPA focuses on the interface north of the controller (or similar
> management entity) and south of the service manager. SUPA defines
> management policies that control the configuration of network
> elements. Management policies can be interpreted outside of
> network elements, and the interpretation typically results in
> configuration changes of collections of network elements.
> 
> if SUPA is dealing with policy abstractions how can it be that
> "SUPA focuses on the interface north of the controller (or similar
> management entity) and south of the service manager.:”
> 
> Scott
-- 
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: John Strassner <[email-masked]>
Date: Mon, 1 Jun 2015 08:26:30 +0000

Hi Scott,

> management entity) and south of the service manager.:”

Where is the confusion? :-) SUPA provides **abstractions** - hence, this
MUST be "north" of the device. The service manager has the most abstract
interface For example, the policy: "A physical server is underutilized 
if its memory usage is less than 75% of its memory capacity" (a real 
policy from OpenStack Congress) is completely declarative - note that
no technology-specific features (e.g., ports, IP addresses, device IDs)
are even mentioned. So, how can a device implement this? For that matter,
how could a controller implement it? It needs context, and this is what
SUPA will provide.

regards,
John

John Strassner, Ph.D.
CTO, Software Labs, Huawei Technologies
2330 Central Expressway
San Jose, CA  95050

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Scott O. Bradner
Sent: Sunday, May 31, 2015 6:28 PM
To: John Strassner
Cc: Dan Romascanu; Juergen Schoenwaelder; [email-masked]; Tina TSOU
Subject: Re: [Supa] MINOR charter revision proposal

Scott

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

---

From: Georgios Karagiannis <[email-masked]>
Date: Mon, 1 Jun 2015 11:12:09 +0000

Hi Juergen,

Thank you very much for working out this new version of the SUPA charter.
It looks good. 
Please note that I agree with the comment of Scott to replace "amounts and types of traffic" with 
"variety and importance of traffic".

Best regards,
Georgios

> From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: 01 June 2015 09:51
> To: Bradner, Scott
> Cc: Dan Romascanu; Tina TSOU; [email-masked]; John Strassner
> Thanks. I have incorporated the suggested changes. Concering your question, I
> think we should take out the sentence that talks about where a policy
> interpreter is located. I think the sentence does not add anything important
> for the charter.
> 
> > suggestion to replace the 1st two paragraphs of John’s latest draft
> > charter (I do not think the traffic amounts are a SUPA issue & I’ve
> > tries to clarify the intent somewhat
> >
> > increasingly complex enterprise and service provider network
> > architectures makes the task of network operations and management
> > applications and deploying new services much more difficult.  Two
> > possible mechanisms for dealing with this growing difficulty are the
> > use of software abstractions to simplify the design and configuration
> > of monitoring and control operations and the use of programmatic
> > control over the configuration and operation of such networks.
> >
> > SUPA (Simplified Use of Policy Abstractions) will define a generic
> > policy information model (GPIM) for use in network operations and
> > management applications. The GPIM can represent different types of
> > policy rules for controlling managed entities throughout the service
> > development and deployment lifecycle. The GPIM will be mapped into
> > corresponding YANG data models to define interoperable implementations
> > that can exchange and modify generic policies using protocols such as
> NETCONF/RESTCONF.
> >
> > the question is in regard ti rte. this paragraph SUPA focuses on the
> > interface north of the controller (or similar management entity) and
> > south of the service manager. SUPA defines management policies that
> > control the configuration of network elements. Management policies can
> > be interpreted outside of network elements, and the interpretation
> > typically results in configuration changes of collections of network
> > elements.
> >
> > if SUPA is dealing with policy abstractions how can it be that "SUPA
> > focuses on the interface north of the controller (or similar

---

From: Benoit Claise <[email-masked]>
Date: Mon, 01 Jun 2015 07:19:16 -0700

> add anything important for the charter.
Based on 
http://cnds.eecs.jacobs-university.de/users/schoenw/supa/supa-charter-2015-06-01.txt

    "The GPIM will be mapped into
    corresponding YANG data models to define interoperable implementations
    that can exchange and modify generic policies using protocols such as
    NETCONF/RESTCONF."

Betweeen what and what?

Regards, Benoit

---

From: "Bradner, Scott" <[email-masked]>
Date: Mon, 1 Jun 2015 01:27:46 +0000

Scott

---

From: "Bradner, Scott" <[email-masked]>
Date: Mon, 1 Jun 2015 01:28:51 +0000

Scott

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Jun 2015 17:06:43 +0200

>    that can exchange and modify generic policies using protocols such as

Whatever name you want to give it... I still like Figure 1 in RFC 3139
as a starting point.

                Configuration Management
               Data (High-level Policies)
                           |
                           |
   Network                 V                Network
   Topology ----->   Configuration    <---- Status/performance
   Information     Data Translator(s)       Information
                           |
                           |
     -------------------------------------------------
     |               |               |               |
   Device          Device          Device          Device
   Local           Local           Local           Local
   Conf(1)         Conf(2)         Conf(3)         Conf(4)

We did not have a good name (or agreed name) for "Configuration Data
Translator(s)" back when this RFC was created. Nowadays, some people
call it a 'controller' - the main point, however, has not really
changed. You feed high-level policies into this 'Configuration Data
Translator' and based on topology information and network status and
performance information. SUPA data models would define how high-level
policies are communicated to the 'Configuration Data Translator'.
Again, I do not really care how people what to call this box.

/js