Subject: Re: [Supa] Area hand-off, and some friendly advice ...

From: "Vic Liu" <[email-masked]>
Date: Thu, 18 Sep 2014 18:32:19 +0800

Dear SUPA

Automation of configuration sounds interesting to operators and DC network
managers. If I understand correctly, do you mean higher level simplified
configuration can be translated into detailed ones by a controller-like
agent and then dispatched to the data plane? However, before reading your PS
and use case drafts, I'm not sure the meaning of your abstraction. Can you
elaborate it?

Thank You
All the best!
-------------------------------------
Vic Liu
China Mobile

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Tuesday, September 16, 2014 4:58 AM
To: Spencer Dawkins; [email-masked]
Cc: Benoit Claise
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Dear Spencer, Benoit et al,

Thank you for your friendly advice. 

Below are SUPA draft charter, and OPENv6, APONF and SUPA group historic
perspective, based on the list discussion. Look forward to more opinions and
discussions on the list.

* SUPA draft charter:
--------------

SUPA (Shared Unified Policy Automation)

Target Area: OPS

Description of Working Group:

Network operators are faced with networks of increasing size and complexity
while trying to improve their quality and availability, as more and more
services depend on them. Programmatic ways to configure networks, often
called software-defined, are considered by many network operators in order
to shift the balance in their favor.
 
Automation of configuration may provide significant improvements in
configuration agility, error detection and uptime for operators. However the
real value behind central configuration schemes lies within the possible
simplification through abstraction provided by such systems to applications
running above them (on the so-called northbound side). Well-designed
abstractions are able to provide a wide range of granularity for various
applications needs, from the lower-level physical network to high-level
application services.
 
Although several organizations outside of the IETF have defined various
schemes for the configuration of network devices and specific network
controllers, none of them offer a vendor-neutral standardized way for
applications to transmit their needs to controllers. The SUPA (Shared
Unified Policy Automation) working group will work on the definition of such
as standardized interface for applications to communicate with network
controllers of all types.
 
The interface definitions will be based on the concept of network graph, an
entity describing an arbitrary topology of nodes and links at any level of
abstraction and granularity. Such a graph may describe, for example, a
physical topology, a L2 network, a service topology or the relationships
between datacenters. Although some IETF working groups have started work
relating to the description of various topologies such as I2RS (L3 and
routing topologies), ALTO (cost maps), SFC (service chain), none of these
groups aim at offering a truly generic multi-layer and abstract topology for
standard northbound configuration.
 
Work items for SUPA include:
 
1) Choice of a modeling language used by the group to describe the network
graph. Existing modeling languages such as YANG will be considered for this
purpose unless no suitable one is found.
 
2) Choice of a transport protocol for the modeling language mentioned above.
The group will re-use a protocol already defined as a transport for the
modeling language, such as NETCONF or RESTCONF in the case of YANG.
 
3) The definition of a standardized model for a network topology graph. This
model may be used to describe topologies at any functional layer, from
physical networks to network services and higher abstractions. The nodes of
this graph may describe physical nodes as well as virtualized ones.
 
4) The definition and standardization of a number of basic abstracted models
using network graphs. These might include, but are not limited to, L3VPNs,
L2VPNs, datacenters, traffic engineering, implementation of IPv6 transition
mechanism and their enforcement to users.  
 
5) Guidelines for the mapping of abstract model information to physical or
virtualized network components.  

Proposed milestones for the working group:
 
-   Produce a problem statement document for SUPA.

-   Produce a gap analysis for SUPA in order to verify overlap with the work
of other IETF groups.

-   Produce a requirement document describing the desired properties of an
abstract multi-layer network graph definition.

-   Produce a gap analysis of existing modeling language, their
characteristics, possible transport protocols and how they compare to the
SUPA requirements.

-   Produce a document specifying the model for a generic multi-layer
network graph.

-   Produce several documents describing different levels of abstract views
using the network graph model defined above, including physical view,
logical view, layer-3 view, configuration view, performance probing view,
service view and other such as L3VPN, L2VPN, datacenters and traffic
engineering.  

------------

* OPENv6, APONF and SUPA group historic perspective
-------------------------------------------------------------------------

