Re: [Supa] SUPA questions

[Juergen Schoenwaelder <[e-mail]>]

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/>