Re: [Supa] SUPA "bar" bof at IETF 91 Honolulu

["Hosnieh Rafiee" <[e-mail]>]

My name is missed among remote participants J

 

 

From: Supa [mailto:[e-mail]] On Behalf Of JF Tremblay
Sent: Wednesday, November 12, 2014 12:34 AM
To: [e-mail]
Subject: [Supa] SUPA "bar" bof at IETF 91 Honolulu

 

These are the minutes of the “bar” bof for supa. Let me know if you spot any major error. 

 

---------------------------------------------------

SUPA “bar" bof minutes

IETF 91 - Hawaii - Room South Pacific II

2014-11-10, 8:00-9:30

---------------------------------------------------

 

Chair: Scott Bradner

 

Attendees (32)

Benson Schliesser, Brocade

Andy Bierman, Yuma Works

Dan Romascanu, Avaya

Qiao Fu, China Mobile

Dapeng Liu, China Mobile

Hui Dang, China Mobile

Audric Schiltknecht, Viagenie

Jean-Francois Tremblay, Viagenie

Marc Blanchet, Viagenie

Dave Allan, Ericsson

Will Liu, Huawei

Tina Tsou, Huawei

Marco Liebsch, NEC

Rob Shakir, BT

Carl Moberg, Tail-F/Cisco

Parviz Yegani, Juniper

Joel Jaeggli, Fastly

Benoit Claise, Cisco

Fernando Gont, UTN/FRH

Ron Bonica, Juniper

Mehmet Ersue, Nokia

Bert Wijnen, RIPE NCC

Eric Voit, Cisco

Peter Van Horne, Cisco

Balazs Lengyel, Ericsson

Yunsing Lu, Futurewave

Andrew Qu, MediaTek

Dhruv Dhody, Huawei

Guang Ying Zheng, Huawei

Gang Yan, Huawei

Bing Liu, Huawei

Xia Chen, Huawei

 

Remote participants (possibly incomplete list):

Ying Cheng, China Unicom

Luis, Telefonica

Chongfeng Xie, China Telecom

Qiong Sun, China Telecom

Juergen Schoenwaelder, Jacobs University 

Kostas Koustikousis, EICT

 

-----------------

 

 

First speaker (20 min) - Georgios Karagiannis is the speaker

 

Georgios Karagiannis (GK):

This is a presentation of SUPA. We tought about changing the name, but it will remain the same. 

I'd like to emphasis the problem to solve. 

Operators would like to apply vendor-neutral service abstractions.

(GK disagreed with the above sentence and suggested the following text, but these aren't official minutes:

          Service providers and network operators consider network configuration, optimization and automation using software-defined networking tools and techniques, 

          to provide significant benefits in deployment agility and fast time to market

          They would like to achieve this configuration automation by introducing multi-level and multi-technology network service abstractions.

)

This can be realized in many ways. What's missing is a multi-level multi-technology abstraction. 

The main goal here is to provide this network service abstraction. 

These would be described with yang models. 

Such network service abstractions are, for example, VPNs. 

To allow applications to request multiple services from controllers. 

The applications would have network services that can be created deleted or updated rapidly. 

 

Scott Bradner (SB): What kind of applications are these?

 

GK: These can be end-user applications or network management. Includes OSS types of systems. 

(GK disagreed with the above sentence and suggested the following text:

          The end user applications or network management applications can request network services from the network. The Application block shown in the figure represents a box that

          Is owned either by a service provider or a network operator (in this case is an OSS type of system). This box runs also the service logic associated with Application(s).

)

 

Ron Bonica (RB): Is it vendor neutral or technology neutral? It would have to be both. 

 

Andrew Qu (?): Possible use case: could be temporary instances of networks. 

 

SB: sounds like a network management application. 

Are you thinking about bounding the service space?

 

GK: No. It's a service abstraction. It's linked to a specific service. 

I'd like to show the architecture, this is the SUPA architecture overview. 

There are applications talking to one or multiple controllers. 

There are 3 layers, the top are applications, the middle shows controllers, the bottom network elements. 

 

Rob Shakir (RS): Which interface do you target? No one operator is the same, no need to be vendor neutral. 

 

GK: It would provide an abstract view for VPN. Only the controller has a complete view of the network. It provides an abstract view for the application. 

 

Andy Bierman (AB): Isn't this what OpenStack is doing? 

 

GK: Not sure OpenStack would provide these services in a vendor neutral. 

 

AB: The question is... this wasn't the question. 

 

GK: Service specific yang models are providing different abstractions to application

 

Benoit Claise (BC): What is the link with the topology that is done in i2rs? 

 