Most IETF working groups are formed in the interest of solving some actual
real-world problem from network operators, developers or manufacturers and
the initial work from the OPENv6 group was no exception. Some operators saw
a common interest in defining a common approach for the deployment of IPv6
transition tools. Although the preferred way of deploying IPv6 remains by
dual-stacking, several operators have deployed additional transition tools
such as 6RD (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with
the intent of speeding up or to provide more flexibility in their IPv6
services. Each of these protocols presents its own set of deployment
challenges and failure modes for users, either because of unsupported
applications, partial implementations in some off-the-shelf devices such as
home routers or some limitations of the protocols themselves to name a few
cases. 

The fact these protocols are often deployed with techniques targeting the
extension of IPv4 service, such as Carrier Grade NAT, making their
deployment even more complex, especially when targeting minimal end-user
impact. Although some approaches in solving this were proposed, for example
in RFC6264, the market hasn't seen the advent of configurable CGN devices or
adaptive home gateways. The only solution for operators is to have an agile
way to provision rapidly and easily any type of IPv6 or IPv4 service
depending of the specific needs of each end-user and their device. These
changes must be performed with respect to the operator existing policies
regarding the network, billing, security and other constraints. 

While exploring these issues, it became clear the best way to address them
would be to use a central controller that would be able to coordinate the
deployment of different protocols amongst several devices in a consistent
fashion. Such a controller would receive high-level policy information from
a management application, transform it in network-level configuration and
apply it to physical or virtual devices. At that point, several other use
cases outside of the deployment of IPv6 started to emerge, for example for
the control of data center traffic steering, for the creation of tunnels and
the provisioning of L3VPN. The group decided to rename its activities under
the acronym APONF, for Application Policy on Network Functions, which seemed
a more fitting name. The definition of policies by a management application
toward a network controller would be at the center of the work for the
group. Several group documents were created around this concept. 

When presented at a bar bof during IETF-90 in Toronto, most of the feedback
was positive, but the scope of the work was often judged too large in scope.
It wasn't clear either how much overlap there was with other IETF groups. A
better analysis of this aspect in the following weeks revealed some level of
overlap with other groups, but also where deficiencies exist. The two
aspects where IETF work seems to be lacking are in the definition of
high-level policy language for applications and also in a standard model to
describe network topologies at different levels of granularity, or
abstraction. Some existing working groups have published work on the latter.
For example, the ALTO working group defined a way to describe network
functions at different level of granularity using cost maps, but this
approach does not seem practical for the description of complex network
topologies to and from a central controller. A topology draft exists in the
I2RS group, but it is very centered !
around ro
 uting protocols and L2-L3 links. 

The group has recently renamed its activities under the SUPA (Shared Unified
Policy Automation) acronym with the intention of defining a standard way to
push policies to a central controller. It appears, however, that in order to
define such policies, the definition of a standard multi-layer model for the
description of networks of all types would be desirable. Therefore the
initial work for the SUPA group would be to select an existing modeling
language and define a clear multi-layer model able to describe network or
service information at any level of granularity or complexity.
--------------

Thank you,
Tina

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Friday, September 12, 2014 9:42 AM
To: [email-masked]
Cc: Benoit Claise
Subject: [Supa] Area hand-off, and some friendly advice ...

Dear SUPA friends,

Several IESG members had a chat earlier this week, and decided that SUPA
really belongs in OPS. I've requested that the area affiliation in
http://www.ietf.org/list/nonwg.html be updated to reflect that.

Benoit will be your AD for additional charter discussion.

If I might offer some friendly advice, several ADs are fairly confused about
the relationship between openv6, APONF, and SUPA. If you could put together
a short paragraph that's something like "we started openv6 to do X, then we
realized we needed to do Y so we proposed APONF, and after discussions in
Toronto, we chose a different direction with SUPA because of Z", that would
be very helpful.

I also have a request from Benoit (and Adrian, and Joel) to make the
description at https://www.ietf.org/mailman/listinfo/supa more
understandable for people who haven't been following the work - if you
intend to charter a working group, you'll want people to understand what
you're proposing.

You should probably keep in mind that people who talk over a long period of
time are likely to develop a shared understanding that people who weren't
involved don't understand clearly. If there's a smart newcomer who could
look over problem statements, proposed charters and see what's not clear to
newcomers, that would likely be helpful as well.

Thanks, and best wishes. I'll see you in the hallways of Honolulu, where all
ADs lurk sooner or later ...

Spencer

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

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

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 18 Sep 2014 11:23:27 +0000

Dear Vic,

Thank you very much for your email!

IMHO, the scope of SUPA is to work on (1) modeling different abstraction levels of the configuration (by using e.g., YANG) (2) by using configuration based policy translate a  higher abstraction level and simplified configuration into a detailed one, (3) northbound interface (NETCONF or RESTCONF) that can be used to realize/maintain the translation mentioned in bullet (2).

Best regards,
Georgios

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Vic Liu
Sent: Thursday, September 18, 2014 11:32 AM
To: [email-masked]
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Dear SUPA

Automation of configuration sounds interesting to operators and DC network managers. If I understand correctly, do you mean higher level simplified configuration can be translated into detailed ones by a controller-like agent and then dispatched to the data plane? However, before reading your PS and use case drafts, I'm not sure the meaning of your abstraction. Can you elaborate it?

Thank You
All the best!

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Tuesday, September 16, 2014 4:58 AM
To: Spencer Dawkins; [email-masked]
Cc: Benoit Claise
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Below are SUPA draft charter, and OPENv6, APONF and SUPA group historic perspective, based on the list discussion. Look forward to more opinions and discussions on the list.

* SUPA draft charter:
--------------

Target Area: OPS

Network operators are faced with networks of increasing size and complexity while trying to improve their quality and availability, as more and more services depend on them. Programmatic ways to configure networks, often called software-defined, are considered by many network operators in order to shift the balance in their favor.
 
Automation of configuration may provide significant improvements in configuration agility, error detection and uptime for operators. However the real value behind central configuration schemes lies within the possible simplification through abstraction provided by such systems to applications running above them (on the so-called northbound side). Well-designed abstractions are able to provide a wide range of granularity for various applications needs, from the lower-level physical network to high-level application services.
 
Although several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, none of them offer a vendor-neutral standardized way for applications to transmit their needs to controllers. The SUPA (Shared Unified Policy Automation) working group will work on the definition of such as standardized interface for applications to communicate with network controllers of all types.
 
The interface definitions will be based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of abstraction and granularity. Such a graph may describe, for example, a physical topology, a L2 network, a service topology or the relationships between datacenters. Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3 and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering a truly generic multi-layer and abstract topology for standard northbound configuration.

1) Choice of a modeling language used by the group to describe the network graph. Existing modeling languages such as YANG will be considered for this purpose unless no suitable one is found.
 
