Subject: [Supa] Any example of "network service graph"?

From: "Guang Yao" <[email-masked]>
Date: Tue, 2 Sep 2014 16:34:29 +0800

Dear folks,

I'm reading the documents, and I find "network service graph" is a critical
concept to understand how SUPA/APONF works.

The definition is as follows:

"Network service graph: provides an abstraction view of a network

infrastructure, which also includes network service attributes."

I can understand it provides a view of the network, and contains something
about the services/applications. However, what exactly is the view it
provides? And what are the "network service attributes"? I fail to
understand these concepts clearly. Maybe it is due to I missed the
discussions at the beginning stage.

So would you please give an example of the "Network service graph"? For
example, the "Network service graph" should be associated with the "flow
steering policy", or "the IPv6 transition policy"? Many thanks!

Best regards,

Guang

---

From: JF Tremblay <[email-masked]>
Date: Tue, 2 Sep 2014 15:45:36 -0400

This is a very good question actually. 

I believe the wording “Network Service Graph” was somehow derived from ETSI “Network Forwarding Graph”. The “Service” part might be a derivative from some past discussions on service graphs. I find this wording a bit confusing and I’d like to suggest a few other replacement ideas:
1. Network Topology
2. Topology graph
3. Network graph

My own personal favorite is 2, as it clearly shows this is a topology graph and it avoids the work “network”, which is often linked to layer-3 concepts. A supa topology graph could describe any sort of topology, at any level and with any type of abstraction. It could be, for example, a service nodes graph, a physical topology graph, a L3VPN representation, etc. 

Here’s a tentative definition (replace “topology graph” by your favorite wording below)

Topology graph: 
Describes a group of network elements or network functions connected to each other using links. Links might be unidirectional or bidirectional and describe different levels of network relations, such as physical links, data links, network (IP) links, sessions or service relationship, for example. This graph might represent a physical configuration, a virtualized one or any level of abstraction required by the presenter or the topology, usually a network controller offering an abstract view for a higher level application or another type of controller.   

Again, the idea here is to define this topology graph as a generic concept that could describe pretty much any abstracted representation might want to use. Comments? 

JF Tremblay, Viagenie
[email-masked]

On Sep 2, 2014, at 4:34 AM, Guang Yao <[email-masked]> wrote:

> Dear folks,
>  
> I’m reading the documents, and I find “network service graph” is a critical concept to understand how SUPA/APONF works.
>  
> “Network service graph: provides an abstraction view of a network
> infrastructure, which also includes network service attributes.”
>  
> I can understand it provides a view of the network, and contains something about the services/applications. However, what exactly is the view it provides? And what are the “network service attributes”? I fail to understand these concepts clearly. Maybe it is due to I missed the discussions at the beginning stage.
>  
> So would you please give an example of the “Network service graph”? For example, the “Network service graph” should be associated with the “flow steering policy”, or “the IPv6 transition policy”? Many thanks!
>  
> Best regards,
> Guang
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 3 Sep 2014 10:15:08 +0800

This is a very clear explanation, thank you!

If "network graph" is used, I can understand it is a topology graph which
contains network elements (e.g., servers, switches). If using "service
graph", I guess it should be a graph of network functions (from ETSI). Thus,
maybe it is nature to use "network service graph" to denote "an abstraction
view of a network infrastructure including network service attributes".
However, it is somewhat hard for me to understand this definition before
reading your explanation. I think at least it should be described as a graph
of nodes and links (as your description), rather than an "abstraction view"
which is abstract indeed.

And I find in the new charter the "network service graph" has been
re-defined. 

"A network service graph is a graph specified by a Network Service Provider
that defines how one or more network services are applied to traffic flowing
through a set of nodes of the graph, which includes attributes such as:

o) network topology

o) service functions their interdependencies

o) mapping between service function and network topology 

o) application based policies"

It has been very clear. I can understand there is a network topology, a
number of services graphs composed by service functions, and a mapping
between each function and its location on the topology. 

However, I'm not sure about the exact meaning of "application based
policies", which are "generated by network service systems to map the
network service graph instance into specific network management policies". I
feel in the definition there is nothing about the  applications. Would there
be some further explanation on this definition? Thank you very much!

Besides, I found the service graphs must be composed to resolve conflicts
between applications before being applied to the network. However it seems
this task is not in the milestones. Is this task covered by other groups or
did I miss something?

Best regards,

Guang

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Wednesday, September 03, 2014 3:46 AM
To: [email-masked]
Subject: Re: [Supa] Any example of "network service graph"?

