Subject: Re: [Supa] Supa Digest, Vol 2, Issue 22

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 23 Sep 2014 12:31:26 -0400

Some comments on comments below.

> From: Zhen Cao <[email-masked]>
> Subject: Re: [Supa] Area hand-off, and some friendly advice ...
> Date: September 22, 2014 at 8:13:06 AM EDT
> To: Tina TSOU <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> 
> Hello Tina and everybody, 
> 
> I have some comments about the scope of SUPA, as a newly coming reader.  See the comments in line. 
> 
> Best regards,
> zhen
> 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.
This seems vague - what size? Shift which balance in their favor? What do you mean by that?
> 
> 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.
> 
> After the first two paragraph, I am really expecting a full introduction of SUPA, especially what the four-letter abbreviation means physically.  
I agree what is supa and what is targeting in the above.
>  
> 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. 
Several, various.. please specify. 
> 
> 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.
> 'Any level of abstraction' is very aggressive to me, good to you guys?  What's the level of abstraction will the group focus on?
Agree - this needs a more focused scope.
>  
> 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.
There could be a reason for this... Maybe we need words that say why we think supa will be able to create some umbrella architecture and protocols superseeding all of these.
> 
> Work items for SUPA include:
> 
> How about moving the easier items to the front, e.g. the problem statement and requirement. Normally these are the prerequisite for any chartered technical items, basic on which the definition/specification/choice making work can kick-off.  Btw, the five items charter also seems aggressive too. 
>  
> 
> 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.
Can there be a pointer to YANG? Is there IPR attached to it that needs disclosure?
> 
> 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.
Great goal but again seems overly ambitious.
> 
> 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.
Again very wide and most likely not achievable in a group based on concenssus. I would suggest focusing on 2 max.
>  
> 
> 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 athttps://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: Georgios Karagiannis <[email-masked]>
> Subject: Re: [Supa] Area hand-off, and some friendly advice ...
> Date: September 22, 2014 at 9:27:08 AM EDT
> To: Zhen Cao <[email-masked]>, Tina TSOU <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> 
> Hi Zhen,
>  
> Thank you very much for the comments.
>  
> In the next version of the charter, we will:
> o) emphasize the main goal of SUPA:
>  
>    The main goal of SUPA is to provide a way for applications to specify
>    policies to the network infrastructure using a simplified view of
>    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
>    mapping policies to attributes of the network graphs.
>  
> o) emphasize that as starting point, for applications, we will focus only on network services
>  
> o) emphasize that we will focus on policy and data models that are able to provide enough details on the used network and service topology.
>  
> o) emphasize that regarding policy, enhancements of the YANG xPath expression might be required.
>  
> Best regards,
> Georgios
>  
>  
>  
> From: Supa [mailto:[email-masked]] On Behalf Of Zhen Cao
> Sent: Monday, September 22, 2014 2:13 PM
> To: Tina TSOU
> Cc: [email-masked]
> Subject: Re: [Supa] Area hand-off, and some friendly advice ...
>  
> Hello Tina and everybody, 
>  
> I have some comments about the scope of SUPA, as a newly coming reader.  See the comments in line. 
>  
> Best regards,
> zhen
> 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.
>  
> After the first two paragraph, I am really expecting a full introduction of SUPA, especially what the four-letter abbreviation means physically.  
>  
> 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.
> 'Any level of abstraction' is very aggressive to me, good to you guys?  What's the level of abstraction will the group focus on?
>  
> 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:
>  
> How about moving the easier items to the front, e.g. the problem statement and requirement. Normally these are the prerequisite for any chartered technical items, basic on which the definition/specification/choice making work can kick-off.  Btw, the five items charter also seems aggressive too. 
>  
> 
> 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 athttps://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