Subject: [Supa] New SUPA charter

From: Georgios Karagiannis <[email-masked]>
Date: Fri, 26 Sep 2014 00:31:57 +0000

Hi all,

We have worked out all comments that we have received on the previous version of the SUPA charter.
The new version of the charter can be seen below:

Best regards,
Georgios

=================================================
SUPA (Shared Unified Policy Automation) charter v1.12
Target Area: Operations and Management

Description of Working Group:

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.

Several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, but none of them offer a vendor-neutral standardized way for applications and network services to transmit their needs to network controllers. 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. In particular, SUPA will focus on service specific models that allow applications to request certain network services to be created/deleted/modified. A network service can for example be a virtual link between two endpoints that uses certain properties, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.

Each network service can be represented by a service based POLICY model that can model a group of demands (i.e., actions and constraints) that are being initiated by applications that impose similar requirements on the communication network. The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the way of how the service policy model is generated, since it groups, unifies and shares the similar requirements imposed by a bulk of applications. SUPA will provide guidelines for mechanisms that can dynamically and on an interoperable manner, AUTOMATICALLY map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.

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 (1) at offering truly generic topology models for the standard northbound interface, and (2) that an application can communicate with network boxes, such as network controllers, and NEs, developed by different vendors.
SUPA will work on defining vendor-neutral standardized 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 network graph describes (1) topologies at different levels of abstraction, (2) the relationships between the abstraction levels and (3) applied service based policy, which are actions and constraints applied on these topologies.
SUPA may also define any mappings to any other network topology data models defined within the IETF.

The main goal of SUPA is to provide service specific models that allow applications to request network services to be created/deleted/modified. This can be realized by:
  o) model multiple topologies at different levels of abstraction using a network graph,
  o) model the relationships between the abstraction levels.
  o) transporting model instances using either NETCONF or RESTCONF

SUPA will ensure that in case any specific NETCONF/RESTCONF protocol requirements are identified, they will be communicated in a timely manner to the NETCONF working group. SUPA will consult with the YANG doctors to ensure that data models follow common practices.

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.
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, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.
3) Provide guidelines for mechanisms that can dynamically and on an interoperable manner, automatically map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.
4) Guidelines on how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation

Deliverables:
=============
o) Produce an informational RFC "Problem Statement and Use Cases".
o) Produce a standards-track RFC that specifies YANG models for a generic multi-layer network graph.
o) Produce standards-track RFCs that specify extensions for the generic YANG models defined above for network services that manage virtual links, traffic engineering and implementation of IPv6 transition mechanism and their enforcement to users.
o) Produce an informational RFC that provides the guidelines for mechanisms that can dynamically and on interoperable manner, automatically map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.
o) Produce an informational RFC that provides the guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC.

Milestones:
===========
Dec 2014  Initial "Problem Statement and Use Cases" WG I-D
Feb 2015  Initial "Multi-layer Network Graph YANG Model" WG I-D
Apr 2015  Initial service specific data model WG I-Ds
May 2015  Initial "Mapping Guidelines" WG I-D
Jun 2015  Submit "Problem Statement and Use Cases" I-D to IESG
Jul 2015  Initial "Authentication and Authorization" WG I-D
Sep 2015  Submit "Multi-layer Network Graph YANG Model" I-D to IESG
Nov 2015  Submit service specific data model I-Ds to IESG
Feb 2016  Submit "Mapping Guidelines" I-D to IESG
Apr 2016  Submit "Authentication and Authorization" I-D to IESG

---

From: Tina TSOU <[email-masked]>
Date: Fri, 26 Sep 2014 01:05:00 +0000

Dear all,

Sorry for confusion. The version Georgios and I sent out just now are the same, it came out of yesterday's (today's) group online discussion meeting.

Thank you,
Tina