I believe the wording "Network Service Graph" was somehow derived from ETSI
"Network Forwarding Graph". The "Service" part might be a derivative from
some past discussions on service graphs. I find this wording a bit confusing
and I'd like to suggest a few other replacement ideas:

1. Network Topology

2. Topology graph

3. Network graph

My own personal favorite is 2, as it clearly shows this is a topology graph
and it avoids the work "network", which is often linked to layer-3 concepts.
A supa topology graph could describe any sort of topology, at any level and
with any type of abstraction. It could be, for example, a service nodes
graph, a physical topology graph, a L3VPN representation, etc. 

Here's a tentative definition (replace "topology graph" by your favorite
wording below)

Topology graph: 

Describes a group of network elements or network functions connected to each
other using links. Links might be unidirectional or bidirectional and
describe different levels of network relations, such as physical links, data
links, network (IP) links, sessions or service relationship, for example.
This graph might represent a physical configuration, a virtualized one or
any level of abstraction required by the presenter or the topology, usually
a network controller offering an abstract view for a higher level
application or another type of controller.   

Again, the idea here is to define this topology graph as a generic concept
that could describe pretty much any abstracted representation might want to
use. Comments? 

JF Tremblay, Viagenie

[email-masked]
<mailto:[email-masked]> 

On Sep 2, 2014, at 4:34 AM, Guang Yao <[email-masked]
<mailto:[email-masked]> > wrote:

Dear folks,

Best regards,

Guang

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

---

From: JF Tremblay <[email-masked]>
Date: Wed, 3 Sep 2014 16:30:09 -0400

On Sep 2, 2014, at 10:15 PM, Guang Yao <[email-masked]> wrote:

> If “network graph” is used, I can understand it is a topology graph which contains network elements (e.g., servers, switches). If using “service graph”, I guess it should be a graph of network functions (from ETSI). Thus, maybe it is nature to use “network service graph” to denote “an abstraction view of a network infrastructure including network service attributes”. However, it is somewhat hard for me to understand this definition before reading your explanation. I think at least it should be described as a graph of nodes and links (as your description), rather than an “abstraction view” which is abstract indeed.
> And I find in the new charter the “network service graph” has been re-defined.
<snip>
> However, I’m not sure about the exact meaning of “application based policies”, which are “generated by network service systems to map the network service graph instance into specific network management policies”. I feel in the definition there is nothing about the  applications… Would there be some further explanation on this definition? Thank you very much!

