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

From: Benoit Claise <[email-masked]>
Date: Wed, 01 Oct 2014 15:44:11 +0200

On 24/09/2014 00:57, Benoit Claise wrote:
> Tina, all,
>
> To make sure this comment is not lost at the end of this email, let me 
> make it upfront. I invite you to submit a BoF request to make your case.
> Note: the deadline is Sept 26th.
>
> Let's start from this figure, where NE= Network Element
>             ---------------------
>             | applications   |
>             ---------------------
>                          |                               <--- service 
> YANG models  /NETCONF interface
>             ---------------------
>             |   controller     |               <---  mapping services 
> to topology
>             ---------------------
>                 |       |        |                    <--- 
> device/feature specific YANG models / NETCONF interface
>             NE1    NE2   NEn
>
>
> What can the IETF possibly standardize?
> 1. Service YANG models  /NETCONF? Yes, for sure, and we should do this 
> full speed
OLD: Service YANG models  /NETCONF? Yes, for sure, and we should do this 
full speed
NEW: Device/Feature YANG models  /NETCONF? Yes, for sure, and we should 
do this full speed

Regards, Benoit
> 2. Mapping services to topology? Potentially, but that's not an easy task
> 3. service YANG models  /NETCONF? I'm not convinced we could 
> standardize them, as they are operators specific, and will be evolving 
> along the time. There are many different ways to configure a VPN, for 
> example.
>
> See in-line
>> Dear all,
>>
>> Hope this version of draft charter address most of the comments from 
>> the list.
>>
>> ------
>>
>> 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.
>>
>> Automating the way of exposing a view of the network to applications 
>> 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 models provided by such systems to applications and network 
>> services running above them (on the so-called northbound side). 
>> Well-designed models are able to provide a wide range of granularity 
>> for various applications and network services 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 and network services to transmit their needs to 
>> controllers.
> Isn't it simply because the industry has not standardized their 
> services?  See above.
>> The SUPA (Shared Unified Policy Automation) working group will work 
>> on the definition of such as standardized interface for applications 
>> and network services to communicate with network controllers of all 
>> types.
> What is a standardized interface?
> Is "service YANG models  /NETCONF (or potentially RESTCONF)"? Or is it 
> something else?
>>
>> The specification of the interface towards end user apllications is 
>> initially not in the scope of SUPA.
> Here you lost me.
> Which interface do you mean in figure above?
>
>> In particular, as starting point, SUPA will only focus on network 
>> services, which are enhanced Operational Support System (OSS) like 
>> services that help a communication service provider to monitor, 
>> control, analyze and manage a communication network. The systems that 
>> are runniung such network services are denoted in this document as 
>> Network Service Systems.
>> Each network service can be represented by a classified application 
>> based POLICY model, since it can model the group of demands which are 
>> SHARED and UNIFIED and are coming from a bundle of applications that 
>> impose similar requirements on the communication network.
> I'm afraid I don't understand (like Jürgen)
>>
>> The main goal of SUPA is to provide a way for applications and for 
>> network services to specify SHARED application based POLICIES to the 
>> network infrastructure using a simplified view of the network. This 
>> can be realized by:
>> (1) modeling the network infrastructure as an simplified network 
>> graph using a modeling language such
>> as YANG,
>
>> (2) transporting model instances either using NETCONF or RESTCONF and 
>> (3) providing guidelines on AUTOMATICALLY mapping policies to 
>> attributes of the network graphs.
>>
>> Although some IETF working groups have started work relating to the 
>> description of various topologies such as I2RS (L3and routing 
>> topologies), ALTO (cost maps), SFC (service chain), none of these 
>> groups aim at offering truly generic topology models for the standard 
>> northbound interface.
>> SUPA will work on defining interfaces based on the concept of network 
>> graph, an entity describing an arbitrary topology of nodes and links 
>> at any level of granularity. Such a graph may describe, for example, 
>> a physical topology, a service topology or the relationships between 
>> datacenters. Any network topology data models or policy models that 
>> have been defined (or are being defined) within the IETF will be 
>> reused in SUPA as much as possible.
>> In addition to the above, policies may be defined and applied to a 
>> network graph. These application based policies are actions or 
>> constraints generated by Network Service Systems. They are then 
>> mapped from the network graph instance into specific network 
>> management policies toward network components.
>>
>> Work items for SUPA include:
>>
>> 1) The definition of a standardized model for a network graph, using 
>> YANG. This model may be used to describe topologies at any functional 
>> layer, from physical networks to network services.
>> Any network topology data models or policy models that have been 
>> defined (or are being defined) within the IETF will be reused in SUPA 
>> as much as possible.
> So basically, you "just" want a topology database ...
> http://tools.ietf.org/html/draft-clemm-netmod-yang-network-topo-01
> http://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/
> ... and a way to map services to it.
> The topology is kind of easy, the mapping is way harder!
>>
>> 2) The definition and standardization of a number of basic policy and 
>> data models using network graphs. These might include, but are not 
>> limited to L3VPNs, datacenters, traffic engineering, implementation 
>> of IPv6 transition mechanism and their enforcement to users.
> Are these examples of SHARED and UNIFIED policies?
>
> Regards, Benoit (OPS AD)
>>
>> 3) Guidelines on how to use NETCONF (or RESTCONF) authentication and 
>> authorization mechanisms to achieve protection and isolation
>>
>> 4) Guidelines for automatic mapping policies to attributes of the 
>> network graphs.
>>
>>
>> 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:
>>
>> o) Produce 'Problem Statement and Use Cases' as an Informational RFC.
>>
>> o) Produce a document specifying the YANG models for a generic 
>> multi-layer network graph, as Protocol Specification' Standards Track 
>> RFC.
>>
>> o) Produce several documents describing different views of a 
>> communication network by using the network graph model defined above, 
>> which includes policy and data models, as Protocol Specifications' 
>> Standards Track RFCs.
>>
>> o) Produce a document on defining the SUPA NETCON/YANG or RESTCONF 
>> (or RESTCONF/YANG) containers, as Protocol Specification' Standards 
>> Track RFC.
>>      o) Produce a document that provides the guidelines on using 
>> NETCONF (or RESTCONF) authentication and authorization mechanisms to 
>> achieve security protection and isolation' as an Informational RFC.
>>
>> o) Produce a document that provides the guidelines for for automatic 
>> mapping policies to attributes of the network graphs.
>>
>> -----------
>>
>>
>> Thank you,
>> Tina
>>
>>
>> -----Original Message-----
>> From: Georgios Karagiannis
>> Sent: Tuesday, September 23, 2014 4:18 AM
>> To: Juergen Schoenwaelder
>> Cc: Zhen Cao; Tina TSOU; [email-masked]
>> Subject: RE: [Supa] Area hand-off, and some friendly advice ...
>>
>> Hi Juergen,
>>
>> Okay, thanks for your recommendation!
>>
>> Best regards,
>> Georgios
>>
>>
>> -----Original Message-----
>> From: Juergen Schoenwaelder 
>> [mailto:[email-masked]]
>> Sent: Monday, September 22, 2014 3:42 PM
>> To: Georgios Karagiannis
>> Cc: Zhen Cao; Tina TSOU; [email-masked]
>> Subject: Re: [Supa] Area hand-off, and some friendly advice ...
>>
>> On Mon, Sep 22, 2014 at 01:27:08PM +0000, Georgios Karagiannis wrote:
>>> o) emphasize that regarding policy, enhancements of the YANG xPath 
>>> expression might be required.
>>>
>> I am wondering what this is or why this would be needed. At the 
>> charter level, you may need to talk about defining data models to 
>> express policy. I do not see why that would need to enhancements of 
>> YANG's usage of xpath.
>>
>> /js
>>
>
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
> .
>