Subject: Re: [Teas] [Supa] SUPA questions

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Feb 2015 00:54:56 -0000

[Blind copying TEAS - please continue the discussion on the SUPA list]

I don't want to say "do it my way", but on the subject of abstraction and virtualisation, I hope you will look at http://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/

The topic of aggregation, abstraction, virtualisation, network layering, and so forth has been the subject of almost continual work in the routing area for the last 15 years. So I don't think it fair to say "This working group introduces...."

Juergen is right that "policy" is an important input to the automation of abstraction, and the interested people may be right that that policy needs to have a configuration method. I am not completely convinced that this is critical for standardisation because the point at which abstraction is achieved is likely to be a single point of "topology export" from a network and so the configuration is applied at that point and not at a variety of routers.

If (and this is not certain long-term) export of virtualised topology is via BGP-LS (which is how a number of implementations have done it) then policy is, of course, easily imposed via BGP export policies.

Thanks,
Adrian

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