Well, my point was against including “services” in the definition. If what supa defines is a “network service graph”, than this is barely an interface to sfc, which is already described in draft-penno-sfc-yang (http://tools.ietf.org/html/draft-penno-sfc-yang-05).

>  Besides, I found the service graphs must be composed to resolve conflicts between applications before being applied to the network. However it seems this task is not in the milestones. Is this task covered by other groups or did I miss something? 

This is the “policy” part. How to resolve conflicts and permissions before applying any change. SUPA should provide guidelines on how to resolve these in a deterministic way. 

Again, my personal view is that supa has three main blocks of work: 
- Defining an abstract model (a generic topology graph, basically a better version of draft-clemm-i2rs-yang-network-topo)
- Define how the model will be defined and transported, if possible with an existing protocol (could be YANG for example)
- Define the guidelines to apply policies, in other words how an abstract model should be applied to devices (virtual or not) 

My 2 cents. 

JF

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Sep 2014 23:44:37 +0200

> - Define how the model will be defined and transported, if possible with an existing protocol (could be YANG for example)

YANG is a data modeling language, not a protocol. NETCONF and RESTCONF
are protocols to access and manipulate data defined in YANG data
models. I assume people understand that but then I also see these
terms messed up more than occasionally...

/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: Felix <[email-masked]>
Date: Thu, 4 Sep 2014 02:39:23 +0000

Hi JF,

>From my point, the information of configuration can't be found from the first view of "network graph".

The main Goal of SUPA is to provide vendor-neutral network level configuration model to management applications. So that the management applications can dynamically reconfigure the network to do what they want. So I tend to choose something like "Network level configuration graph" or "vendor-neutral network level configuration graph"

Best regards!
Felix

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Thursday, September 04, 2014 4:30 AM
To: [email-masked]
Subject: Re: [Supa] Any example of "network service graph"?

On Sep 2, 2014, at 10:15 PM, Guang Yao <[email-masked]<mailto:[email-masked]>> wrote:

If "network graph" is used, I can understand it is a topology graph which contains network elements (e.g., servers, switches). If using "service graph", I guess it should be a graph of network functions (from ETSI). Thus, maybe it is nature to use "network service graph" to denote "an abstraction view of a network infrastructure including network service attributes". However, it is somewhat hard for me to understand this definition before reading your explanation. I think at least it should be described as a graph of nodes and links (as your description), rather than an "abstraction view" which is abstract indeed.
And I find in the new charter the "network service graph" has been re-defined.
<snip>

However, I'm not sure about the exact meaning of "application based policies", which are "generated by network service systems to map the network service graph instance into specific network management policies". I feel in the definition there is nothing about the  applications... Would there be some further explanation on this definition? Thank you very much!

Well, my point was against including "services" in the definition. If what supa defines is a "network service graph", than this is barely an interface to sfc, which is already described in draft-penno-sfc-yang (http://tools.ietf.org/html/draft-penno-sfc-yang-05).

This is the "policy" part. How to resolve conflicts and permissions before applying any change. SUPA should provide guidelines on how to resolve these in a deterministic way.

My 2 cents.

JF

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 4 Sep 2014 11:00:08 +0800

Hi Felix,

When I read "So that the management applications can dynamically reconfigure
the network to do what they want.", two concerns come to my mind:

1.       What if the configurations of two applications conflict each other?

2.       What if the configuration is malicious or wrongly generated, and
can result in loop/packet drop/unreach ?

Maybe these topics should be mentioned in the charter?

Best regards,

Guang

From: Supa [mailto:[email-masked]] On Behalf Of Felix
Sent: Thursday, September 04, 2014 10:39 AM
To: JF Tremblay; [email-masked]
Subject: Re: [Supa] Any example of "network service graph"?

Hi JF,

>From my point, the information of configuration can't be found from the
first view of "network graph".

The main Goal of SUPA is to provide vendor-neutral network level
configuration model to management applications. So that the management
applications can dynamically reconfigure the network to do what they want.
So I tend to choose something like "Network level configuration graph" or
"vendor-neutral network level configuration graph"

Best regards!

Felix

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Thursday, September 04, 2014 4:30 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Supa] Any example of "network service graph"?

On Sep 2, 2014, at 10:15 PM, Guang Yao <[email-masked]
<mailto:[email-masked]> > wrote:

<snip>

Well, my point was against including "services" in the definition. If what
supa defines is a "network service graph", than this is barely an interface
to sfc, which is already described in draft-penno-sfc-yang
(http://tools.ietf.org/html/draft-penno-sfc-yang-05).

This is the "policy" part. How to resolve conflicts and permissions before
applying any change. SUPA should provide guidelines on how to resolve these
in a deterministic way. 

- Defining an abstract model (a generic topology graph, basically a better
version of draft-clemm-i2rs-yang-network-topo)

- Define how the model will be defined and transported, if possible with an
existing protocol (could be YANG for example)

- Define the guidelines to apply policies, in other words how an abstract
model should be applied to devices (virtual or not) 

My 2 cents. 

JF

---

From: Felix <[email-masked]>
Date: Thu, 4 Sep 2014 03:16:11 +0000

Hi Guang,

I think that there need a mechanism in the controller or controller like function in network. The network level configuration should first reach the controller like function, and the controller should deal with the conflict between applications. The anti-attack for malicious or wrongly configuration should also be deal with in the controller like function.

Best regards!
Felix

From: Guang Yao [mailto:[email-masked]]
Sent: Thursday, September 04, 2014 11:00 AM
To: Felix; 'JF Tremblay'; [email-masked]
Subject: RE: [Supa] Any example of "network service graph"?

Hi Felix,

When I read "So that the management applications can dynamically reconfigure the network to do what they want.", two concerns come to my mind:

2.       What if the configuration is malicious or wrongly generated, and can result in loop/packet drop/unreach ?

Best regards,
Guang

From: Supa [mailto:[email-masked]] On Behalf Of Felix
Sent: Thursday, September 04, 2014 10:39 AM
To: JF Tremblay; [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] Any example of "network service graph"?

Hi JF,

Best regards!
Felix

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Thursday, September 04, 2014 4:30 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] Any example of "network service graph"?

My 2 cents.

JF

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 4 Sep 2014 11:17:59 +0800

Hi JF,

Thank you very much for your kind reply.

As I can understand, the procedure may be like this:

1.       At first "an abstracted view" of the network is formed. It has
nothing about the applications and is only determined by the network
topology. This can be the "topology graph" you mentioned.

2.       The "abstracted view" is delivered to the applications. Then each
application determine how each service should be deployed in the "abstracted
view". For example, they define functions/polices on each node of the
topology.

3.       The network management system collects the requirements from the
applications. Then it merges the requirements from the applications,
resolves the conflicts, and checks errors. After that, it integrate the
services to the topology graph. Then the topology graph will contains the
service information. Then it would be OK to name the graph " network service
graph". It is not a SFC since it also contains network topology. 

4.       The polices in the integrated graph are finally applied to the
network devices, through NETCONF or something else.

I inferred the whole procedure because I don't find the specifications in
the existing documents. Please kindly correct me if there are
misunderstandings.

Best regards,

Guang

 

<snip>

My 2 cents. 

JF

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 4 Sep 2014 11:21:58 +0800

+1

Guang

From: Supa [mailto:[email-masked]] On Behalf Of Felix
Sent: Thursday, September 04, 2014 11:16 AM
To: Guang Yao; 'JF Tremblay'; [email-masked]
Subject: Re: [Supa] Any example of "network service graph"?

Hi Guang,

I think that there need a mechanism in the controller or controller like
function in network. The network level configuration should first reach the
controller like function, and the controller should deal with the conflict
between applications. The anti-attack for malicious or wrongly configuration
should also be deal with in the controller like function.

Best regards!

Felix

From: Guang Yao [mailto:[email-masked]] 
Sent: Thursday, September 04, 2014 11:00 AM
To: Felix; 'JF Tremblay'; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Supa] Any example of "network service graph"?

