Subject: Re: [Supa] Discussion on SUPA draft chatter

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 2 Sep 2014 06:58:01 +0000

Hi Jun,

I am trying to answer your second question. Regarding to protocol specifications, IMHO,  vendor-neutral data models to describe network/device configuration may belong to this area, e.g., the YANG model for configuration of SAVI?

Regards,
Will

From: Supa [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, August 31, 2014 3:18 PM
To: [email-masked]; [email-masked]
Subject: Re: [Supa] Discussion on SUPA draft chatter

Hi Jun,

Thank you very much for your email!

Please note that we are working on providing preliminary versions of drafts that are providing the information associated with these milestones.

Please also note that in order to show why the SUPA activity is useful for the IETF community we are also working on a state of the art/gap analysis.

Best regards,

Georgios

________________________________
Van: Supa <[email-masked]<mailto:[email-masked]>> namens Jun Bi <[email-masked]<mailto:[email-masked]>>
Verzonden: zaterdag 30 augustus 2014 20:42
Aan: [email-masked]<mailto:[email-masked]>
Onderwerp: [Supa] Discussion on SUPA draft chatter

Hi all,

I would like to trigger the discussion on SUPA charter.

The latest version of SUPA draft charter I received is below.

I would ask questions about items in milestones, may I ask,

    I-D 'Guidelines on mapping network service graphs into specific network
    management and controlling policies' as an Informational RFC.

What specific technologies the "mapping" here means ? Do we have an example ?

    I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol
    Specification' Standards Track RFC.

What would be included into this protocol specification  ?

Thanks,
Jun

SUPA (Shared Unified Policy Automation) charter

Target Area:

Description of Working Group:

Today network operators are challenged to create an abstract view of their network infrastructure and help service developers on using and programming this abstraction rather than manipulating individual devices. An abstract view of a network infrastructure and service function interdependencies can be realized using a network service graph. 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, based on I2RS, SFC based network topologies and represented by a graph of links and nodes

o) service functions (e.g., policing function, NAT, Firewall, DNS, DHCP) and their interdependencies

o) mapping between service function (and their service function interdependencies) and network topology (similar to ALTO mapping)

o) application based policies (actions and access policies) generated by network service systems to map the network service graph instance into specific network management policies, i.e., into device level configuration models. Such application based demands are:
   *) Configuration types:
       o) request to dynamically configure a node
       o) request to place a service function on a network
          function
   *) Data plane types:
       o) request to steer a traffic flow
       o) request prioritize a traffic flow
       o) request to encapsulate/de-capsulate a traffic flow
       o) request block or admit a traffic flow
   *) Control plane / Routing plane types:
       o) request to change the routing state on a network
          function
Network services are enhanced Operational Support System (OSS) services that help a communication service provider to monitor, control, analyze and manage a communication network. In this context, network services can be used to provide the required configuration and application programming interfaces to network service developers. Subsequently, a network service can use the service based demands and possibly update its associated network service graph.

The main goal of SUPA is to provide application based policies and means to model and program the abstract view of network infrastructure and service function interdependencies in order to support and feed network management and controlling policies (e.g., dynamic network configuration, I2RS routing strategies).
This can be realized by:

(1) modeling the network service graph, which among others include application based policies, using YANG,

(2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) network service graphs in a secure and efficient manner between network service systems and network management and controlling systems,

(3) providing guidelines on mapping attributes of network service graphs provided by network service systems into specific network management and controlling policies.

Work items related to SUPA include:
o) specify the network service graph based on YANG models

o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distribute up to date (fresh) network service graphs between network service systems and network management and controlling systems

o) provide guidelines for mechanisms that can dynamically map attributes, including application based policies, of network service graphs into specific network management and controlling policies, such as dynamic network configuration, I2RS routing strategies

o) document how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation

The following items are out of the SUPA scope:

o) specification of the network management and controlling policies and their associated device configuration models

Milestones:

    I-D 'Problem Statement and Use Cases' as an Informational RFC.

    I-D 'Guidelines on mapping network service graphs into specific network
    management and controlling policies' as an Informational RFC.

    I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and
    authorization mechanisms to achieve security protection and isolation'
    as an Informational RFC.

    I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol
    Specification' Standards Track RFC.

---

From: JF Tremblay <[email-masked]>
Date: Tue, 2 Sep 2014 16:40:14 -0400

Good question, indeed. 