2) Choice of a transport protocol for the modeling language mentioned above.
The group will re-use a protocol already defined as a transport for the modeling language, such as NETCONF or RESTCONF in the case of YANG.
 
3) The definition of a standardized model for a network topology graph. This model may be used to describe topologies at any functional layer, from physical networks to network services and higher abstractions. The nodes of this graph may describe physical nodes as well as virtualized ones.
 
4) The definition and standardization of a number of basic abstracted models using network graphs. These might include, but are not limited to, L3VPNs, L2VPNs, datacenters, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.  
 
5) Guidelines for the mapping of abstract model information to physical or virtualized network components.  

-   Produce a gap analysis of existing modeling language, their
characteristics, possible transport protocols and how they compare to the SUPA requirements.

-   Produce several documents describing different levels of abstract views
using the network graph model defined above, including physical view, logical view, layer-3 view, configuration view, performance probing view, service view and other such as L3VPN, L2VPN, datacenters and traffic engineering.  

------------

Most IETF working groups are formed in the interest of solving some actual real-world problem from network operators, developers or manufacturers and the initial work from the OPENv6 group was no exception. Some operators saw a common interest in defining a common approach for the deployment of IPv6 transition tools. Although the preferred way of deploying IPv6 remains by dual-stacking, several operators have deployed additional transition tools such as 6RD (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with the intent of speeding up or to provide more flexibility in their IPv6 services. Each of these protocols presents its own set of deployment challenges and failure modes for users, either because of unsupported applications, partial implementations in some off-the-shelf devices such as home routers or some limitations of the protocols themselves to name a few cases. 

The fact these protocols are often deployed with techniques targeting the extension of IPv4 service, such as Carrier Grade NAT, making their deployment even more complex, especially when targeting minimal end-user impact. Although some approaches in solving this were proposed, for example in RFC6264, the market hasn't seen the advent of configurable CGN devices or adaptive home gateways. The only solution for operators is to have an agile way to provision rapidly and easily any type of IPv6 or IPv4 service depending of the specific needs of each end-user and their device. These changes must be performed with respect to the operator existing policies regarding the network, billing, security and other constraints. 

While exploring these issues, it became clear the best way to address them would be to use a central controller that would be able to coordinate the deployment of different protocols amongst several devices in a consistent fashion. Such a controller would receive high-level policy information from a management application, transform it in network-level configuration and apply it to physical or virtual devices. At that point, several other use cases outside of the deployment of IPv6 started to emerge, for example for the control of data center traffic steering, for the creation of tunnels and the provisioning of L3VPN. The group decided to rename its activities under the acronym APONF, for Application Policy on Network Functions, which seemed a more fitting name. The definition of policies by a management application toward a network controller would be at the center of the work for the group. Several group documents were created around this concept. 

When presented at a bar bof during IETF-90 in Toronto, most of the feedback was positive, but the scope of the work was often judged too large in scope.
It wasn't clear either how much overlap there was with other IETF groups. A better analysis of this aspect in the following weeks revealed some level of overlap with other groups, but also where deficiencies exist. The two aspects where IETF work seems to be lacking are in the definition of high-level policy language for applications and also in a standard model to describe network topologies at different levels of granularity, or abstraction. Some existing working groups have published work on the latter.
For example, the ALTO working group defined a way to describe network functions at different level of granularity using cost maps, but this approach does not seem practical for the description of complex network topologies to and from a central controller. A topology draft exists in the I2RS group, but it is very centered !
around ro
 uting protocols and L2-L3 links. 

The group has recently renamed its activities under the SUPA (Shared Unified Policy Automation) acronym with the intention of defining a standard way to push policies to a central controller. It appears, however, that in order to define such policies, the definition of a standard multi-layer model for the description of networks of all types would be desirable. Therefore the initial work for the SUPA group would be to select an existing modeling language and define a clear multi-layer model able to describe network or service information at any level of granularity or complexity.
--------------

Thank you,
Tina

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Friday, September 12, 2014 9:42 AM
To: [email-masked]
Cc: Benoit Claise
Subject: [Supa] Area hand-off, and some friendly advice ...

Dear SUPA friends,

Several IESG members had a chat earlier this week, and decided that SUPA really belongs in OPS. I've requested that the area affiliation in http://www.ietf.org/list/nonwg.html be updated to reflect that.

If I might offer some friendly advice, several ADs are fairly confused about the relationship between openv6, APONF, and SUPA. If you could put together a short paragraph that's something like "we started openv6 to do X, then we realized we needed to do Y so we proposed APONF, and after discussions in Toronto, we chose a different direction with SUPA because of Z", that would be very helpful.

I also have a request from Benoit (and Adrian, and Joel) to make the description at https://www.ietf.org/mailman/listinfo/supa more understandable for people who haven't been following the work - if you intend to charter a working group, you'll want people to understand what you're proposing.

You should probably keep in mind that people who talk over a long period of time are likely to develop a shared understanding that people who weren't involved don't understand clearly. If there's a smart newcomer who could look over problem statements, proposed charters and see what's not clear to newcomers, that would likely be helpful as well.

Thanks, and best wishes. I'll see you in the hallways of Honolulu, where all ADs lurk sooner or later ...

Spencer

---

From: JF Tremblay <[email-masked]>
Date: Thu, 18 Sep 2014 10:53:49 -0400

Thank you Vic for your interest. More below. I took the liberty of changing the topic to reflect the actual discussion. 

On Sep 18, 2014, at 7:23 AM, Georgios Karagiannis <[email-masked]> wrote:
> 
> IMHO, the scope of SUPA is to work on (1) modeling different abstraction levels of the configuration (by using e.g., YANG)

Georgios, I have trouble parsing some of your sentences. I’m good with “modelling different abstraction levels”, this makes perfect sense. But the “of the configuration” just throws me off. For me, “configuration” is synonym with a non-abstracted view of the network. Configuration is what a physical controller manipulates and pushes to devices. By “configuration” here, do you mean the parameters of the model?

> (2) by using configuration based policy translate a  higher abstraction level and simplified configuration into a detailed one,

Again, problems parsing. What is “configuration based policy”? What does that mean?
Why does it “translate a higher abstraction level”? 

I think I have a glimpse of what you are trying to say. Is it that higher abstractions have simplified configuration models and that these will get translated by the controller into a physical-level non-abstract configuration?

> (3) northbound interface (NETCONF or RESTCONF) that can be used to realize/maintain the translation mentioned in bullet (2).

Again, I get the idea, but this wording is a bit weird. It’s not the northbound interface that translates anything. An interface exposes an API and/or a model. Could we rather say that the northbound interfaces defined in SUPA will expose models for different levels of abstractions? And then that these abstract models will get translated within the controller in a non-abstract model?

This would be nice, but what is SUPA planning exactly within the scope of work? To define a number of possible abstract models for the northbound? To only define a mechanism by which any model can be defined? 

I guess we’d want a way to define abstract models on the northbound side without going through standardization within a workgroup each time. I’m not sure this would be desirable.  

Opinions on the list?

JF

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 18 Sep 2014 16:38:07 +0000

Dear JF,

Comments in line!

From: JF Tremblay [mailto:[email-masked]]
Sent: Thursday, September 18, 2014 3:54 PM
To: Georgios Karagiannis
Cc: [email-masked]
Subject: Re: [Supa] SUPA's scope of work

On Sep 18, 2014, at 7:23 AM, Georgios Karagiannis <[email-masked]<mailto:[email-masked]>> wrote:

JF: Georgios, I have trouble parsing some of your sentences. I'm good with "modelling different abstraction levels", this makes perfect sense. But the "of the configuration" just throws me off. For me, "configuration" is synonym with a non-abstracted view of the network. Configuration is what a physical controller manipulates and pushes to devices. By "configuration" here, do you mean the parameters of the model?

Georgios: Configuration in this context is network topology! Doe to use the same terminology used by Vic.

JF: (2) by using configuration based policy translate a  higher abstraction level and simplified configuration into a detailed one,

Again, problems parsing. What is "configuration based policy"? What does that mean?
Why does it "translate a higher abstraction level"?

Georgios: This term is associated with the comments on the charter:

"Such application based demands are:
            *) Configuration types:
                 o) request to dynamically configure e.g., (virtualized) L2VPN, a (virtualized L3VPN),
                  a service topology, the  relationships between datacentres
                o) request to place the configuration, e.g., a service topology on physical locations, e.g.,
                    on VMs (virtual Machines)"