Hi Felix,

Best regards,

Guang

From: Supa [mailto:[email-masked]] On Behalf Of Felix
Sent: Thursday, September 04, 2014 10:39 AM
To: JF Tremblay; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Supa] Any example of "network service graph"?

Hi JF,

Best regards!

Felix

 

<snip>

My 2 cents. 

JF

---

From: JF Tremblay <[email-masked]>
Date: Fri, 5 Sep 2014 10:18:39 -0400

On Sep 3, 2014, at 5:44 PM, Juergen Schoenwaelder <[email-masked]> wrote:

> terms messed up more than occasionally…

Ok, I agree this sentence was poorly worded. YANG applied to the model definition, not the protocol, of course. The point was that *both* a modelling language AND a transport have to be chosen or defined, but that depending of the choice of the modelling language, the transport might already be defined.

If YANG is chosen as a modelling langage, then NETCONF or RESTCONF are a given as the protocols. 

JF

---

From: JF Tremblay <[email-masked]>
Date: Fri, 5 Sep 2014 11:01:34 -0400

On Sep 3, 2014, at 10:39 PM, Felix <[email-masked]> wrote:

> Hi JF,
> From my point, the information of configuration can’t be found from the first view of “network graph”.
> The main Goal of SUPA is to provide vendor-neutral network level configuration model to management applications. [...]

Ok, I see this is where we disagree. “network level” in the sentence above really limits the graphs to layer-3 modelling, in my opinion. Adding the word “configuration” makes it even closer to the actual configuration of the device and further from an actual useful abstraction. 

Do yo suggest that supa should be limited to network device configuration? The value of centrally controlled networks is in the quality of abstractions it can provide to higher levels (apps). Exposing actual network layer-3 topology and configuration isn’t a new thing. This is what several other organizations are defining and it’s being done even within the ietf already. draft-clemm-i2rs-yang-network-topo, for example, already defines a basic topology using YANG (which is closely related to routing however).   

Let’s take for example a datacenter abstraction, one of supa’s use case. The goal here is to offer apps an abstracted view of datacenters and allow them to modify parameters relating to the whole datacenter, not single devices. Yes, the result will be actual configuration on devices, but it should’t be exposed to the app (unless it wants it).

As an app développer using supa, I’d like to be able to send a request to the controller like this: “reserve me bandwidth x between datacenters A and B from this time to that time.” This does’t sound like network level configuration… but maybe we’re just disagreeing on vocabulary here. 

Of course it doesn’t preclude that supa offers a network-device view of the network. It just that it’s not its main goal, in my opinion. 

JF

---

From: JF Tremblay <[email-masked]>
Date: Fri, 5 Sep 2014 11:19:28 -0400

Guang, 
Thank you for providing a good concrete example. 

On Sep 3, 2014, at 11:17 PM, Guang Yao <[email-masked]> wrote:
> 
> 1.       At first “an abstracted view” of the network is formed. It has nothing about the applications and is only determined by the network topology. This can be the “topology graph” you mentioned.

Sure, this is one use case for supa, but a very simple one that isn’t providing a lot of value compared what’s already been done at the IETF and in other forums. 