From: Supa [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: Friday, September 26, 2014 8:32 AM
To: [email-masked]
Subject: [Supa] New SUPA charter

Hi all,

Best regards,
Georgios

Deliverables:
=============

Milestones:
===========

---

From: Parviz Yegani <[email-masked]>
Date: Fri, 26 Sep 2014 21:06:36 -0700

Great job Georgios. The charter is well written and nicely structured. The
notion of "network boxes", however, is a bit confusing. I'd rather to
replace it with "network nodes" or "network components". I also have some
other minor editorial comments. I will send it in a separate email. It's
good that you mentioned the SUPA WG (once formed) will collaborate with
other relevant groups within IETF (NETCONF, Yang doctors, ..) to ensure
consistency and avoid divergence or perhaps any possible duplication of
work.

Thanks,
Parviz

On Thu, Sep 25, 2014 at 5:31 PM, Georgios Karagiannis <
[email-masked]> wrote:

> 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.
>
>
>
> Several organizations outside of the IETF have defined various schemes for
> the configuration of network devices and specific network controllers, but
> none of them offer a vendor-neutral standardized way for applications and
> network services to transmit their needs to network controllers. 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. In
> particular, SUPA will focus on service specific models that allow
> applications to request certain network services to be
> created/deleted/modified. A network service can for example be a virtual
> link between two endpoints that uses certain properties, traffic
> engineering, implementation of IPv6 transition mechanism and their
> enforcement to users.
>
>
>
> Each network service can be represented by a service based POLICY model
> that can model a group of demands (i.e., actions and constraints) that are
> being initiated by applications that impose similar requirements on the
> communication network. The terms "UNIFIED" and "SHARED" used in the SUPA
> abbreviation, relate to the way of how the service policy model is
> generated, since it groups, unifies and shares the similar requirements
> imposed by a bulk of applications. SUPA will provide guidelines for
> mechanisms that can dynamically and on an interoperable manner,
> AUTOMATICALLY map services and policies defined on an abstract topology
> graph down to more detailed network graphs and specific network management
> and controlling policies.
>
>
>
> 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 (1) at offering truly
> generic topology models for the standard northbound interface, and (2) that
> an application can communicate with network boxes, such as network
> controllers, and NEs, developed by different vendors.
>
> SUPA will work on defining vendor-neutral standardized 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 network graph describes
> (1) topologies at different levels of abstraction, (2) the relationships
> between the abstraction levels and (3) applied service based policy, which
> are actions and constraints applied on these topologies.
>
> The main goal of SUPA is to provide service specific models that allow
> applications to request network services to be created/deleted/modified.
> This can be realized by:
>
> SUPA will ensure that in case any specific NETCONF/RESTCONF protocol
> requirements are identified, they will be communicated in a timely manner
> to the NETCONF working group. SUPA will consult with the YANG doctors to
> ensure that data models follow common practices.
>
>
>
> 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.
>
> 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, traffic engineering, implementation of IPv6 transition mechanism
> and their enforcement to users.
>
> 3) Provide guidelines for mechanisms that can dynamically and on an
> interoperable manner, automatically map services and policies defined on an
> abstract topology graph down to more detailed network graphs and specific
> network management and controlling policies.
>
> 4) Guidelines on how to use NETCONF (or RESTCONF) authentication and
> authorization mechanisms to achieve protection and isolation
>
>
>
> Deliverables:
>
> =============
>
> o) Produce standards-track RFCs that specify extensions for the generic
> YANG models defined above for network services that manage virtual links,
> traffic engineering and implementation of IPv6 transition mechanism and
> their enforcement to users.
>
> o) Produce an informational RFC that provides the guidelines for
> mechanisms that can dynamically and on interoperable manner, automatically
> map services and policies defined on an abstract topology graph down to
> more detailed network graphs and specific network management and
> controlling policies.
>
> o) Produce an informational RFC that provides the guidelines on using
> NETCONF (or RESTCONF) authentication and authorization mechanisms to
> achieve security protection and isolation' as an Informational RFC.
>
>
>
> Milestones:
>
> ===========
>
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>
>

-- 
Dr. Parviz Yegani
(408) 759-1973 mobile
[email-masked]

---

From: Parviz Yegani <[email-masked]>
Date: Sat, 27 Sep 2014 13:47:58 -0700

Thanks,
Parviz

-- 
Dr. Parviz Yegani
(408) 759-1973 mobile
[email-masked]

---

From: Kostas Pentikousis <[email-masked]>
Date: Mon, 29 Sep 2014 17:02:09 +0200

Hi Georgios,

I second Parviz, it’s much better after the recent revisions. A few comments wrt to the version at https://github.com/liushucheng/SUPA/wiki/SUPA-Charter

Do we need this phrase: "to shift the balance [of costs?] in their favor"? SUPA should not be a zero-sum game. Everyone should benefit (vendors, operators, admins, users, new service providers).

Do we REALLY have to capitalize POLICY, UNIFIED, SHARED, and AUTOMATICALLY? :)

The paragraph starting with "Some IETF working groups..." may be useful to motivate chartering the WG, but I'm not sure it should be part of the final charter.

