Fabric as a Service creation review
|
Colin Dixon
During today's TSC call [0], we heard the project proposal for Fabric as a Service [1], but there was still active discussion going on when the call ended and many TSC members said that they would like to see more time for discussion on the mailing list before a vote. The major discussion points when we left off seemed to be:1.) How will this co-exist with existing projects in the same area, e.g., other projects that try to program devices via OpenFlow, OVSDB, etc. 2.) How is this different from the existing approaches to similar problems already in OpenDaylight, e.g., GBP, NIC, VTN, OVSDB network virtualization 3.) Is the scope any more restricted than creating logical L2 and L3 networks? Please discuss these and any other topics and when things peter out or converge, I'll start a vote either here or on the TSC call. Thanks, --Colin |
|
|
|
xingjun chu
1.) How will this co-exist with existing projects in the same area, e.g., other projects that try to program devices via OpenFlow, OVSDB, etc.
- I don’t see any conflicts there. FaaS complements existing projects as a common network abstraction layer bottom up. I can see the other projects leverage FaaS capability very nicely. We have done a GBP render based on FaaS with some vendor devices. - With this layer, more application centric model (Other than GBP, NIC,NEMO) could be easily brought in and implemented if users think existing cannot meet the needs. - FaaS decouples service and underneath low level interface, more southbound protocols and interfaces can be transparently supported without service layer changes. - FaaS allows user to define/choose devices to be managed under FaaS. If users choose not to, the device can be managed outside of FaaS. these are all configurable.
FaaS is to abstract physical device level services into network level services based on what network resource exists and does without loosing the capability of the nework. So it has clear mapping between FaaS model and physical network. With this layer, Users’ network needs can be rendered to a more generic and simplified model other than technology, vendor specific devices level interfaces.
No, besides L2/L3, it also provides QoS/Policy primitives inside and between L2/L3 networks. Moreover, it will coordinate with SFC project to provide SFC capabilities between logical networks.
-Xingjun
From: project-proposals-bounces@... [mailto:project-proposals-bounces@...]
On Behalf Of Colin Dixon
Sent: Thursday, July 16, 2015 2:25 PM To: tsc@...; project-proposals@... Subject: [Project-proposals] Fabric as a Service creation review
During today's TSC call [0], we heard the project proposal for Fabric as a Service [1], but there was still active discussion going on when the call ended and many TSC members said that they would like to see more time for discussion on the mailing list before a vote. The major discussion points when we left off seemed to be:
Please discuss these and any other topics and when things peter out or converge, I'll start a vote either here or on the TSC call.
Thanks, --Colin |
|
|
|
xingjun chu
More on first question.
FaaS is to provide Fabric abstraction, more importantly it provides Cross Fabric services. It intends to decouple upper layer service from different lower level fabric technology. If Existing projects already did good job on per technology or single Fabric control, FaaS can leverage that and can interact with existing project as a Fabric. For example, a openflow network can be viewed as a Fabric. We can have an adaptor within FaaS talking to openflow controller. Same to OVSDB.
Xingjun
From: Xingjun Chu
Sent: Thursday, July 16, 2015 3:06 PM To: 'Colin Dixon'; tsc@...; project-proposals@... Subject: RE: [Project-proposals] Fabric as a Service creation review
1.) How will this co-exist with existing projects in the same area, e.g., other projects that try to program devices via OpenFlow, OVSDB, etc.
- I don’t see any conflicts there. FaaS complements existing projects as a common network abstraction layer bottom up. I can see the other projects leverage FaaS capability very nicely. We have done a GBP render based on FaaS with some vendor devices. - With this layer, more application centric model (Other than GBP, NIC,NEMO) could be easily brought in and implemented if users think existing cannot meet the needs. - FaaS decouples service and underneath low level interface, more southbound protocols and interfaces can be transparently supported without service layer changes. - FaaS allows user to define/choose devices to be managed under FaaS. If users choose not to, the device can be managed outside of FaaS. these are all configurable.
FaaS is to abstract physical device level services into network level services based on what network resource exists and does without loosing the capability of the nework. So it has clear mapping between FaaS model and physical network. With this layer, Users’ network needs can be rendered to a more generic and simplified model other than technology, vendor specific devices level interfaces.
No, besides L2/L3, it also provides QoS/Policy primitives inside and between L2/L3 networks. Moreover, it will coordinate with SFC project to provide SFC capabilities between logical networks.
-Xingjun
From:
project-proposals-bounces@... [mailto:project-proposals-bounces@...]
On Behalf Of Colin Dixon
During today's TSC call [0], we heard the project proposal for Fabric as a Service [1], but there was still active discussion going on when the call ended and many TSC members said that they would like to see more time for discussion on the mailing list before a vote. The major discussion points when we left off seemed to be:
Please discuss these and any other topics and when things peter out or converge, I'll start a vote either here or on the TSC call.
Thanks, --Colin |
|
|
|
David Bainbridge
Subject: Re: [Project-proposals] Fabric as a Service creation review
This is the assumption that I would like to challenge. Every one of the projects that have come along in this area have essentially believed that they represent the bottom most layer and the other projects could be modified to use this new layer. This essentially doesn’t happen and the new project becomes another layer that is used by a few projects, but not all and thus represents a point of confusion and compatibility.
|
|
|
|
xingjun chu
See my answers inline
-Xingjun
From: Bainbridge, David [mailto:dbainbri@...]
Sent: Thursday, July 16, 2015 3:39 PM To: Xingjun Chu; Colin Dixon; tsc@...; project-proposals@... Subject: Re: [Project-proposals] Fabric as a Service creation review
Subject: Re: [Project-proposals] Fabric as a Service creation review
This is the assumption that I would like to challenge. Every one of the projects that have come along in this area have essentially believed that they represent the bottom most layer and the other projects could be modified to use this new layer. This essentially doesn’t happen and the new project becomes another layer that is used by a few projects, but not all and thus represents a point of confusion and compatibility.
Xingjun-> I think this is a good thing. At least good intention. We should have such intention to build a great software based on each other’s value/contribution either to customer or to other project. 1+1 > 2 . Let’s leave it to customers (internal or external) to determine any project’s destiny. That’s being said, based on our experience with customers, FaaS has a good level abstraction a it provides a framework to build network service across different fabrics which could based on different technology, vendor devices. Especially it decouples service with technology, customers like that. it provides no vendor locked in as well as well layered visibility for trouble shooting (device, fabric, network, service).
|
|
|
|
David Bainbridge
I agree building on each others technology is a good thing. That is not what I am challenging. What I am challenging is that GBP can argue at some level, it is this lowest level abstraction that others should use as is OVSDB, etc. And I quite frankly doubt that if FaaS is approved and build everyone will start to flock to it and build everything top of it because there is no way to force people to do so, projects have other priorities so they won’t convert unless they are forced, and your team won’t be able to make the changes to all the project to make them all communicate to FaaS. In short, ODL does not have a common vision and implementation that supports a common lower layer, nor do they have any way to enforce a direction. As such any new project the has this as a goal turns into a “me too” project. What I would like to see is some group (TSC?) spend some time and come up with a common vision and direction and then move projects toward that direction. If that common vision involves FaaS that is fine, but again without that “me too”.
|
|
|