JF: I think I have a glimpse of what you are trying to say. Is it that higher abstractions have simplified configuration models and that these will get translated by the controller into a physical-level non-abstract configuration?

Again, I get the idea, but this wording is a bit weird. It's not the northbound interface that translates anything. An interface exposes an API and/or a model. Could we rather say that the northbound interfaces defined in SUPA will expose models for different levels of abstractions? And then that these abstract models will get translated within the controller in a non-abstract model?

I guess we'd want a way to define abstract models on the northbound side without going through standardization within a workgroup each time. I'm not sure this would be desirable.

Georgios: You are jumping in conclusions too fast.
The exact description of what I mean will be written in the problem statement draft.
What I wanted to say here is exactly (note the term: can be used to realize/maintain the translation)
northbound interface (NETCONF or RESTCONF) that can be used to realize/maintain the translation mentioned in bullet
The text is not mentioning anything about "SUPA will expose models for different levels of abstractions"

Best regards,
Georgios

Opinions on the list?

JF

---

From: JF Tremblay <[email-masked]>
Date: Fri, 19 Sep 2014 10:14:13 -0400

On Sep 18, 2014, at 12:38 PM, Georgios Karagiannis <[email-masked]> wrote: 
> JF: Georgios, I have trouble parsing some of your sentences. I’m good with “modelling different abstraction levels”, this makes perfect sense. But the “of the configuration” just throws me off. For me, “configuration” is synonym with a non-abstracted view of the network. Configuration is what a physical controller manipulates and pushes to devices. By “configuration” here, do you mean the parameters of the model?
>  

Georgios, you say “Configuration […] is network topology!”. I’m not sure this makes things clearer. Interfaces are usually either API-based or model-driven. In the case of SUPA, we’re obviously discussing model-driven interfaces on the northbound side. I guess that by “configuration” here you mean the content of the model, but you may be using the word "configuration" a bit too liberally. 

> “Such application based demands are:
>             *) Configuration types:
>                     on VMs (virtual Machines)”

Ok, I get it. You’re calling a model instance with its data a “configuration”. Not my favorite choice of words, but I’ll wait to hear form others on the list. 

JF