Finally, the last paragraphs starting with "SUPA will work on defining... " and ending with the section on Work Items has a bit of overlap with the remaining text (Work Items, Deliverables). I have a few more editorial comments (e.g. s/started work relating/started work related), but we can handle that offline.

Best regards,

Kostas

PS: I took the liberty to CC NMRG as some folks in that group may have an interest in this line of work.

| Von: Parviz Yegani [mailto:[email-masked]] 
| Gesendet: Samstag, 27. September 2014 06:07
| An: Georgios Karagiannis
| Cc: [email-masked]
| Betreff: Re: [Supa] New SUPA charter
|
| Great job Georgios. The charter is well written and nicely structured. The notion of "network boxes", however, 
| is a bit confusing. I'd rather to replace it with "network nodes" or "network components". I also have
| some other minor editorial comments. I will send it in a separate email. It's good that you mentioned the
| SUPA WG (once formed) will collaborate with other relevant groups within IETF (NETCONF, Yang doctors, ..)
| to ensure consistency and avoid divergence or perhaps any possible duplication of work.

| Thanks,
| Parviz

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 29 Sep 2014 18:03:25 +0000

Hi George,

I like the intent of SUPA.  And that means I am going to make a lot of comments below :-).   Beyond that, I have two general comments on new items which could be considered for scope.

Comment #1: Focus on standardizing where the network element APIs might also change...
For me the highest value items to standardize are domain abstractions/models which:
  (a) can be acted upon as a whole externally, and
  (b) have supporting implications requiring incremental work on the network elements.

There are such example mini-domain-abstractions in the IP control plane today.   Consider VRRP, Anycast RP, ICCP: these are *very* close to domain policy abstractions.  To build on the lessons of these protocol types, how do we provide Policy abstractions which might be interesting *and* might need to support a dynamic convergence substrate?

The reason I am aiming here is that IETF standardization will be of most value where there is a distributed state machine linking activity across controller and network element. My suspicion is that many new service offerings which are purely "controller models" (i.e., requiring only existing network element interfaces) will likely be fleshed out in Open Source venues first.   If we don't pay attention to where we are different from Open Source, we could end up forced to rubber stamp Open Source work in SUPA.

Comment #2: What about networks with Multiple Controllers?
Eventually there will be many interacting controllers in the network.  A historical proof-point is the old phone network which had 800/freephone, Mobility, Local number portability, and other controllers tied to the SS7 network.  This pattern will repeat with IP network controllers.  Huge monolithic controllers will never dominate.   So in cases where there are multiple controllers touching a single device, how to you resolve domain and device consistency issues?

IMHO, the SUPA network Policy group could be chartered to handle these reconciliations.  In the end, these really are Policy reconciliation questions at the domain level.  The charter as written below is close to hitting that.

Anyway, my comments below do not focus on the two comments above, and are intended to hit just the text below...

From: Supa, September 25, 2014 8:32 PM

Hi all,

Best regards,
Georgios

<Eric> Versus equipment vendors? Versus end-user customers?  There is plenty of new value for all.

<Eric> From below in SUPA goals, it looks like SUPA might be considering models and enforcement between layers.  An L3VPN service might feel the same to an end user.   But an operator's underlying technology choices make exposure of technology and operational knobs very different. Especially across different classes of operators.  There are dozens of ways of fulfilling the L3VPN abstraction.  Describing the bindings digestibly to those who will consume which models in a way which also provides reuse will be non-trivial.

Several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, but none of them offer a vendor-neutral standardized way for applications and network services to transmit their needs to network controllers. 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. In particular, SUPA will focus on service specific models that allow applications to request certain network services to be created/deleted/modified.

<Eric> This will mean that the device servicing the SUPA abstraction will be able to commit create/delete/modify across a set of authoritative datastores within its domain.  This could even mean info authoritatively owned in different controllers. This can be done, but requires negotiation protocols under the covers to describe which transactions can be committed.  Doing this well means knowing how to revoke commitments as network conditions change.

A network service can for example be a virtual link between two endpoints that uses certain properties, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.

<Eric> I like this paragraph.  It highlights that various subsets of network elements have abstractions which can be controlled from the outside for a set purpose.

<Eric> Do you have examples of such models?   Especially ones where there are not WG drafts somewhere else?   The very hard part will be describing a higher level of abstraction which is really usable by the IETF WGs listed above.  This value statement should soon be matched with an example model which serves the set of technologies above.