In my humble opinion, we could divide supa’s work in clearer blocks or objectives, for example: 
a) provide a way to express an abstracted view of a network through a flexible model and transport protocol
b) provide guidance in the way the mapping of the abstracted should be mapped to actual network configuration for physical and virtualized devices 

The “mapping” part of the work is clearly part of b), but netconf and yang models are clearly part of a). These are two distincts part of the proposed work. 

It would be hard to work on b) without doing a) first, so the charter should reflect this. You can’t defined how things are “mapped” before first defining how they are defined and abstracted. 

For a), I’d suggest we aim at providing flexibility so that the protocol and the models are able to describe pretty much any type of abstraction, for any network level, type of devices and services (virtualized or physical), complexity and associated parameters. That way, a provider that’s used to work “close to the metal” can start with very little abstraction and then increase abstraction as required. 

As for an “example of mapping”, the datacenter example is not bad. The client configures a view containing only abstracted “datacenters” with a limited number of links. This is the view that an application admin, a system admin or a tenant operator could view. Let’s say that datacenter client would like to reserve bandwidth between A and B (either programatically or manually). The controller could offer an abstracted view for this purpose. Then once the request is received, this is mapped to a layer-3 model and applied (or submitted for approval). There are two views here, the abstracted one exposed north-side only and a layer-3 view that might be exposed both southbound (for configuration) and northbound (for approval, debugging, showing results in display, etc).  Supa does not touch the southern side, but would provide mechanisms for northbound transport and exposure to abstractions (which is mostly section a) above). 

I’m not sure how much of b) could actually be specified. This is very device-specific and also specific to the southbound protocol used. 

JF Tremblay, Viagenie
[email-masked]

On Aug 30, 2014, at 2:42 PM, Jun Bi <[email-masked]> wrote:

> What specific technologies the “mapping” here means ? Do we have an example ?
>  
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 3 Sep 2014 12:50:31 +0800

Hi Will,

Good example.

So to compose this RFC, shall we collect enough typical use cases to prove
the protocol covers typical configuration requirements? Or we just take I-D
'Problem Statement and Use Cases' as an Informational RFC. as input.

Best Regards,

Jun

From: Liushucheng (Will) [mailto:[email-masked]] 
Sent: Tuesday, September 2, 2014 2:58 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Supa] Discussion on SUPA draft chatter

Hi Jun,

I am trying to answer your second question. Regarding to protocol
specifications, IMHO,  vendor-neutral data models to describe network/device
configuration may belong to this area, e.g., the YANG model for
configuration of SAVI? 

Regards,

Will 

From: Supa [mailto:[email-masked]] On Behalf Of
[email-masked] <mailto:[email-masked]> 
Sent: Sunday, August 31, 2014 3:18 PM
To: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Subject: Re: [Supa] Discussion on SUPA draft chatter

Hi Jun,

Please note that we are working on providing preliminary versions of drafts
that are providing the information associated with these milestones.

Please also note that in order to show why the SUPA activity is useful for
the IETF community we are also working on a state of the art/gap analysis.

Best regards,

Georgios

  _____  

Van: Supa <[email-masked] <mailto:[email-masked]> > namens Jun
Bi <[email-masked] <mailto:[email-masked]> >
Verzonden: zaterdag 30 augustus 2014 20:42
Aan: [email-masked] <mailto:[email-masked]> 
Onderwerp: [Supa] Discussion on SUPA draft chatter 

Hi all,

What specific technologies the "mapping" here means ? Do we have an example
?

Thanks,

Jun

Target Area: 

Today network operators are challenged to create an abstract view of their
network infrastructure and help service developers on using and programming
this abstraction rather than manipulating individual devices. An abstract
view of a network infrastructure and service function interdependencies can
be realized using a network service graph. 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, based on I2RS, SFC based network topologies and
represented by a graph of links and nodes

o) service functions (e.g., policing function, NAT, Firewall, DNS, DHCP) and
their interdependencies

o) mapping between service function (and their service function
interdependencies) and network topology (similar to ALTO mapping)

o) application based policies (actions and access policies) generated by
network service systems to map the network service graph instance into
specific network management policies, i.e., into device level configuration
models. Such application based demands are:

   *) Configuration types:

          function 

   *) Data plane types:

          function

Network services are enhanced Operational Support System (OSS) services that
help a communication service provider to monitor, control, analyze and
manage a communication network. In this context, network services can be
used to provide the required configuration and application programming
interfaces to network service developers. Subsequently, a network service
can use the service based demands and possibly update its associated network
service graph.

