[OpenDaylight TSC] Fabric as a Service creation review
Another point I want to emphasize if I didn’t emphasize enough is there are more than openflow, ovsdb/openvswitch devices in the network out there and in fact, majority of devices are not . FaaS decouples physical network from upper services by fabric abstraction which makes upper services vendor/technology agnostic. FaaS targets not only one homogenous fabric but also aim for multiple fabric networks and could be used for multiple sites of DCN including DCI deployment.
Cheers!
Xingjun
Sent: Thursday, July 16, 2015 4:24 PM
To: Bainbridge, David; Colin Dixon; tsc@...; project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
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
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.
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).
- 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.
2.) How is this different from the existing approaches to similar problems already in OpenDaylight, e.g., GBP, NIC, VTN, OVSDB network virtualizationFaaS 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.
3.) Is the scope any more restricted than creating logical L2 and L3 networks?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:
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