<Eric> This need not just be about graphs.  Also see notes below about maintaining flexibility when trying at the same time to maintain relationships between abstraction levels.

The main goal of SUPA is to provide service specific models that allow applications to request network services to be created/deleted/modified.

This can be realized by:

<Eric> Just topologies?   There is a whole set of Policies which are not topology which are (simpler?) unsolved problems.   Based on work item 2 below, at minimum you should be able to add the word Policy here.

<Eric> This means you are binding the different abstraction models via logic / state machines.  What happens when one abstraction widely disconnects from existing lower level abstractions?  Is this dis-allowed?  This will be common for L3VPN, there are a huge number of ways to deliver the abstraction.

<Eric> "Any functional layer" might be hard.  To do this, the model will have to be very "meta".  Meta is fine, but this means you will have to describe relationships between layers in terms of values for specific objects.

<Eric> As I note above, L3PVN is one which particular worries me.  Especially as it relates to "model the relationships between the abstraction levels" above.  There is such a volume of implementation methods and users, I don't know what we gain here by formalizing the layered dependencies.   AFAIK, there will be an explosion of variants below the 1st level of abstraction.

Eric

Deliverables:
=============

Milestones:
===========

---

From: Georgios Karagiannis <[email-masked]>
Date: Tue, 30 Sep 2014 07:54:45 +0000

Hi Eric,

Thank you very much for your constructive comments. Please see in line.

> -----Original Message-----
> From: Georgios Karagiannis
> Sent: Tuesday, September 30, 2014 9:28 AM
> To: Georgios Karagiannis
> Subject: RE: New SUPA charter
> 
> 
> 
> From: Eric Voit (evoit) [mailto:[email-masked]]
> Sent: Monday, September 29, 2014 8:03 PM
> To: Georgios Karagiannis
> Cc: [email-masked]
> Subject: RE: New SUPA charter
> 
> Hi George,
> 
> I like the intent of SUPA.  And that means I am going to make a lot of
> comments below :-).   Beyond that, I have two general comments on new items
> which could be considered for scope.
[>] 

Georgios: Thank you very much.

> 
> Comment #1: Focus on standardizing where the network element APIs might also
> change. For me the highest value items to standardize are domain
> abstractions/models which:
> There are such example mini-domain-abstractions in the IP control plane
> today.   Consider VRRP, Anycast RP, ICCP: these are *very* close to domain
> policy abstractions.  To build on the lessons of these protocol types, how do
> we provide Policy abstractions which might be interesting *and* might need to
> support a dynamic convergence substrate?
[>] 

Georgios: Agree with this comment. Please note that the intention of SUPA is to include both (a) and (b).
You can help to clarify this in the text.

> 
> The reason I am aiming here is that IETF standardization will be of most value
> where there is a distributed state machine linking activity across controller
> and network element. My suspicion is that many new service offerings which are
> purely "controller models" (i.e., requiring only existing network element
> interfaces) will likely be fleshed out in Open Source venues first.   If we
> don't pay attention to where we are different from Open Source, we could end
> up forced to rubber stamp Open Source work in SUPA.
> 
> Eventually there will be many interacting controllers in the network.  A
> historical proof-point is the old phone network which had 800/freephone,
> Mobility, Local number portability, and other controllers tied to the SS7
> network.  This pattern will repeat with IP network controllers.  Huge
> monolithic controllers will never dominate.   So in cases where there are
> multiple controllers touching a single device, how to you resolve domain and
> device consistency issues?
[>] 

Georgios: This comment refers to a scenario where distributed controllers are used. 
Some text that we have in the charter used to describe interoperability, assumes that multi-controllers might be used, 
see the reply on one of your comments, below.

> 
> IMHO, the SUPA network Policy group could be chartered to handle these
> reconciliations.  In the end, these really are Policy reconciliation questions
> at the domain level.  The charter as written below is close to hitting that.
> 
> Anyway, my comments below do not focus on the two comments above, and are
> intended to hit just the text below.
> 
> SUPA (Shared Unified Policy Automation) charter v1.12 Target Area: Operations
> and Management
> 
> Programmatic ways to configure networks, often called software-defined, are
> considered by many network operators in order to shift the balance in their
> favor.
> 
[>] 

