Re: [Supa] another updated charter draft

[JF Tremblay <[e-mail]>]

Some comments inline below...

> On Jan 22, 2015, at 7:22 AM, Romascanu, Dan (Dan) <[e-mail]> wrote:
> Please find below another updated charter draft, incorporating comments from Will and from the two J.S.

Looks like we have a collision of name initials here... 

> UPDATED CHARTER PROPOSAL
>  
> The rapid increase in the amount and type of traffic, along with the increasing complexity of network architectures, make it significantly more challenging for operations and management applications to manage networks and to deploy new services. Two mechanisms in dealing with this growing complexity are the use of software abstractions to simplify management, and the increase in Programmatic control over the configuration and operation of these networks.

Suggestion: “Two complementary mechanisms”
This would strengthen the fact they aren’t mutually exclusive (Will’s earlier comment).  

> The former enables simplified views of the network to be constructed, which hides complex configuration detail and provides a smaller number of standard control points to configure common functions. The latter uses the abstractions and control points of the former to more quickly define and manage network services. However, combining these two mechanisms provide additional and significant benefits in design and deployment agility.

This last sentence also re-inforce both are required. Good. 


> This WG introduces the concepts of multi-level (multiple levels of abstraction) and multi-technology (e.g. IP, optical) network abstractions to address the current separation between development and deployment operations. Multiple levels of abstraction enable common concepts present in different technologies and implementations to be represented in a common manner. This facilitates using different components and technologies to implement a network service. 

Good text, except that using “optical” here might open the door to overlaps with ACTN, which has a lot of focus on optical transport. Even if ACTN isn’t a wg officially yet, the bof and the list showed a lot of momentum so far.  


> The purpose of the SUPA (Shared Unified Policy Automation) working group is to develop a methodology by which the management and monitoring of network services can be done using standardized policy rules. Three types of YANG data models are envisioned, each at a different level of abstraction: 

This wording suggests a single level of abstraction for each model, which isn’t accurate. The topology model could be at different levels of abstraction. I suggest removing the second part (…each at a different) altogether. 


> 1)  model of the physical and virtual network topology including the capabilities (e.g., data rate or latency of links) and operational parameters needed to support service deployment over the network topology

Which capabilities and parameters are being discussed here? This is a bit too fuzzy. Can’t these be described generically as network resources?


>   2) model of the network service that network resources required by the network service to be correctly executed to the physical and/or virtual topology in order to deploy and perform the service

This one isn’t clear to me. Don’t we want to say here that we’ll model services using the generic topology model defined above? 

Suggestion: 
2) Create some network services models using the generic topology model defined above. The service models are extensions of the base topology model that add service-specific parameters required to plan, deploy and operate the service. The group’s target is to focus first on an inter-datacenter traffic model. 


>   3) model of the policy rules for managing the network service

I concur with Juergen, this one isn’t very crisp and clear either. What are we describing here? Are these generic policies that are independent of the model itself? Something similar to the work being done in OpenStack’s Congress or the interesting NeMo work Susan presented at the last IETF? 
or
Are these policy elements that are embedded in the service model and hardcoded there? Or possibly a model that extends the service model?

I’m hesitant about #2. I doubt it would be a wise choice, as the model would have to be updated/refreshed each time new types of policies would have to be added. Having policies in separate documents makes more sense. But then it’s a huge scope of work to be doing generic policy work. As Jurgen’s mentioned, this would be possibly resuscitating a whole branch of work that hasn’t seen a lot of work in this millennia, but that seems to get new attention now. 


> Using the above three models, the network is first defined as a topology.

Sure. Is this a physical topology, an abstract one, or it doesn’t matter?

> A service is then defined as a graph that uses that topology.

The service is itself a new abstracted topology that uses the underlying physical/logical one. No need to re-introduce a foreign word such as ‘graph’ here imho.  

> A set of policy rules is then defined to manage the service.

In a separate document/model? 

> In this approach, the service data models, as well as the policy model, will be derived from a single information model, ensuring that each can be shared and reused as managed objects.

Hum. The topology information model is the same, agreed. But the service and policies each need different underlying information models. 


> Policy rules will be used to define the operational aspects of both the "southbound" (e.g., controller to network device) and "northbound" (e.g., controller to network application) portions of the service environment.

Not sure I understand the meaning of this sentence. The policies would be “transmitted” on the northbound side and applied to devices or lower level entities (other controllers for example) through the southbound side. 


> The first example that the working group will focus on will be VPN management. 

VPN management is very large and understood differently by a lot of people. This could mean you are managing access VPNs for example (which is not what this is about). 

Suggestion: 
The group will focus first on inter-datacenter traffic management, including the automated provisioning of site-to-site VPN of various types (for example IPsec, tunnels, MPLS L2 and L3). 


>  
> Work items for this WG include:
>  
> 1) A Yang data model that represents a generic form of the physical and virtual topology and capabilities of a network within a single administrative domain. 

Suggestion: 
A Yang model that represents a generic form of physical or virtual topology, covering a single administrative domain. The model also describes and allows the manipulation of basic network resources. 


> 2) A Yang data model that maps network services to the capabilities of a network.

The usage of the ‘map’ verb seems to create a lot of confusion here. It isn’t clear to a lot of people what “mapping” means. 

Suggestion: 
A Yang model of a sample network service using the generic topology model defined above. This network service model will add service-specific parameters required to provision, control and operate the service. Provisioning and management of inter-datacenter traffic with or without VPNs would be used as the sample service.  


> 3) A Yang data model that specifies how policy rules may control the operational, administrative, and management aspects of a network service. 

Again, the “how” and the “may” above make this a bit unclear, in my opinion. Is this a model containing policies? Or additional information on how to apply policies to services? 

Suggested wording: 
A Yang model that specifies policy rules controlling a network service. These policy rules are generic and cover operational and management aspects of the service. The rules can be applied to any type of service model as defined in point 2).  

Hope this helps. I believe there’s still some work to do on the charter to agree on what supa is about, before delving into other documents such as the architecture and gap analysis. 

/JF