GK: I2RS defines the topology, it could be used. We're focusing on the binding topology model. 

 

BC: is there anything that needs to be done regarding topology?

 

GK: If we are focusing on VPN, we can use the routing topology model defined in i2rs. 

 

RS: My understand was that this was a top level high level topology model. 

At the same time, you say VPN is just an example. 

 

GK: What I understand from Benoit.

 

RB: You say the topology the controller creates.  

One is the service abstraction model, the second is the detailed topology model. 

When you talk about the topology for the VPN, you could mean two things. The hub and spoke, or the connections between the PEs. 

 

GK: [...]

 

BC: It was exactly my question, what kind of topology do you need. 

 

RB: If it's the later, a lot of wgs are working on it. 

 

GK: One important thing is, we're [...].

 

RS: Have you tried to build this topology model and use it at all?

We did that. And the hard thing is not to build the layers above it. The hard thing is grouping things for them to make sense for the network. 90% is building things to make sense in the network. 

[...]

A lot of things here are not new things. 

 

GK: We actually want to do is to provide the application with a service logic. 

(GK disagreed with the above sentence and suggested the following replacement: 

          GK: We actually want to do is to provide a network service specific abstraction to the Application, such that the service logic associated with this Application will be able 

          to use this network service specific abstraction during the instantiation and running phase of the application.

)

 

RS: You can't look at it from one side only. I get what you're saying, but trying to break it might make things easier, but they're linked. 

 

Marco Liebsch (ML): In addition to the abstraction and the mapping. This is configuration of the network function and [...].

 

GK: The problem statement draft says that we do it.... if it's a hard problem to solve, we might leave it. It's something we need to define. 

 

Benoit: You want to use VPN as an example. BESS is chartered to do this. What's the connection? 

 

Parviz Yegani (PY): First thing: if there's a problem that needs to be solved. If there's an overlap, from other workgroups, first we want to see if there's an overlap to address. 

If there'S something like a crud operation mentioned here. You want to bring up the configuration, maintain the software, you want to do it as a different module. But first, we need to be in agreement for the problem to be solved. If there isn't an agreement, then we go talk about the charter. 

 

RS: The first slide says we're going to do this, but it never showed where the pain point is. 

 

GK: I agree we have to find if there's overlap with other wgs. 

Regarding your question Benoit, we're not focused ont BGP-based VPN. 

These are service abstractions. Maybe it's good to show one example. 

This is an example with topology abstraction. [showing a slide]

This is an example with VPN service. [showing another slide]

For example this controller would provide the endpoints. 

This is a version, a short description of how the service would work. 

 

Andy Bierman (AB): Is the goal of this work to provide a layered view that isolate the apps from the network elements or just a cache? 

 

GK: This is an isolation layer. 

 

 

Same presentation - Speaker changes to Eric Voit

 

Eric Voit (EV): Hi everybody. 

I'm actually coming not to say what supa should be. But to discuss something that isn't completely covered in the IETF. We have a demo of how this might fit in the IETF. 

First, a slightly controversial thing. 

There are now a number of abstractions in the network. 

We already have multi-domain abstractions

There's a range of ideas and of controllers. 

This is an idea of a service, a cloud policer. 

Say you're an amazon or a cloud service that will offer 100 Mbps to a client. 

You don't care if the policer is only in one box or not. 

This is a model that [...].

Not sure it belongs in netmod, in supa or else. 

There are over 100 yang models in ODL. 

Only roughly 30 of them are based on standards. 

This is a simple model with both service level and interface information in the model. 

We'll show this in a demo. What we have here is a global rule. Say we tie this to a subnet. 

Simple rule to configure the router this way. 

The controller, we say the global rate is the total rate of traffic offered. 

IT gives the total of traffic going through at any moment. 

We have 100mps service allocated, with two different rates sent to differnt routers. 

The goal is to dynamically change the configuration to provide a consistent data rate. 

To summarize: we have a multi-device abstraction that works across a domain. 

They are not real multi-device abstraction group. 

 

AB: you have statistics mapped to the application. 

If it's a service abstraction, it shouldn't care about the counters. 

 

EV: The service abstraction that's new, i want to configure 100 mbps. 

In terms of application, there's a difference between what's exposed northbound. 

Really simple: the app gets the stats and pushes down the data. 

The way ODL started, it's almost like a [...] it operates almost like a passthrough. 

 

Rob Shakir (RS): there's a fundamental divide between configuration and real time. 

Without making a judgement, it's hard to draw the line. 

 

EV: It's a fuzzy line between orchestration and real-time. What do we standardize, do we really need abstraction. 

Which abstractions do we care about? Not sure. There will be things that will be multi-box, some others will be single box. 

 