> 2.       The “abstracted view” is delivered to the applications. Then each application determine how each service should be deployed in the “abstracted view”. For example, they define functions/polices on each node of the topology.
> 3.       The network management system collects the requirements from the applications. Then it merges the requirements from the applications, resolves the conflicts, and checks errors. After that, it integrate the services to the topology graph. Then the topology graph will contains the service information. Then it would be OK to name the graph “ network service graph”. It is not a SFC since it also contains network topology.
> 4.       The polices in the integrated graph are finally applied to the network devices, through NETCONF or something else.
>  
> I inferred the whole procedure because I don’t find the specifications in the existing documents. Please kindly correct me if there are misunderstandings.

Let’s take another concrete example, but with an abstract view this time. 

1. Say my controller offers several views, for example L3 network topology, L3VPN topologies, L2VPNs topologies and datacenter view. 
   An app may know in advance the available view or not (interesting idea, do we need a discovery mechanism for the views? It might be useful). 
2. An app sends a request for a list of datacenters.
3. The controller sends a list of active datacenters 
4. The app then uses the datacenter view to send a request specifying: “reserve 3 Gbps of bandwidth at high QOS between datacenters A and B between 1:00 AM and 3:00 AM”
    Here, the view the app uses only contains datacenters, not devices, links or other low-level information. 
5. The controller translates (maps, compile, etc, they are synonyms) the request into physical device configuration
6. The controller verifies if the current policy set allows the app to make these changes. 
7. The controller replies with a success/error type of message. 
8. The app MAY request a complete view of the network and see what has changed, but it’s likely not to. 

Does this example makes sense? It uses an abstracted datacenter view for the network. This is why I believe it isn’t right to say that supa defines a “network service graph” or "network level configuration”. It would limit the scope of the wg to something that’s already been done. 

My 2 cents. Comments welcome. 

JF

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 9 Sep 2014 15:12:26 +0800

Hi JF,

This is a clear & interesting & useful example!

If these features were supported, SUPA will be wonderful.

One small question:

You use "reserve 3 Gbps of bandwidth at high QOS between datacenters A and B
between 1:00 AM and 3:00 AM" as the policy from the app. It seems SUPA
should provide an exhausted list of high-level policy patterns? At least, it
is hard for the controller to understand natural language. Or has this been
done by some other group?

Best regards,

Guang

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Friday, September 05, 2014 11:19 PM
To: [email-masked]
Subject: Re: [Supa] Any example of "network service graph"?

Guang, 

On Sep 3, 2014, at 11:17 PM, Guang Yao <[email-masked]
<mailto:[email-masked]> > wrote:

Sure, this is one use case for supa, but a very simple one that isn't
providing a lot of value compared what's already been done at the IETF and
in other forums. 

Let's take another concrete example, but with an abstract view this time. 

1. Say my controller offers several views, for example L3 network topology,
L3VPN topologies, L2VPNs topologies and datacenter view. 

   An app may know in advance the available view or not (interesting idea,
do we need a discovery mechanism for the views? It might be useful). 

4. The app then uses the datacenter view to send a request specifying:
"reserve 3 Gbps of bandwidth at high QOS between datacenters A and B between
1:00 AM and 3:00 AM"

    Here, the view the app uses only contains datacenters, not devices,
links or other low-level information. 

5. The controller translates (maps, compile, etc, they are synonyms) the
request into physical device configuration

6. The controller verifies if the current policy set allows the app to make
these changes. 

8. The app MAY request a complete view of the network and see what has
changed, but it's likely not to. 

Does this example makes sense? It uses an abstracted datacenter view for the
network. This is why I believe it isn't right to say that supa defines a
"network service graph" or "network level configuration". It would limit the
scope of the wg to something that's already been done. 

JF

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 10 Sep 2014 07:35:43 +0000

So, have we reached an agreement which term should be used?

Regards,
Will (Shucheng LIU)

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Friday, September 05, 2014 11:02 PM
To: [email-masked]
Subject: Re: [Supa] Any example of "network service graph"?

On Sep 3, 2014, at 10:39 PM, Felix <[email-masked]<mailto:[email-masked]>> wrote:

Hi JF,

Ok, I see this is where we disagree. "network level" in the sentence above really limits the graphs to layer-3 modelling, in my opinion. Adding the word "configuration" makes it even closer to the actual configuration of the device and further from an actual useful abstraction.