[>] 
Georgios: Agree that there is plenty of new value for all.
> 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.
> 
> <Eric> From below in SUPA goals, it looks like SUPA might be considering
> models and enforcement between layers.  An L3VPN service might feel the same
> to an end user.   But an operator's underlying technology choices make
> exposure of technology and operational knobs very different. Especially across
> different classes of operators.  There are dozens of ways of fulfilling the
> L3VPN abstraction.  Describing the bindings digestibly to those who will
> consume which models in a way which also provides reuse will be non-trivial.
[>] 

Georgios: Agree, but this will be one of the values of SUPA, i.e., to address this non-triviality.
> 
> Several organizations outside of the IETF have defined various schemes for the
> configuration of network devices and specific network controllers, but none of
> them offer a vendor-neutral standardized way for applications and network
> services to transmit their needs to network controllers. 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. In particular, SUPA will focus on
> service specific models that allow applications to request certain network
> services to be created/deleted/modified.
> 
> <Eric> This will mean that the device servicing the SUPA abstraction will be
> able to commit create/delete/modify across a set of authoritative datastores
> within its domain.  This could even mean info authoritatively owned in
> different controllers. This can be done, but requires negotiation protocols
> under the covers to describe which transactions can be committed.  Doing this
> well means knowing how to revoke commitments as network conditions change.
[>] 

Georgios: yes, I agree with you. Netconf (or restconf) is intended to be used for this purpose.

> 
> A network service can for example be a virtual link between two endpoints that
> uses certain properties, traffic engineering, implementation of IPv6
> transition mechanism and their enforcement to users.
> 
> Each network service can be represented by a service based POLICY model that
> can model a group of demands (i.e., actions and constraints) that are being
> initiated by applications that impose similar requirements on the
> abbreviation, relate to the way of how the service policy model is generated,
> since it groups, unifies and shares the similar requirements imposed by a bulk
> of applications. SUPA will provide guidelines for mechanisms that can
> dynamically and on an interoperable manner, AUTOMATICALLY map services and
> policies defined on an abstract topology graph down to more detailed network
> graphs and specific network management and controlling policies.
> 
> <Eric> I like this paragraph.  It highlights that various subsets of network
> elements have abstractions which can be controlled from the outside for a set
> purpose.
[>] 

Georgios: Great.

> various topologies such as I2RS (L3 and routing topologies), ALTO (cost maps),
> SFC (service chain), none of these groups aim (1) at offering truly generic
> topology models for the standard northbound interface, and (2) that an
> application can communicate with network boxes, such as network controllers,
> and NEs, developed by different vendors.
> 
> <Eric> Do you have examples of such models?   Especially ones where there are
> not WG drafts somewhere else?   The very hard part will be describing a higher
> level of abstraction which is really usable by the IETF WGs listed
> above.  This value statement should soon be matched with an example model
> which serves the set of technologies above.
[>] 

Georgios: Actually, this example comes very close to your comment #2, where the network boxes are multi-controllers.

> 
> SUPA will work on defining vendor-neutral standardized 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 network graph describes (1)
> topologies at different levels of abstraction, (2) the relationships between
> the abstraction levels and (3) applied service based policy, which are actions
> and constraints applied on these topologies.
> <Eric> This need not just be about graphs.  Also see notes below about
> maintaining flexibility when trying at the same time to maintain relationships
> between abstraction levels.
[>] 

Georgios: No, it is not only about graphs. Please note that in our provided definition a network graph, includes policies and relationships between abstraction levels.

> <Eric> Just topologies?   There is a whole set of Policies which are not
> topology which are (simpler?) unsolved problems.   Based on work item 2 below,
> at minimum you should be able to add the word Policy here.
[>] 

Georgios: Agree. . Please note that in our provided definition a network graph, includes policies and relationships between abstraction levels.

> <Eric> This means you are binding the different abstraction models via logic /
> state machines.  What happens when one abstraction widely disconnects from
> existing lower level abstractions?  Is this dis-allowed?  This will be common
> for L3VPN, there are a huge number of ways to deliver the abstraction.
[>] 

Georgios: Thanks for providing hints on the solution space. I agree with you that such details need to be incorporated in the solution space.

> requirements are identified, they will be communicated in a timely manner to
> the NETCONF working group. SUPA will consult with the YANG doctors to ensure
> that data models follow common practices.
> 
> <Eric> "Any functional layer" might be hard.  To do this, the model will have
> to be very "meta".  Meta is fine, but this means you will have to describe
> relationships between layers in terms of values for specific objects.
[>] 

