|
Hi David, good point
I really would like to hear more community opinions on whether we should provide single or multiple low-level network abstractions in OpenDaylight. I personally think the first is less confusing for both users and developers, however experience shows we never managed to agree on that. So I start to question myself whether this is really feasible given people different opinions and users different expectations. In any case I would not mind to help or collaborate in a low-level network abstraction definition if most people think single abstraction is what we should be doing.
BR/Luis
On Jul 16, 2015, at 2:27 PM, Bainbridge, David < dbainbri@...> wrote:
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).
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”.
- 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 virtualization
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.
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 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.
_______________________________________________TSC mailing listTSC@...https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
After reading the slides I still do not see how this solves the problem you claim it does.
It seems it is inserting yet another layer, which will suffer from velocity issues when FaaS lags underlying network element features causing anything leveraging it to lag.
It’s another layer which will obfuscate any troubleshooting and diagnostics.
I see nothing on multi tenancy support.
I see nothing on instrumentation support.
Slide5: Every "bad thing" you cite as a reason for FaaS (monolithic, topdown) you are re-injecting. This seems like a monolithic shim, without any indication of the precise services it will offer.
Slide 5: You cite “policy between logical elements” … I’m sorry, you are doing what now? So its policy… between logical elements, but this will transform into concrete policy how exactly? And who’s policy? What models are you using and translating?
I can’t see how GBP could possibly leverage or adopt this, which is fine, but please don’t claim that it’s offering a service that others can consume, because I just cannot see how that is possible.
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.
2.) How is this different from the existing approaches to similar problems already in OpenDaylight, e.g., GBP, NIC, VTN, OVSDB network virtualization
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.
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 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 for your comments See answers inline
Regards
Xingjun
toggle quoted message
Show quoted text
From: alagalah [mailto:alagalah@...]
Sent: Wednesday, July 22, 2015 12:15 AM
To: Xingjun Chu; Colin Dixon; tsc@...; project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
After reading the slides I still do not see how this solves the problem you claim it does.
It seems it is inserting yet another layer, which will suffer from velocity issues when FaaS lags underlying network element features causing anything leveraging
it to lag.
---> Without FaaS, rendering from high level language such as GBP, Intent .. to physical devices appears to me very monolithic, I don’t see how it can be done.
FaaS will make the monolithic structure well layered. It is not “insert another layer”. It tries to turn the monolithic into a well defined layered structure. For example, a VXLAN Fabric object is a management object which represents VXLAN underlay topology
with a optional VXLAN control plane logic . The object provides L2 network CRUD operations as well as L3 routing capabilities between those L2 networks. You can also define policies between those networks.
It’s another layer which will obfuscate any troubleshooting and diagnostics.
àjust opposite, since Fabric is formed bottom up. It has clear definition between
Fabric to a topology of network, how each L2 network is sliced and configured, troubleshooting will be easier. When something is wrong in the service level, the fault can be tracked down to a logical element, then fabric , finally to physical devices.
I see nothing on multi tenancy support.
-à
Tenant info can be maintained on the higher level such as GBP or NIC. I don’t see needs at fabric level . Since every objects such as l2 network, l3 router that are created on the fabric has global unique id which can be associated with tenant id on the higher
level. Unless we found such use case requires tenant info at this level.
I see nothing on instrumentation support.
è
Thanks . Yes Instrumentation will be there for every logical element. The state model for each logical element is still to be defined which will come
after we make the main functions working.
Slide5: Every "bad thing" you cite as a reason for FaaS (monolithic, topdown) you are re-injecting. This seems like a monolithic shim, without any indication of
the precise services it will offer.
--à
Check the wiki page, it has more information regarding what a Fabric can do.
Slide 5: You cite “policy between logical elements” … I’m sorry, you are doing what now? So its policy… between logical elements, but this will transform into concrete
policy how exactly? And who’s policy? What models are you using and translating?
-à
In currently implementation, the policy model is pretty much based on the ACL capability offered by most of vendor switches. But the model can be evolved as our work progress.
I can’t see how GBP could possibly leverage or adopt this, which is fine, but please don’t claim that it’s offering a service that others can consume, because I
just cannot see how that is possible
è
Hope the above explanation makes things a bit clearer ….
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.
2.) How is this different from the existing approaches to similar problems already in OpenDaylight, e.g., GBP, NIC, VTN, OVSDB network virtualization
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.
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
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.
_______________________________________________ TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
This is a separate topic which the TSC could entertain, but I think that holding FaaS to a much higher standard than we have other projects in the past here is likely capricious, so I'd like to factor it apart from voting on whether to move FaaS to incubation.
--Colin
On Sun, Jul 19, 2015 at 2:30 AM, Luis Gomez <ecelgp@...> wrote: Hi David, good point
I really would like to hear more community opinions on whether we should provide single or multiple low-level network abstractions in OpenDaylight. I personally think the first is less confusing for both users and developers, however experience shows we never managed to agree on that. So I start to question myself whether this is really feasible given people different opinions and users different expectations. In any case I would not mind to help or collaborate in a low-level network abstraction definition if most people think single abstraction is what we should be doing.
BR/Luis
On Jul 16, 2015, at 2:27 PM, Bainbridge, David < dbainbri@...> wrote: 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).
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”.
- 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 virtualization
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.
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 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.
|
|
|
Having read through this. It sounds like there is still spirited debate around how this will eventually fit into the broader OpenDaylight ecosystem, e.g., what other projects will use it and why, as well as some technical concerns about the approach. That being said, short of the community and TSC voicing these opinions and having the publicly noted, I don't think they actually stand in the way of the project being approved.
(As a personal aside, I can say that I would have liked to see more actual incorporating of TSC and community feedback as opposed to mechanical stating that the feedback is either wrong or already taken into account in the project, but that isn't required to get an incubation project.)
I'm not 100% sure what the intended scope is based on that. At a high-level, a "fabric" is basically any networking service and so the scope would then be incredibly broad, e.g., pretty much any network task. Later on it talks specifically about L2 and L3, but in this e-mail chain Xingjun said it should also include QoS and Policy.
So, concretely: is the scope really "anything that might be used to provide a fabric abstraction including L2 and L3 virtual networks, QoS, and Policy including SFC"?
Thanks,
--Colin
On Wed, Jul 22, 2015 at 10:23 AM, Xingjun Chu <Xingjun.Chu@...> wrote:
Thanks for your comments See answers inline
Regards
Xingjun
From: alagalah [mailto:alagalah@...]
Sent: Wednesday, July 22, 2015 12:15 AM
To: Xingjun Chu; Colin Dixon; tsc@...; project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
After reading the slides I still do not see how this solves the problem you claim it does.
It seems it is inserting yet another layer, which will suffer from velocity issues when FaaS lags underlying network element features causing anything leveraging
it to lag.
---> Without FaaS, rendering from high level language such as GBP, Intent .. to physical devices appears to me very monolithic, I don’t see how it can be done.
FaaS will make the monolithic structure well layered. It is not “insert another layer”. It tries to turn the monolithic into a well defined layered structure. For example, a VXLAN Fabric object is a management object which represents VXLAN underlay topology
with a optional VXLAN control plane logic . The object provides L2 network CRUD operations as well as L3 routing capabilities between those L2 networks. You can also define policies between those networks.
It’s another layer which will obfuscate any troubleshooting and diagnostics.
àjust opposite, since Fabric is formed bottom up. It has clear definition between
Fabric to a topology of network, how each L2 network is sliced and configured, troubleshooting will be easier. When something is wrong in the service level, the fault can be tracked down to a logical element, then fabric , finally to physical devices.
I see nothing on multi tenancy support.
-à
Tenant info can be maintained on the higher level such as GBP or NIC. I don’t see needs at fabric level . Since every objects such as l2 network, l3 router that are created on the fabric has global unique id which can be associated with tenant id on the higher
level. Unless we found such use case requires tenant info at this level.
I see nothing on instrumentation support.
è
Thanks . Yes Instrumentation will be there for every logical element. The state model for each logical element is still to be defined which will come
after we make the main functions working.
Slide5: Every "bad thing" you cite as a reason for FaaS (monolithic, topdown) you are re-injecting. This seems like a monolithic shim, without any indication of
the precise services it will offer.
--à
Check the wiki page, it has more information regarding what a Fabric can do.
Slide 5: You cite “policy between logical elements” … I’m sorry, you are doing what now? So its policy… between logical elements, but this will transform into concrete
policy how exactly? And who’s policy? What models are you using and translating?
-à
In currently implementation, the policy model is pretty much based on the ACL capability offered by most of vendor switches. But the model can be evolved as our work progress.
I can’t see how GBP could possibly leverage or adopt this, which is fine, but please don’t claim that it’s offering a service that others can consume, because I
just cannot see how that is possible
è
Hope the above explanation makes things a bit clearer ….
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.
2.) How is this different from the existing approaches to similar problems already in OpenDaylight, e.g., GBP, NIC, VTN, OVSDB network virtualization
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.
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
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.
_______________________________________________ TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
Hi Colin,
The answer is “Yes”.
Regarding SFC, I just want to clarify a bit that policy is really overloaded word. Fabric itself might only support limited policy support based on its capability.
For example, in our current implementation, it may just leverage “ACL” functionality within the devices that consist of the fabric. For more broader policy support , FaaS should and will coordinate with ODL SFC project.
Thanks
Xingjun
toggle quoted message
Show quoted text
From: Colin Dixon [mailto:colin@...]
Sent: Thursday, July 23, 2015 10:49 PM
To: Xingjun Chu
Cc: alagalah; tsc@...; project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
Having read through this. It sounds like there is still spirited debate around how this will eventually fit into the broader OpenDaylight ecosystem, e.g., what other projects will use it and why, as well as some technical concerns about the approach. That being
said, short of the community and TSC voicing these opinions and having the publicly noted, I don't think they actually stand in the way of the project being approved.
(As a personal aside, I can say that I would have liked to see more actual incorporating of TSC and community feedback as opposed to mechanical stating that the feedback is either wrong or already taken into account in the project, but that isn't required to
get an incubation project.)
I'm not 100% sure what the intended scope is based on that. At a high-level, a "fabric" is basically any networking service and so the scope would then be incredibly broad, e.g., pretty much any network task. Later on it talks specifically about L2 and L3,
but in this e-mail chain Xingjun said it should also include QoS and Policy.
So, concretely: is the scope really "anything that might be used to provide a fabric abstraction including L2 and L3 virtual networks, QoS, and Policy including SFC"?
On Wed, Jul 22, 2015 at 10:23 AM, Xingjun Chu <Xingjun.Chu@...> wrote:
Thanks for your comments See answers inline
Regards
Xingjun
From: alagalah [mailto:alagalah@...]
Sent: Wednesday, July 22, 2015 12:15 AM
To: Xingjun Chu; Colin Dixon;
tsc@...;
project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
After reading the slides I still do not see how this solves the problem you claim it does.
It seems it is inserting yet another layer, which will suffer from velocity issues when FaaS lags underlying network element features causing anything leveraging it to lag.
---> Without FaaS, rendering from high level language such as GBP, Intent .. to physical devices appears to me very monolithic, I don’t see how it can be done. FaaS will make the
monolithic structure well layered. It is not “insert another layer”. It tries to turn the monolithic into a well defined layered structure. For example, a VXLAN Fabric object is a management object which represents VXLAN underlay topology with a optional
VXLAN control plane logic . The object provides L2 network CRUD operations as well as L3 routing capabilities between those L2 networks. You can also define policies between those networks.
It’s another layer which will obfuscate any troubleshooting and diagnostics.
àjust opposite, since Fabric is formed bottom up. It has clear definition between Fabric to a topology
of network, how each L2 network is sliced and configured, troubleshooting will be easier. When something is wrong in the service level, the fault can be tracked down to a logical element, then fabric , finally to physical devices.
I see nothing on multi tenancy support.
-à Tenant info can
be maintained on the higher level such as GBP or NIC. I don’t see needs at fabric level . Since every objects such as l2 network, l3 router that are created on the fabric has global unique id which can be associated with tenant id on the higher level. Unless
we found such use case requires tenant info at this level.
I see nothing on instrumentation support.
è
Thanks . Yes Instrumentation will be there for every logical element. The state model for each logical element is still to be defined which will come after we make the main
functions working.
Slide5: Every "bad thing" you cite as a reason for FaaS (monolithic, topdown) you are re-injecting. This seems like a monolithic shim, without any indication of the precise services
it will offer.
--à Check the wiki
page, it has more information regarding what a Fabric can do.
Slide 5: You cite “policy between logical elements” … I’m sorry, you are doing what now? So its policy… between logical elements, but this will transform into concrete policy how exactly?
And who’s policy? What models are you using and translating?
-à In currently
implementation, the policy model is pretty much based on the ACL capability offered by most of vendor switches. But the model can be evolved as our work progress.
I can’t see how GBP could possibly leverage or adopt this, which is fine, but please don’t claim that it’s offering a service that others can consume, because I just cannot see how
that is possible
è
Hope the above explanation makes things a bit clearer ….
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.
2.) How is this different from the existing approaches to similar problems already in OpenDaylight, e.g., GBP, NIC, VTN, OVSDB network virtualization
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.
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
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.
_______________________________________________ TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
That was exactly my point the review day: we can debate whether or not we need a new network abstraction or if we should go to a single low-level one like David B proposed, but so far we have approved several network abstractions (GBP, NIC, VTN, etc..) at different levels with no issues, so it does not seem fair to judge FaaS with different standard we have done with past projects.
BR/Luis
On Jul 23, 2015, at 7:38 AM, Colin Dixon < colin@...> wrote:
This is a separate topic which the TSC could entertain, but I think that holding FaaS to a much higher standard than we have other projects in the past here is likely capricious, so I'd like to factor it apart from voting on whether to move FaaS to incubation.
--Colin
|
|
|
Just as an exercise, can you give a few examples of what would be "out of scope" for FaaS?
--Colin
On Thu, Jul 23, 2015 at 1:36 PM, Xingjun Chu <Xingjun.Chu@...> wrote:
Hi Colin,
The answer is “Yes”.
Regarding SFC, I just want to clarify a bit that policy is really overloaded word. Fabric itself might only support limited policy support based on its capability.
For example, in our current implementation, it may just leverage “ACL” functionality within the devices that consist of the fabric. For more broader policy support , FaaS should and will coordinate with ODL SFC project.
Thanks
Xingjun
From: Colin Dixon [mailto:colin@...]
Sent: Thursday, July 23, 2015 10:49 PM
To: Xingjun Chu
Cc: alagalah; tsc@...; project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
Having read through this. It sounds like there is still spirited debate around how this will eventually fit into the broader OpenDaylight ecosystem, e.g., what other projects will use it and why, as well as some technical concerns about the approach. That being
said, short of the community and TSC voicing these opinions and having the publicly noted, I don't think they actually stand in the way of the project being approved.
(As a personal aside, I can say that I would have liked to see more actual incorporating of TSC and community feedback as opposed to mechanical stating that the feedback is either wrong or already taken into account in the project, but that isn't required to
get an incubation project.)
I'm not 100% sure what the intended scope is based on that. At a high-level, a "fabric" is basically any networking service and so the scope would then be incredibly broad, e.g., pretty much any network task. Later on it talks specifically about L2 and L3,
but in this e-mail chain Xingjun said it should also include QoS and Policy.
So, concretely: is the scope really "anything that might be used to provide a fabric abstraction including L2 and L3 virtual networks, QoS, and Policy including SFC"?
On Wed, Jul 22, 2015 at 10:23 AM, Xingjun Chu <Xingjun.Chu@...> wrote:
Thanks for your comments See answers inline
Regards
Xingjun
From: alagalah [mailto:alagalah@...]
Sent: Wednesday, July 22, 2015 12:15 AM
To: Xingjun Chu; Colin Dixon;
tsc@...;
project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
After reading the slides I still do not see how this solves the problem you claim it does.
It seems it is inserting yet another layer, which will suffer from velocity issues when FaaS lags underlying network element features causing anything leveraging it to lag.
---> Without FaaS, rendering from high level language such as GBP, Intent .. to physical devices appears to me very monolithic, I don’t see how it can be done. FaaS will make the
monolithic structure well layered. It is not “insert another layer”. It tries to turn the monolithic into a well defined layered structure. For example, a VXLAN Fabric object is a management object which represents VXLAN underlay topology with a optional
VXLAN control plane logic . The object provides L2 network CRUD operations as well as L3 routing capabilities between those L2 networks. You can also define policies between those networks.
It’s another layer which will obfuscate any troubleshooting and diagnostics.
àjust opposite, since Fabric is formed bottom up. It has clear definition between Fabric to a topology
of network, how each L2 network is sliced and configured, troubleshooting will be easier. When something is wrong in the service level, the fault can be tracked down to a logical element, then fabric , finally to physical devices.
I see nothing on multi tenancy support.
-à Tenant info can
be maintained on the higher level such as GBP or NIC. I don’t see needs at fabric level . Since every objects such as l2 network, l3 router that are created on the fabric has global unique id which can be associated with tenant id on the higher level. Unless
we found such use case requires tenant info at this level.
I see nothing on instrumentation support.
è
Thanks . Yes Instrumentation will be there for every logical element. The state model for each logical element is still to be defined which will come after we make the main
functions working.
Slide5: Every "bad thing" you cite as a reason for FaaS (monolithic, topdown) you are re-injecting. This seems like a monolithic shim, without any indication of the precise services
it will offer.
--à Check the wiki
page, it has more information regarding what a Fabric can do.
Slide 5: You cite “policy between logical elements” … I’m sorry, you are doing what now? So its policy… between logical elements, but this will transform into concrete policy how exactly?
And who’s policy? What models are you using and translating?
-à In currently
implementation, the policy model is pretty much based on the ACL capability offered by most of vendor switches. But the model can be evolved as our work progress.
I can’t see how GBP could possibly leverage or adopt this, which is fine, but please don’t claim that it’s offering a service that others can consume, because I just cannot see how
that is possible
è
Hope the above explanation makes things a bit clearer ….
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.
2.) How is this different from the existing approaches to similar problems already in OpenDaylight, e.g., GBP, NIC, VTN, OVSDB network virtualization
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.
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
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.
_______________________________________________ TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
Hi Colin,
-
FaaS does not manage appliances such as Firewall. Load balancer etc …
-
FaaS does not provide SFC
-
FaaS does not manage topology or topology discovery , it relies on topology manager of ODL
-
FaaS does not manage inventory, it relies on inventory manager of ODL
-
FaaS relies on existing connectors of ODL such as OVSDB, of, netconf
-Xingjun
toggle quoted message
Show quoted text
From: Colin Dixon [mailto:colin@...]
Sent: Friday, July 24, 2015 12:58 PM
To: Xingjun Chu
Cc: alagalah; tsc@...; project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
Just as an exercise, can you give a few examples of what would be "out of scope" for FaaS?
--Colin
On Thu, Jul 23, 2015 at 1:36 PM, Xingjun Chu <Xingjun.Chu@...> wrote:
Hi Colin,
The answer is “Yes”.
Regarding SFC, I just want to clarify a bit that policy is really overloaded word. Fabric itself
might only support limited policy support based on its capability. For example, in our current implementation, it may just leverage “ACL” functionality within the devices that consist of the fabric. For more broader policy support , FaaS should and will coordinate
with ODL SFC project.
Thanks
Xingjun
From: Colin Dixon [mailto:colin@...]
Sent: Thursday, July 23, 2015 10:49 PM
To: Xingjun Chu
Cc: alagalah;
tsc@...;
project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
Having read through this. It sounds like there is still spirited debate around how this will eventually fit into the broader OpenDaylight ecosystem, e.g., what other projects will use it and why, as well as some technical concerns about the approach. That being
said, short of the community and TSC voicing these opinions and having the publicly noted, I don't think they actually stand in the way of the project being approved.
(As a personal aside, I can say that I would have liked to see more actual incorporating of TSC and community feedback as opposed to mechanical stating that the feedback is either wrong or already taken into account in the project, but that isn't required to
get an incubation project.)
I'm not 100% sure what the intended scope is based on that. At a high-level, a "fabric" is basically any networking service and so the scope would then be incredibly broad, e.g., pretty much any network task. Later on it talks specifically about L2 and L3,
but in this e-mail chain Xingjun said it should also include QoS and Policy.
So, concretely: is the scope really "anything that might be used to provide a fabric abstraction including L2 and L3 virtual networks, QoS, and Policy including SFC"?
On Wed, Jul 22, 2015 at 10:23 AM, Xingjun Chu <Xingjun.Chu@...> wrote:
Thanks for your comments See answers inline
Regards
Xingjun
From: alagalah [mailto:alagalah@...]
Sent: Wednesday, July 22, 2015 12:15 AM
To: Xingjun Chu; Colin Dixon;
tsc@...;
project-proposals@...
Subject: Re: [OpenDaylight TSC] [Project-proposals] Fabric as a Service creation review
After reading the slides I still do not see how this solves the problem you claim it does.
It seems it is inserting yet another layer, which will suffer from velocity issues when FaaS lags underlying network element features causing anything leveraging it to lag.
---> Without FaaS, rendering from high level language such as GBP, Intent .. to physical devices appears to me very monolithic, I don’t see how it can be done. FaaS will make the
monolithic structure well layered. It is not “insert another layer”. It tries to turn the monolithic into a well defined layered structure. For example, a VXLAN Fabric object is a management object which represents VXLAN underlay topology with a optional
VXLAN control plane logic . The object provides L2 network CRUD operations as well as L3 routing capabilities between those L2 networks. You can also define policies between those networks.
It’s another layer which will obfuscate any troubleshooting and diagnostics.
àjust opposite, since Fabric is formed bottom up. It has clear definition between Fabric to a topology
of network, how each L2 network is sliced and configured, troubleshooting will be easier. When something is wrong in the service level, the fault can be tracked down to a logical element, then fabric , finally to physical devices.
I see nothing on multi tenancy support.
-à Tenant info can
be maintained on the higher level such as GBP or NIC. I don’t see needs at fabric level . Since every objects such as l2 network, l3 router that are created on the fabric has global unique id which can be associated with tenant id on the higher level. Unless
we found such use case requires tenant info at this level.
I see nothing on instrumentation support.
è
Thanks . Yes Instrumentation will be there for every logical element. The state model for each logical element is still to be defined which will come after we make the main
functions working.
Slide5: Every "bad thing" you cite as a reason for FaaS (monolithic, topdown) you are re-injecting. This seems like a monolithic shim, without any indication of the precise services
it will offer.
--à Check the wiki
page, it has more information regarding what a Fabric can do.
Slide 5: You cite “policy between logical elements” … I’m sorry, you are doing what now? So its policy… between logical elements, but this will transform into concrete policy how exactly?
And who’s policy? What models are you using and translating?
-à In currently
implementation, the policy model is pretty much based on the ACL capability offered by most of vendor switches. But the model can be evolved as our work progress.
I can’t see how GBP could possibly leverage or adopt this, which is fine, but please don’t claim that it’s offering a service that others can consume, because I just cannot see how
that is possible
è
Hope the above explanation makes things a bit clearer ….
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.
2.) How is this different from the existing approaches to similar problems already in OpenDaylight, e.g., GBP, NIC, VTN, OVSDB network virtualization
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.
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
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.
_______________________________________________ TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