Burt Wijen (BW): We have a more basic problem. Who should hold the topology model. 

 

EV: Because there's no topology model, we do what we can in ODL. 

 

BW: That wasn't clear to me yet. The policer get the information to the app. 

 

EV: I'd be happy to talk about the model we have in netmod. In the demo, we're taking counter and summing them up, with a threshold. 

 

BW: You're saying you're configuration a network element... you would configure them separately. How do you control it's only one controller that touches the element. 

 

EV: Great question: we have models for that.

Where is it done? There a combination of top-domain controller and local control. 

 

Scott Bradner (SB): What do you do when someone changes on CLI something the yang model controls. It's not unachievable, it's a conflicting request. 

 

EV: We do have some answers. What we have working is the ability to know where the request comes from and the ability to reject the request. 

 

BW: [...]

 

EV: We're pulling the interface definition out of existing IETF documents. 

 

BW: This is how you'll get the data on the interface. 

 

EV: The mount discussion is in netmod on Friday. 

 

SB: I'd like the ADs to comment on where do they think it fits. 

 

Parviz Yegani (PY): We should first say: is there a problem supa can solve in ietf. 

Need a rough consensus on the problem. 

 

SB: There's a lot of different things, I didn't get a clear picture. 

Is it a service model, a network model. Could you describe what you thing it is. 

 

Benoit Claise (BC): Two ways to see things... a problem to be solved or let's look at the deliverables. 

 

GK: The main goal is the definition of service specific abstractions. 

 

BC: Can you give me a precise outcome. 

 

SB: the answer can't be "VPN" [addressing GK]. Don't talk about a particular think. 

 

GK: To provide this service abstraction. We had many types of services to address. We decide to limit the number. If you think this is not the right one... 

 

BC: you want to use one showcase, vpn or something else, to prove [...]

 

GK: For the sake of simplicity, the example was vpn. 

We have to limit the scope. 

 

BW: when I hear this and hear about abstract services, I think about what we did for routing. 

We have one generic thing that's common. There are a number of generic variables. 

We do something for VPN, with specific things, then we realized these are the same than another service. 

I would consider this before diving in a model. 

 

PY: after hearing from operators. 

 

RS: how many operators? 3? 

 

PY: We are a majority of vendors here. We have to listen to our customers. 

They bring these requirements to the ietf. we have to address at least one of their pain point. 

For supa, I really want to hear from operator what pain point we think we can address. 

We need to understand what requirements are driving the problem. 

 

RS: honestly, these arguments (capex, opex) are not considered in the ietf. 

Operators are driven by what affects their business

Abstracting away [...]

I'm unclear the right way is to do a set of model and expect operators to figure out how to use them. 

There will be a drive toward more standardization, but I'm not sure the time is right. 

 

SB: we heard a bunch of discussion. I'd like to ask for a sense of the ADs. It's too early to get a sense for the room. 

 

BC: We heard many things. Still not clear... I'm coming from the problem statement. 

I asked many times... I'm still not clear on your ideal deliverables, in an ideal world. 

These are for me simple questions, if you could answer these. 

I'm somehow waiting for some more homeworks. 

 

GK: we have done them...

 

BC: This is my summary for today. 

 

SB: I've asked for this many times. What's an application. It goes from the game on my laptop to a management application. Need to be more specific, what problem to solve and for whom. 

 

Tina Tsou (TT): To me, we have several operators in the room and online. The supa motivation is similar to a bgp model motivation. Network configuration model. Just a simple way to have a configuration model. 

 

SB: this came across as modeling both configuration and service, which is an ambiguity. 

We asked some people at Stanford. Feel of deja vu and a bit fuzzy, but some the basic stuff hasn't been expressed well enough. 

Whether it's use case or other what fuzzes the picture. 

You need to focus on things that matter for the carriers. 

 

GK: Operators are also participating in supa. We got requirements from them. 

 

BC: How many do you have. Can we have 10 of them?

We want to listen to operators. If you said: we have this agreement from many operators. 

You would carry way more weight. 

 

TT: we have operators on the line, they haven't talked. 

Ying Cheng (phone): there are several problems. We are deploying and need to find solutions to solve customers on-demand requirements thought an API. [...] We need to find an open architecture.  Thank you.

 

SB: thank you for your input. 

Some of this work might be very interesting, but needs more explanation from operators. 

 

Joel Jaeggli (JJ): The process of exploration si one thing. It needs to focus to turn into an IETF activity. 

It has to become a kernel that becomes actionable. Something that would be deliverable within a year, with a timescale. 

 

SB: we need to have a set of milestones. On a timescale. Why we're doing and which specific documents are required. 

 

---------------

 

JF