Georgios: maybe values and characteristics.
> L3VPNs, traffic engineering, implementation of IPv6 transition mechanism and
> <Eric> As I note above, L3PVN is one which particular worries me.  Especially
> as it relates to "model the relationships between the abstraction levels"
> above.  There is such a volume of implementation methods and users, I don't
> know what we gain here by formalizing the layered dependencies.   AFAIK, there
> will be an explosion of variants below the 1st level of abstraction.
[>] 

Georgios: By formalizing the layered dependencies we can stimulate interoperability.

> o) Produce standards-track RFCs that specify extensions for the generic YANG
> models defined above for network services that manage virtual links, traffic
> engineering and implementation of IPv6 transition mechanism and their
> enforcement to users.
> o) Produce an informational RFC that provides the guidelines for mechanisms
> that can dynamically and on interoperable manner, automatically map services
> and policies defined on an abstract topology graph down to more detailed
> network graphs and specific network management and controlling policies.
> o) Produce an informational RFC that provides the guidelines on using NETCONF
> (or RESTCONF) authentication and authorization mechanisms to achieve security
> protection and isolation' as an Informational RFC.
> 
> Milestones:
> ===========
> Dec 2014  Initial "Problem Statement and Use Cases" WG I-D Feb 2015  Initial
> "Multi-layer Network Graph YANG Model" WG I-D Apr 2015  Initial service
> specific data model WG I-Ds May 2015  Initial "Mapping Guidelines" WG I-D Jun
> 2015  Submit "Problem Statement and Use Cases" I-D to IESG Jul 2015  Initial
> "Authentication and Authorization" WG I-D Sep 2015  Submit "Multi-layer
> Network Graph YANG Model" I-D to IESG Nov 2015  Submit service specific data
> model I-Ds to IESG Feb 2016  Submit "Mapping Guidelines" I-D to IESG Apr
> 2016  Submit "Authentication and Authorization" I-D to IESG
> 
> 

Best regards,
Georgios

---

From: Georgios Karagiannis <[email-masked]>
Date: Tue, 30 Sep 2014 10:21:23 +0000

Dear Kostas,

Thank you very much for the provided comments on the SUPA charter!

Please see in line!

> From: Kostas Pentikousis [mailto:[email-masked]]
> Sent: Monday, September 29, 2014 5:02 PM
> To: Parviz Yegani; Georgios Karagiannis
> Cc: [email-masked]; [email-masked]
> Subject: AW: [Supa] New SUPA charter
> 
> Hi Georgios,
> 
> I second Parviz, it’s much better after the recent revisions. A few comments
> wrt to the version at https://github.com/liushucheng/SUPA/wiki/SUPA-Charter
> 
> Do we need this phrase: "to shift the balance [of costs?] in their favor"?
> SUPA should not be a zero-sum game. Everyone should benefit (vendors,
> operators, admins, users, new service providers).
[>] 
Georgios: Agree with you, that everyone should benefit (vendors,
operators, admins, users, new service providers).
We need to rephrase this text. 

> Do we REALLY have to capitalize POLICY, UNIFIED, SHARED, and AUTOMATICALLY? :)
[>] 
Georgios: not really, we just used them to make the emphasize how the SUPA abbreviation relates to the charter description. I assume that we can mark these words using another method, e.g., ""

> 
> The paragraph starting with "Some IETF working groups..." may be useful to
> motivate chartering the WG, but I'm not sure it should be part of the final
> charter.
[>] 

Georgios: Not sure, how we should handle this issue. We used the paragraph to show the relation with other IETF WGs.

> 
> Finally, the last paragraphs starting with "SUPA will work on defining... "
> and ending with the section on Work Items has a bit of overlap with the
> remaining text (Work Items, Deliverables). 
[>] 

Georgios: Thanks,  we will try to remove the overlap as much as possible.

I have a few more editorial
> comments (e.g. s/started work relating/started work related), but we can
> handle that offline.
[>] 

Georgios: thank you very much!

Best regards,
Georgios

> | Great job Georgios. The charter is well written and nicely structured.
> | The notion of "network boxes", however, is a bit confusing. I'd rather
> | to replace it with "network nodes" or "network components". I also
> | have some other minor editorial comments. I will send it in a separate
> | email. It's good that you mentioned the SUPA WG (once formed) will
> collaborate with other relevant groups within IETF (NETCONF, Yang doctors, ..)
> to ensure consistency and avoid divergence or perhaps any possible duplication
> of work.
> 
> | Thanks,
> | Parviz