Do yo suggest that supa should be limited to network device configuration? The value of centrally controlled networks is in the quality of abstractions it can provide to higher levels (apps). Exposing actual network layer-3 topology and configuration isn't a new thing. This is what several other organizations are defining and it's being done even within the ietf already. draft-clemm-i2rs-yang-network-topo, for example, already defines a basic topology using YANG (which is closely related to routing however).

Let's take for example a datacenter abstraction, one of supa's use case. The goal here is to offer apps an abstracted view of datacenters and allow them to modify parameters relating to the whole datacenter, not single devices. Yes, the result will be actual configuration on devices, but it should't be exposed to the app (unless it wants it).

As an app développer using supa, I'd like to be able to send a request to the controller like this: "reserve me bandwidth x between datacenters A and B from this time to that time." This does't sound like network level configuration... but maybe we're just disagreeing on vocabulary here.

Of course it doesn't preclude that supa offers a network-device view of the network. It just that it's not its main goal, in my opinion.

JF

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 10 Sep 2014 16:48:26 +0800

IMHO:

1.       The apps only require a “network graph”, which is an abstraction
view of the network topology.

2.       The controller should merge the services and place the functions on
the real topology(service placement will be a problem). Then an intermediate
graph with topology and service is formed. This one can be named “network
service graph”.

3.       Finally, the service-level graph is translated into a
configuration-level(or policy-level) graph(maybe no graph is required here),
and the configurations are applied on the devices.

So, I think the graphs are actually different views on the same thing. Maybe
we should define it to be a model, and “network graph”, “network service
graph”, “network level configuration graph” are just different views of this
model. 

From: Supa [mailto:[email-masked]] On Behalf Of Liushucheng (Will)
Sent: Wednesday, September 10, 2014 3:36 PM
To: JF Tremblay; [email-masked]
Subject: Re: [Supa] Any example of "network service graph"?

Regards,

Will (Shucheng LIU)

