Re: [Supa] SUPA questions

[Benoit Claise <[e-mail]>]

Hi,
> 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).
Fair enough.

Note: I believe the charter proposal is not clear on the network 
topology versus service topology

This working group introduces the concepts of multi-level (multiple
levels of abstraction) and multi-technology (e.g., IP, VPNs, MPLS)
network abstractions to address the current separation between
development and deployment operations.



>
>>> 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?
One one side, you want a service-specific topology, so "VPN, IPSEC, 
tunnels, MPLS L2 or L3" specific topologieS I guess.
One the other end you want a technology agnostic topology, like "VPN" I 
guess. Is this feasible, I don't know? Is this wanted? I guess the 
subset of the topology (what you called a service topology) is actually 
the view that an application (*) requires to monitor and manage his own 
set of services.
(*) in architecture composed of: an application <-> controller <-> 
network elements

>
>>> -  "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.
I guess I don't understand the connection between a policy and a service.

Regards, Benoit
>
> /js
>