Re: [Supa] SUPA questions

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Feb 12, 2015 at 01:54:02PM +0100, Benoit Claise wrote:
> 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.
>

Abstraction simply means you leave out details. Consider a customer
using servers located on a varying number of nodes in different data
centers and the service request is to have protected connectivity
between the nodes in the different data centers. The connectivity
needs to have certain properties in terms of throughput, latency,
availability, ...

This service model is too abstract to implement it directly by an
automated system. A network operator who wants to provide the service
requested by the customer has to map things to the infrastructure.
Policy-driven means that the mapping from the rather abstract service
to the network infrastructure is policy driven, e.g. by using policy
rules. This allows, for example, the operator to route traffic between
data centers different depending on time of day or the current
utilization of links etc.

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

You may call it application - it is the thing that manages the
services. In the slides we called it a service manager (I personally
find application a bit too opaque but perhaps I am just a bit old
fashioned).

> >>>-  "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.
>

I tried to explain it above. The policy controls how an abstract
service request is mapped to the infrastructure and the goal is that
the mapping is dynamic (within the bounds of the policy) and not
static.

/js

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