The main goal of SUPA is to provide application based policies and means to
model and program the abstract view of network infrastructure and service
function interdependencies in order to support and feed network management
and controlling policies (e.g., dynamic network configuration, I2RS routing
strategies). 

This can be realized by:

(1) modeling the network service graph, which among others include
application based policies, using YANG, 

(2) applying NETCONF (or RESTCONF) to enable dissemination of up to date
(fresh) network service graphs in a secure and efficient manner between
network service systems and network management and controlling systems, 

(3) providing guidelines on mapping attributes of network service graphs
provided by network service systems into specific network management and
controlling policies.

o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used
to securely and efficiently distribute up to date (fresh) network service
graphs between network service systems and network management and
controlling systems

o) provide guidelines for mechanisms that can dynamically map attributes,
including application based policies, of network service graphs into
specific network management and controlling policies, such as dynamic
network configuration, I2RS routing strategies

o) document how to use NETCONF (or RESTCONF) authentication and
authorization mechanisms to achieve protection and isolation

o) specification of the network management and controlling policies and
their associated device configuration models

Milestones:

    as an Informational RFC.

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 3 Sep 2014 07:22:58 +0000

Hi Jun,

IMHO, I think both PS and core use cases are all needed for this work. Maybe we should change this sentence to: Submit to IESG Information document defining the SUPA problem statement and core use cases.

Regards,
Will (Shucheng LIU)

From: Jun Bi [mailto:[email-masked]]
Sent: Wednesday, September 03, 2014 12:51 PM
To: Liushucheng (Will)
Cc: [email-masked]; [email-masked]
Subject: RE: [Supa] Discussion on SUPA draft chatter

Hi Will,

Good example.

So to compose this RFC, shall we collect enough typical use cases to prove the protocol covers typical configuration requirements? Or we just take I-D 'Problem Statement and Use Cases' as an Informational RFC. as input.

Best Regards,
Jun

From: Liushucheng (Will) [mailto:[email-masked]]
Sent: Tuesday, September 2, 2014 2:58 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Supa] Discussion on SUPA draft chatter

Hi Jun,

Regards,
Will

From: Supa [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Sunday, August 31, 2014 3:18 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] Discussion on SUPA draft chatter

Hi Jun,

Best regards,

Georgios

Hi all,

Thanks,
Jun

Target Area:

Milestones:

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 3 Sep 2014 18:05:36 +0800

I see, Thanks.

Jun

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Liushucheng (Will)
Sent: Wednesday, September 3, 2014 3:23 PM
To: Jun Bi
Cc: [email-masked]; [email-masked]
Subject: Re: [Supa] Discussion on SUPA draft chatter

Hi Jun,

IMHO, I think both PS and core use cases are all needed for this work. Maybe
we should change this sentence to: Submit to IESG Information document
defining the SUPA problem statement and core use cases.

Regards,

Will (Shucheng LIU)

From: Jun Bi [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2014 12:51 PM
To: Liushucheng (Will)
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Subject: RE: [Supa] Discussion on SUPA draft chatter

Hi Will,

Good example.

Best Regards,

Jun

From: Liushucheng (Will) [mailto:[email-masked]] 
Sent: Tuesday, September 2, 2014 2:58 PM
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Subject: RE: [Supa] Discussion on SUPA draft chatter

Hi Jun,

Regards,

Will 

Hi Jun,

Best regards,

Georgios

  _____  

Hi all,

Thanks,

Jun

Target Area: 

   *) Configuration types:

          function 

   *) Data plane types:

          function

This can be realized by:

Milestones:

    as an Informational RFC.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 24 Sep 2014 13:13:08 +0000

Hi,

I actually only skimmed the previous discussion on the charter so maybe other people already suggested what I am suggesting here...  

Just a quick idea. Probably  you heard about secauth. It is for authentication and authorization.
Maybe secauth can be used in this purpose and the informational draft can be about how to use that?

Other suggestions:
- maybe it is good to also include data privacy as a requirement part of the charter. privacy Because it appears that there are some important control data will be exchanged between the devices.
- What about performance and optimizations. By looking at the charter, you tried to have automation but what is the cost of this automation. There might be different solution later that increases traffic on the network and therefore decrease the performance. So it might be good to also explicitly cover optimization not only as an automation but also considering other factors.

I also take a quick look on the problem statement draft 
http://tools.ietf.org/html/draft-karagiannis-supa-problem-statement-00 