From: Supa [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of JF Tremblay
Sent: Friday, September 05, 2014 11:02 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: Re: [Supa] Any example of "network service graph"?

On Sep 3, 2014, at 10:39 PM, Felix <[email-masked]
<mailto:[email-masked]> > wrote:

Hi JF,

The main Goal of SUPA is to provide vendor-neutral network level
configuration model to management applications. [...]

Ok, I see this is where we disagree. “network level” in the sentence above
really limits the graphs to layer-3 modelling, in my opinion. Adding the
word “configuration” makes it even closer to the actual configuration of the
device and further from an actual useful abstraction. 

Do yo suggest that supa should be limited to network device configuration?
The value of centrally controlled networks is in the quality of abstractions
it can provide to higher levels (apps). Exposing actual network layer-3
topology and configuration isn’t a new thing. This is what several other
organizations are defining and it’s being done even within the ietf already.
draft-clemm-i2rs-yang-network-topo, for example, already defines a basic
topology using YANG (which is closely related to routing however).   

Let’s take for example a datacenter abstraction, one of supa’s use case. The
goal here is to offer apps an abstracted view of datacenters and allow them
to modify parameters relating to the whole datacenter, not single devices.
Yes, the result will be actual configuration on devices, but it should’t be
exposed to the app (unless it wants it).

As an app développer using supa, I’d like to be able to send a request to
the controller like this: “reserve me bandwidth x between datacenters A and
B from this time to that time.” This does’t sound like network level
configuration… but maybe we’re just disagreeing on vocabulary here. 

Of course it doesn’t preclude that supa offers a network-device view of the
network. It just that it’s not its main goal, in my opinion. 

JF

---

From: <[email-masked]>
Date: Wed, 10 Sep 2014 13:02:59 +0000

Hi Guang Yao,

Please note that I agree with most of what you mentioned, except the fact that IMHO the three different graphs are not vieweing the same model, but they are viewing different abstraction models of the the same network.

The network service graph contains the most details of all three. Moreover, please note that the network service  graph includes the information/model provided by the “network level configuration graph”.

Furthermore, what you defined as “network level configuration graph”  is IMHO, similar t the network topology grph that the SFC WG and the i2RS WGs might work on in the (near) future.

IMHO SUPA can focus on the network service graph. Please also note that the work on the modeling activities associated with the “network level configuration graph” can be excluded from SUPA if the SFC WG and or I2RS WGs will decide to work (in the near future) on modeling the “network level configuration graph”.

Best regards,

Georgios

________________________________
Van: Supa <[email-masked]> namens Guang Yao <[email-masked]>
Verzonden: woensdag 10 september 2014 10:48
Aan: 'Liushucheng (Will)'; 'JF Tremblay'; [email-masked]
Onderwerp: Re: [Supa] Any example of "network service graph"?

IMHO:

1.       The apps only require a “network graph”, which is an abstraction view of the network topology.

2.       The controller should merge the services and place the functions on the real topology(service placement will be a problem). Then an intermediate graph with topology and service is formed. This one can be named “network service graph”.

3.       Finally, the service-level graph is translated into a configuration-level(or policy-level) graph(maybe no graph is required here), and the configurations are applied on the devices.

So, I think the graphs are actually different views on the same thing. Maybe we should define it to be a model, and “network graph”, “network service graph”, “network level configuration graph” are just different views of this model.

Regards,
Will (Shucheng LIU)

Hi JF,

JF

---

From: JF Tremblay <[email-masked]>
Date: Thu, 11 Sep 2014 15:19:10 -0400

Comments inline. 
I quoted you out-of-order Guang, but I believe this makes a better discussion. 

On Sep 10, 2014, at 4:48 AM, Guang Yao <[email-masked]> wrote:

> So, I think the graphs are actually different views on the same thing.

Exactly! We’re discussing different levels (granularity) of abstractions for the same physical network. These abstractions can be of any level (0 to 7), this is why we were discussing multi-level/multi-layer topologies/graph. 

> Maybe we should define it to be a model, and “network graph”, “network service graph”, “network level configuration graph” are just different views of this model.

I’m almost in agreement here. These are graphs or topologies, these words can be inter-changed IMHO. The “network” (L3), “service” (L4-7-ish) and “configuration” (NMS level) are qualifiers for the graphs. If we use these words in the charter, then we automatically limit supa’s work to some specific layers, which is something that we’d like to avoid. At least this was my understanding of the work. 

> 1.       The apps only require a “network graph”, which is an abstraction view of the network topology.

I disagree. For the reason above. “Network” is often constrained to L2-L3 in people mind. For example, if I build a service graph for sfc, will it still be considered a network graph? It seems odd. But maybe it’s just me. 

> 2.       The controller should merge the services and place the functions on the real topology(service placement will be a problem).

Agree. 

> Then an intermediate graph with topology and service is formed.

Agree. I’m not sure “intermediate” is the right word here. I would suggest “finer granularity” (alto wording) or “lower-level” or “more detailed” or “less abstract” as synonyms. 

> This one can be named “network service graph”.

“Network graph” maybe, but without the “service”, for the reasons mentioned above. But this is not what the application usually sees. The network view not exposed to the apps unless the apps really needs to dig into it. The apps want to see higher level abstraction. They barely see the network. Actually, quoting what Martin Casado from VmWare recently said: “Most apps don’t care at all about the network and should not even be aware of it”. Of course, a network management app will probably want the gory details and access a really fine grain network graph, there I agree. 

> 3.       Finally, the service-level graph is translated into a configuration-level(or policy-level) graph(maybe no graph is required here), and the configurations are applied on the devices.

Almost! Actually, it’s any network graph at any granularity/level that will be translated to configuration-level graph for application to a physical controller. 

JF

---

From: JF Tremblay <[email-masked]>
Date: Thu, 11 Sep 2014 15:34:14 -0400

> Please note that I agree with most of what you mentioned, except the fact that IMHO the three different graphs are not vieweing the same model, but they are viewing different abstraction models of…

Exact! These are different levels/granularity of the same network. 

> The network service graph contains the most details of all three.

Hum… I just lost you there. This should be exactly the opposite. The service view is of higher level, therefore larger granularity. It shouldn’t be detailed at all. Look at the service chain definition in draft-penno-sfc-yang, it’s very simple and high-level, which is exactly what it should be!

The app specifies a service chain at the higher level. Just which services should be chained in which order. Then the controller take this abstract view and translates it into a less abstract topology view with specific service elements, interfaces and encapsulation to make it a service function path. Then it can be translated to configuration-level information and pushed to physical controllers, depending of the level of abstractions they understand. 

> Moreover, please note that the network service  graph includes the information/model provided by the “network level configuration graph”.

Exactly the opposite. See comment above. The service layer is higher abstraction then the network or configuration level. 

> Furthermore, what you defined as “network level configuration graph”  is IMHO, similar t the network topology grph that the SFC WG and the i2RS WGs might work on in the (near) future.

Might be. But this is goal of supa. To provide a generic way to define these graphs/topologies in a standard way. Whatever sfc and i2rs define will suite their needs, but it’s always going to be a subset. I agree that many people at the IETF (and especially the IESG) do not like overlapping. But in this case, if we want supa to tackle abstraction, it will overlap with other work in progress. 

>  IMHO SUPA can focus on the network service graph.

Too narrow and entirely covered by SFC already. 

> Georgios

Georgios, I hope you’ll see this as a positive and constructive discussion. I believe it’s great and a sane thing to have a thorough discussion on the charter, even if it comes late. The follow-up discussions later will only be strengthened by discussing it in-depth now. 

JF

---

From: <[email-masked]>
Date: Fri, 12 Sep 2014 05:31:15 +0000

Hi JF,

See in line!

________________________________
Van: Supa <[email-masked]> namens JF Tremblay <[email-masked]>
Verzonden: donderdag 11 september 2014 21:34
Aan: [email-masked]
Onderwerp: Re: [Supa] Any example of "network service graph"?

On Sep 10, 2014, at 9:02 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Guang Yao,

Hum... I just lost you there. This should be exactly the opposite. The service view is of higher level, therefore larger granularity. It shouldn't be detailed at all. Look at the service chain definition in draft-penno-sfc-yang, it's very simple and high-level, which is exactly what it should be!

Georgios: The netwrok service graph, as it was defined in APONF contained both service and neywork models/views and provide also the way of how these views are interconnected with each other.
In your definition I miss how the inetconnction between these two models (service and network) will be realized.

Moreover, please note that the network service  graph includes the information/model provided by the "network level configuration graph".

Georgios: Well the network service graph includes all the service and netwrok topology descriptions and in addition to that it provides the glue between them. So it is describing how service functions are mapped/located into network entities.

Furthermore, what you defined as "network level configuration graph"  is IMHO, similar t the network topology grph that the SFC WG and the i2RS WGs might work on in the (near) future.

Might be. But this is goal of supa. To provide a generic way to define these graphs/topologies in a standard way. Whatever sfc and i2rs define will suite their needs, but it's always going to be a subset. I agree that many people at the IETF (and especially the IESG) do not like overlapping. But in this case, if we want supa to tackle abstraction, it will overlap with other work in progress.

Georgios: As I mentioned above, only the network topology model might be covered by SFC  or i2RS and maybe also ALTO. The rest can be covered by SUPA.

Best regards,
Georgios

 Best regards,

Georgios

Georgios, I hope you'll see this as a positive and constructive discussion. I believe it's great and a sane thing to have a thorough discussion on the charter, even if it comes late. The follow-up discussions later will only be strengthened by discussing it in-depth now.

JF

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Sep 2014 11:52:12 +0200

> If YANG is chosen as a modelling langage, then NETCONF or RESTCONF are a given as the protocols. 

You may save a lot of time if the selection is made now rather than
later in the process.

/js

---

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

> You may save a lot of time if the selection is made now rather than

Agreed. If there’s no sensible other choice, let’s cut the chase and just say the modelling aspects will be done in YANG for SUPA. 

Any opinion on NETCONF vs RESTCONF? 

They are not complete replacements for each others. RESTCONF seems simpler to implement, especially for smaller apps. NETCONF seems more efficient for larger data sets, but I might be wrong on these two things, feel free to straighten my views here. 

JF

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Sep 2014 16:54:40 +0200

> They are not complete replacements for each others. RESTCONF seems simpler to implement, especially for smaller apps. NETCONF seems more efficient for larger data sets, but I might be wrong on thes…

I think a major functional difference is that RESTCONF does not
support transactions. draft-ietf-netconf-restconf-01.txt section 1.2
may be relevant to read. It says among other things:

   A simplified transaction model is needed that allows basic CRUD
   operations on a hierarchy of conceptual resources.  This represents a
   limited subset of the transaction capabilities of the NETCONF
   protocol.

   Applications that require more complex transaction capabilities might
   consider NETCONF instead of RESTCONF.  The following transaction
   features are not directly provided in RESTCONF:

   o  datastore locking (full or partial)

   o  candidate datastore

   o  startup datastore

   o  validate operation

   o  confirmed-commit procedure

So it primarily boils down to the question whether a more complete
transaction model is needed.

/js

---

From: JF Tremblay <[email-masked]>
Date: Thu, 18 Sep 2014 11:09:41 -0400

> transaction model is needed.

Great, thanks for pointing out this relevant section. 

In my view of things, more complex transactions are required because management apps could use SUPA interfaces on the northbound side. On the other hand, simpler is better for smaller apps, if we want to allow smaller user apps to use the same SUPA interface set. I don’t know if there’s room to allow both, but this could be considered. 

I’ll educate myself and read the RESTCONF draft more thoroughly. 

JF