Re: [Supa] SUPA questions

[John Strassner <[e-mail]>]

Juergen wrote: " I think the idea is that policy is expressed via a data model, not via a new language. Some of the infrastructure should be generic (e.g. binding a policy to date/time) but then there will be specific extensions. SUPA is planning to focus on inter-datacenter traffic management as a use-case via VPNs and hence the specific extension will have to detail VPN properties, not QoS or access control or generic policy routing properties."

I **almost** agree. :-)

I think that what is required is to express policy as an information model, and in a form more generic than that defined in RFC3060 and related drafts (since they only define one type of (limited) policy rule, of type condition-action).

Then, given a **single** information model, multiple data models could be derived from it that can interoperate because they are all using the same concepts. Without this single information model, the data models will likely be designed in a siloed fashion, and interoperability will suffer.

Finally, if we define an information model, then we can use its components to help define a language (intent-based or otherwise). Without the information model, then how do we define a technology-neutral grammar for the language? (Note: I am still assuming that the "P" in SUPA stands for policy, and that we still want to build a language. If this is indeed true, then the first step should be the information model, so as to make the language as generic and useful as possible. I am also assuming that we are talking a Domain-Specific Language, not Python^2.)

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD


Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050
  Office:  +1.408.330.4923
  Email:   [e-mail]




-----Original Message-----
From: Supa [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, February 04, 2015 8:47 AM
To: Benoit Claise
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Supa] SUPA questions

On Tue, Feb 03, 2015 at 11:38:37AM -0500, JF Tremblay wrote:
> > 
> > Same question as during the bar BoF: what is the connection with I2RS in terms of topology?
> > When I spoke to Alia Atlas some months ago, she mentioned that the topology would be done in I2RS.
> 
> Right. Alia said I2RS was willing to continue this work, but: 
> - This wasn’t discussed in Hawaii (it wasn’t on the agenda and draft-clemm-i2rs-yang-network-topo-01 was expired at that time)
> - There’s been very little discussions on this topic on the I2RS list for the past year. 
> 
> The good news is that topology work is on the agenda for the I2RS interim next Thursday (see http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams <http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams>). Supa participants are willing to re-use the work of other groups such as I2RS, as long as a timely completion envisioned. 
>

It seems that having means to express topologies at various layers is
essential if we want to move from managing devices to managing
networks.  For me, having a clear notion how we look at topologies is
as essential has having a clear notion how we look at interfaces when
we write device data models.

I2RS has topology work in their charter because they need to work with
routing topology. SUPA has topology work in their charter draft
because they need to work with network topologies and service
toplogies. I think there is topology work in some below IP working
groups as well.

I hope that the IESG looks into this issue and finds a way to address
it. One option could be to create a tightly focused short lived WG
that comes up with a generic topology model and to revise other WG
charters such that they work with the result produced by the WG. There
sure are other options one could consider/try. But I believe some
leadership action is needed here.

I assume SUPA will be happy to work with any solution the IESG seems
to be appropriate to address the need for topology data models. But
until there is a clear path, we thought to keep it in the charter as
an indication of "we need this" (and it helps to get IESG member
attention for this issue I guess).

> > Questions on the charter (next to the ones I asked above)
> > - It seems that you discuss multiple use cases in different drafts but I don't see any in the charter as deliverable?

Yes, we will fix that.

> > How would you know if you are successful?
> > On the other hand, I see in the charter text:
> > The first use case that the working group will focus on will be VPN
> > inter-datacenter traffic management, including the automated
> > provisioning of site-to-site virtual private networks (VPNs) of
> > various types (for example IPsec, tunnels, MPLS L2 and L3).
> > "VPN, IPSEC, tunneles, MPLS L2 or L3", they look to me as multiple use cases, at least multiple distinct technolgies, and therefore as a huge piece of work

The idea was to try to be as much as possible agnostic to the VPN
technology. You think this won't be feasible?

> > -  "A set of policy rules is then defined to manage the service"
> > I don't know what you mean by "policy rules"? A new language? A set of YANG models, depending on the use case (Policy-based routing, QoS rate-limiting policy, ACL drop policy, etc...), something else?      
> 
> The policy side is also unclear to me. But again, this would be a high-level top-down approach. I like what’s described in draft-hares-i2rs-info-model-policy-02 (and the related presentation at http://tools.ietf.org/agenda/90/slides/slides-90-i2rs-2.pdf <http://tools.ietf.org/agenda/90/slides/slides-90-i2rs-2.pdf>), but again, that’s an I2RS document. 
> 

I think the idea is that policy is expressed via a data model, not via
a new language. Some of the infrastructure should be generic
(e.g. binding a policy to date/time) but then there will be specific
extensions. SUPA is planning to focus on inter-datacenter traffic
management as a use-case via VPNs and hence the specific extension
will have to detail VPN properties, not QoS or access control or
generic policy routing properties.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

_______________________________________________
Supa mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/supa