>>Currently, the separation of development and operation of network
   technologies leads to slow deployment of network functions/devices
   and poor user experiences.

I think another problem might be that different network providers might use different architecture for their software defined based systems. so there might be no orchestration between them. 

Thanks,
Best,
Hosnieh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Sep 2014 17:01:05 +0200

> Maybe secauth can be used in this purpose and the informational draft can be about how to use that?

Frankly, it is completely unclear what the issue here is and as a
consequence it is hard to say that throwing in secauth is of any help.
I understand that you push secauth and thus you propose to add it in
here as well. But I do not think this is helpful for any of the BOFs
proposed. NETCONF runs over SSH and TLS, RESTCONF over TLS. If secauth
is useful, it should be useful for SSH and/or TLS and thus any
protocol running over SSH and TLS may benefit without requiring
protocol specific work for the protocols running over the security
layers. I guess I am strongly against the proposal.

/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: Hosnieh Rafiee <[email-masked]>
Date: Wed, 24 Sep 2014 15:38:47 +0000

> consequence it is hard to say that throwing in secauth is of any help.

I am not quite sure about your question, if your question is that why this point is in the charter, I guess in any charter, they can explicitly define the document and scope they work on or the protocols or mechanisms they would use.  

>If secauth
> is useful, it should be useful for SSH and/or TLS and thus any protocol
> running over SSH and TLS may benefit without requiring protocol
> specific work for the protocols running over the security layers.

Secauth is not by default combined to any protocol or does not update TLS or SSH specifications so that you can easily say whatever protocols work on TLS, then they by default use it and so no need to mention that. This is not true. In other word, it is independent to those security approaches but able to work with other protocols. 
NETCOnf explicitly said that it runs over SSH but does not mean that it supports the secure authentication and authorization as is the scope of secauth. 

Second point is that, this was about charter, not about BoF contents and what scope the WG plans to handle later or what document plans to explain.

Hosnieh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Sep 2014 09:31:25 +0200

> I am not quite sure about your question, if your question is that why this point is in the charter, I guess in any charter, they can explicitly define the document and scope they work on or the pro…

I said I do not understand that this item really refers to and hence I
can't tell whether secauth is of any relevance. Your response does not
change my observation. Sure, people can write anything they like in a
charter proposal. But then they might be challenged what it means what
they wrote. So you better be prepared to explain what exactly this
charter item means and why secauth is of any help.

> Second point is that, this was about charter, not about BoF contents and what scope the WG plans to handle later or what document plans to explain.

I am lost. NETCONF runs over SSH or TLS, RESTCONF over TLS. If you
want to run NETCONF over something else, you have to go to the NETCONF
working group. SUPA for sure is not the place to do NETCONF/RESTCONF
security work. If you want to add new authentication mechanisms to SSH
or TLS, you have to go to the respective WGs (where they exist).

/js

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 26 Sep 2014 08:49:36 +0000

Hi Jürgen,

> charter item means and why secauth is of any help.

That is true. They can either remove it...The main reason that I mentioned secauth is that, secauth is for authentication and authorization. Netconf is not for authentication or authorization. SUPA planned to have a draft for explaining how to authenticate with netconf. This is something that needs an external protocol or external mechanism that doesn't exist in netconf since both will be two different protocols. In other word, they look for interoperable mechanisms (this is based on my understanding). So, my suggestion was that they can use secauth for this purpose or interoperable mechanism. 

There is no need to either include secauth in netconf or SUPA but only how to use it as a interoperable mechanism. This was my suggestion. Some people might say it is bad and some people might say it is good.

Best,
Hosnieh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Sep 2014 11:06:29 +0200

> There is no need to either include secauth in netconf or SUPA but only how to use it as a interoperable mechanism. This was my suggestion. Some people might say it is bad and some people might say…

NETCONF runs over secure transports (SSH and TLS) and both secure
transports authenticate both of the server and the client (mutual
authentication) NETCONF has an access control model for data model
level authorization. If you want to authorize session using AAA, you
can of course hook SSH into say a RADIUS server. The system
configuration data model even details how to configure this. All this
is defined in RFCs and interoperable today. I remain puzzled what the
problem to be solved is.

/js

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 26 Sep 2014 11:42:08 +0000

> is defined in RFCs and interoperable today. I remain puzzled what the

The more discussion is not related to this list. 
I suggest you read secauth requirements and use case scenarios. I cannot add more since this is not related.

Best,
Hosnieh