Project Proposal for review - Fabric As A service


xingjun chu
 

Hi David,

 

Thanks for your argument anyways...  See answers inline

 

Thanks

Xingjun

 

From: Bainbridge, David [mailto:dbainbri@...]
Sent: Tuesday, June 30, 2015 2:15 PM
To: Xingjun Chu; Colin Dixon
Cc: project-proposals@...
Subject: Re: [Project-proposals] Project Proposal for review - Fabric As A service

 

Xingjun,

 

Thank you for your comments.

 

The plan for GBP is for client to express a desired state as a set of policies and have GBP render that policy to the network and maintain that state in the network as changes to the network occur. GBP can do that by manipulating flows on the switches, as well as potentially other mechanisms. 

 

Does FaaS plan to monitor the changes in the network and as changes occur update the flows on the switches to maintain a network state as it was established to FaaS?

 

Xingjun ->There are no conflicts, FaaS maintains the objects it manages such logical switches, gateways , logical routers as well as tunnels  while GBP manages more high level constructs’ state

 

If so, then we have to projects that are attempting to accomplish the same goal and I would argue that this is a place that we need to look at consolidation.

 

 

If instead, FaaS, is more of a push provisioning API, I.e. you call the API it updates flows but does not attempting to maintain the fabric as established via the API then I would argue that FaaS is simply a provisioning API and you could build a renderer from GBP to FaaS, but FaaS is really then just another API to OF and it might make sense to include the FaaS concepts in GBP. 

Xingjun->FaaS leverages existing southbound plugins such as OVSDB/CLI/Openflow/netconf to provisioning push.

 

I will continue to argue that ODL needs a core abstraction used to maintain a desired network state that every other project leverages and depends on. It becomes a core part of the system and only through that abstraction are changes to the network made. Further, this abstraction should be designed around a control loop that allows ODL to maintain the desired state as changes occur in the network.

 

Xingjun-> the core abstraction may not be one layer, could be two layers which complement each other.  GBP top down from application, FaaS bottom up from network.

 

This core abstraction does not have to be GBP, but I would rather the community start with a project that exists as opposed to start another project with the same goal.

 

The argument can be made that GBP should be a common layer under FaaS/NIC/DEMO or any other application centric API just as the same argument can be made for FaaS. This is really part of my point. The community needs to pick one and move as opposed to keep creating new abstraction layers that other projects could leverage, but in practice none (or few) do.

Xingjun->not community picks who wins, it is the users who picks. J

 

From: Xingjun Chu <Xingjun.Chu@...>
Date: Tuesday, June 30, 2015 at 10:59 AM
To: David Bainbridge <dbainbri@...>, Colin Dixon <colin@...>
Cc: "project-proposals@..." <project-proposals@...>
Subject: RE: [Project-proposals] Project Proposal for review - Fabric As A service

 

 

David,

 

-          We are  involved with GBP development (we have two members contributing code to GBP as we speak)  and we even have a GBP render implemented based FaaS and would like to contribute back to ODL community.

-          FaaS and GBP are at different abstraction level and Faas is NOT intend to replace GBP, they are not conflicting each other. On the contrary, they complements each other as far as I can see.

As Colin pointed, GBP is top down and  FaaS is bottom up . With those two, GBP and others can be much more easier rendered .

-          GBP has  potential we all agree. But in reality users have the final say who is the right language and they may want to have alternatives.

-          FaaS can be a common layer underneath GBP/NIC/NEMO or any application centric API

-          There are use cases FaaS could be used directly outside of ODL.

 

Regards

Xingjun


David Bainbridge
 

Xingjun,

Thank you for your comments.

The plan for GBP is for client to express a desired state as a set of policies and have GBP render that policy to the network and maintain that state in the network as changes to the network occur. GBP can do that by manipulating flows on the switches, as well as potentially other mechanisms. 

Does FaaS plan to monitor the changes in the network and as changes occur update the flows on the switches to maintain a network state as it was established to FaaS?

If so, then we have to projects that are attempting to accomplish the same goal and I would argue that this is a place that we need to look at consolidation.

If instead, FaaS, is more of a push provisioning API, I.e. you call the API it updates flows but does not attempting to maintain the fabric as established via the API then I would argue that FaaS is simply a provisioning API and you could build a renderer from GBP to FaaS, but FaaS is really then just another API to OF and it might make sense to include the FaaS concepts in GBP. 

I will continue to argue that ODL needs a core abstraction used to maintain a desired network state that every other project leverages and depends on. It becomes a core part of the system and only through that abstraction are changes to the network made. Further, this abstraction should be designed around a control loop that allows ODL to maintain the desired state as changes occur in the network.

This core abstraction does not have to be GBP, but I would rather the community start with a project that exists as opposed to start another project with the same goal.

The argument can be made that GBP should be a common layer under FaaS/NIC/DEMO or any other application centric API just as the same argument can be made for FaaS. This is really part of my point. The community needs to pick one and move as opposed to keep creating new abstraction layers that other projects could leverage, but in practice none (or few) do.

From: Xingjun Chu <Xingjun.Chu@...>
Date: Tuesday, June 30, 2015 at 10:59 AM
To: David Bainbridge <dbainbri@...>, Colin Dixon <colin@...>
Cc: "project-proposals@..." <project-proposals@...>
Subject: RE: [Project-proposals] Project Proposal for review - Fabric As A service

 

David,

 

-          We are  involved with GBP development (we have two members contributing code to GBP as we speak)  and we even have a GBP render implemented based FaaS and would like to contribute back to ODL community.

-          FaaS and GBP are at different abstraction level and Faas is NOT intend to replace GBP, they are not conflicting each other. On the contrary, they complements each other as far as I can see.

As Colin pointed, GBP is top down and  FaaS is bottom up . With those two, GBP and others can be much more easier rendered .

-          GBP has  potential we all agree. But in reality users have the final say who is the right language and they may want to have alternatives.

-          FaaS can be a common layer underneath GBP/NIC/NEMO or any application centric API

-          There are use cases FaaS could be used directly outside of ODL.

 

Regards

Xingjun

 

 

From: Bainbridge, David [mailto:dbainbri@...]
Sent: Tuesday, June 30, 2015 12:28 PM
To: Xingjun Chu; Colin Dixon
Cc: project-proposals@...
Subject: Re: [Project-proposals] Project Proposal for review - Fabric As A service

 

Inline …

 

I like having the discussion on the wiki somewhere it's easier to find, but I also want to just give a really fast summary here so people know whether they should go look there.

In essence, David Bainbridge is saying that there is already a proliferation of "universal" abstractions for programming the network including:

* NIC

* GBP

* NEMO

 

In my personal view, I am seeing NIC and NEMO as DSLs that compile down to GBP, where GBP would be the core/common language of the controller processing engine.

Xingjun -> this is interesting. If GBP is the right abstraction why we put another layer on top of it, not mention if this is right implementation given those layers are intent to be at the same abstraction level ??

 

<dbainbri>

Northbound abstractions will always be created on top of a base. The northbound abstractions typically simplify the lower abstraction to more easily address a set of use cases. The analogy I have been using is that when programming a computer you can code in machine language or use a higher level language such as C/Java/Python that essentially compiles down to machine language when run. In this analogy GBP would be the machine language and things like NIC, NEMO, etc. would be a high level language. 

 

Presumably, the higher level languages provide a higher level abstraction that makes a larger population of users / developers more productive, but everything still executes at the machine language layer.

</dbainbri>

 

Likely also to some extent:

* VTN

* OVSDB netvirt

 

If GBP is to be the core/common language of the controller, then everything would have to resolve to a policy as opposed to directly manipulate OF for example. Thus things like VTN would be a DSL.

 

He'd like to see us converge on some of these rather than diverge seemingly with a preference for converging on GBP.

 

I would like us to converge on one, as I think the controller needs to become a control loop system always attempting to achieve a desired network state in the context of continuous change from the network and from further requests. To accomplish this I believe that a single core / common language is required and GBP is designed to support the control loop paradigm and is the most mature in ODL at this point.

Xingjun->I’d like to see that happen too. But ODL is not a standard body and GBP is not a standard either only users have the say.

 

<dbainbri>

Agreed ODL is not a standard body and GBP is not standard. The question I would pose back is can you accomplish the goal you are attempting to accomplish with FaaS by

  1. understanding if GBP can be used to implement you requirements
  2. If not, understand and contribute back to GBP modifications that allow it to meet your requirements
  3. Build FaaS as an abstraction (high level language) on top of GBP

The more projects added to ODL the more its direction is diluted and the more confused users of ODL might become. ODL is in real danger of becoming an experimental playground as opposed to the base of something that can be deployed in real customer networks. With projects that contradict and compete as opposed to a unified platform. What do we want ODL to become?

</dbainbri>

 

 

Xingjun's response is basically two-fold:

1.) The FaaS approach is bottom-up instead of top-down.

2.) Not everyone uses GBP.

 

To the second point, even if FaaS were implemented at this point not every one would use FaaS. The point being that the ODL project needs to converge on a core language that supports the control loop and I think it might be a better approach to start with a language that already exists and is a project and modify it to fits people’s needs as opposed to start a new project from scratch.

 

Xingjun-> There got be some reason behind why NOT everyone users GBP. Either it is not a right abstraction or it cannot cover all the use cases of all levels’ needs . From Network perspective, at one hand, FaaS provides high level abstraction bottom up and at the same time maintains network primitives which is much easier for users to migrate from the traditional way to use network or define network needs. Plus FaaS is not NIC or NEMO and is not at the same level abstraction as GBP and GBP could be well positioned on top of FaaS without any unnecessary overlapping efforts/abstraction.

 

<dbainbri>

I am not suggesting that GBP is perfect as is, but I am suggesting that instead of starting a new project that is meant to accomplish a similar goal that first we look to see if GBP actually has a short coming and can’t meet the needs and if so is it possible to modify GBP to meet the needs. I am also not suggesting that everything use GBP directly. It is perfectly reasonable to have abstractions on top of GBP, just like there are a multitude of higher level programming languages, but to have a cohesive control loop based controller, as opposed to a bunch of disjoint provisioning systems, ODL needs a core abstraction to which everything compiles.

 

As to why don’t more people use GBP, I think there are several reasons including:

  1. it didn’t exist when ODL started and it costs projects to change to use it and they have other priorities
  2. ODL has no clear cross-project direction in this area because ODL keeps arguing the 1000 flowers argument and this leads to more projects not a cohesive product direction
  3. People like developing projects in which they have a larger amount of control, and that leads to a behavior of new projects as opposed to working on existing projects
  4. Company politics
  5. Lack of understanding into which projects already exists and what they do
  6. It is easier to start a new project than contribute to an existing project
  7. Lack of the TSC ability (by design) to set a direction in this area.
  8. And likely more reaons

Put another way, if this project gets approved, and ODL history says it will be, what makes you think that all projects will start using it as the core technology? What ever your reason, I suspect that is the same or similar reason that GBP thought as well. So likely did any other project that started down this path.

 

I know this sounds like a harsh criticism and it likely feels like I am attempting to derail something in which you have put great thought and effort and at some level that is true. It is true, not because I think what you are proposing is a bad idea, but because unless ODL starts working towards a common abstraction it is, imo, in real danger of dying of its own weight as the community expends a huge amount of effort building more and more competitive core abstractions while other open source controllers spend more and more time building network control capability.

 

Has the FaaS project team looked at GBP and evaluated if the goals can be met by either using GBP as is or contributing to change it? If not, I would kindly request that this be done before continuing with this project. If after evaluating GBP you still feel that the goals of FaaS cannot be met by either using / modifying GBP or building FaaS as an abstraction (higher level language) on top of GBP, then I would humbly suggest that the TSC moderate a discussion as to understand why GBP can’t meet the need and recommend changes such that GBP can evolve into the core abstraction as it accepts contributions from the community.

</dbainbri>

 

Avèk respè,

/david

 

 

Avèk respè,

/david

 

 

--Colin

 

On Mon, Jun 29, 2015 at 4:16 PM, Xingjun Chu <Xingjun.Chu@...> wrote:

Thanks for your comments.  see my response https://wiki.opendaylight.org/view/Project_Proposals_talk:FaaS

 

From: Bainbridge, David [mailto:dbainbri@...]
Sent: Monday, June 29, 2015 3:52 PM
To: Xingjun Chu; project-proposals@...
Subject: Re: [Project-proposals] Project Proposal for review - Fabric As A service

 

 

 

From: <project-proposals-bounces@...> on behalf of Xingjun Chu <Xingjun.Chu@...>
Date: Monday, June 29, 2015 at 12:41 PM
To: "project-proposals@..." <project-proposals@...>
Subject: [Project-proposals] Project Proposal for review - Fabric As A service

 

Hi,

 

I have just posted a project proposal for project creation review.

 

Here is the link

 

https://wiki.opendaylight.org/view/Project_Proposals:FaaS

 

Thanks

 

Xingjun Chu

IP solutions

Huawei Technologies Canada Co. ltd

303 Terry Fox Drive, Suite 400

Kanata, Ontario Canada K2K 3J1

T:613-595-1900-1618

F: 613-595-1901


_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


xingjun chu
 

David,

 

-          We are  involved with GBP development (we have two members contributing code to GBP as we speak)  and we even have a GBP render implemented based FaaS and would like to contribute back to ODL community.

-          FaaS and GBP are at different abstraction level and Faas is NOT intend to replace GBP, they are not conflicting each other. On the contrary, they complements each other as far as I can see.

As Colin pointed, GBP is top down and  FaaS is bottom up . With those two, GBP and others can be much more easier rendered .

-          GBP has  potential we all agree. But in reality users have the final say who is the right language and they may want to have alternatives.

-          FaaS can be a common layer underneath GBP/NIC/NEMO or any application centric API

-          There are use cases FaaS could be used directly outside of ODL.

 

Regards

Xingjun

 

 


David Bainbridge
 

Inline …

I like having the discussion on the wiki somewhere it's easier to find, but I also want to just give a really fast summary here so people know whether they should go look there.

In essence, David Bainbridge is saying that there is already a proliferation of "universal" abstractions for programming the network including:

* NIC

* GBP

* NEMO

 

In my personal view, I am seeing NIC and NEMO as DSLs that compile down to GBP, where GBP would be the core/common language of the controller processing engine.

Xingjun -> this is interesting. If GBP is the right abstraction why we put another layer on top of it, not mention if this is right implementation given those layers are intent to be at the same abstraction level ??


<dbainbri>
Northbound abstractions will always be created on top of a base. The northbound abstractions typically simplify the lower abstraction to more easily address a set of use cases. The analogy I have been using is that when programming a computer you can code in machine language or use a higher level language such as C/Java/Python that essentially compiles down to machine language when run. In this analogy GBP would be the machine language and things like NIC, NEMO, etc. would be a high level language. 

Presumably, the higher level languages provide a higher level abstraction that makes a larger population of users / developers more productive, but everything still executes at the machine language layer.
</dbainbri>


Likely also to some extent:

* VTN

* OVSDB netvirt

 

If GBP is to be the core/common language of the controller, then everything would have to resolve to a policy as opposed to directly manipulate OF for example. Thus things like VTN would be a DSL.

 

He'd like to see us converge on some of these rather than diverge seemingly with a preference for converging on GBP.

 

I would like us to converge on one, as I think the controller needs to become a control loop system always attempting to achieve a desired network state in the context of continuous change from the network and from further requests. To accomplish this I believe that a single core / common language is required and GBP is designed to support the control loop paradigm and is the most mature in ODL at this point.

Xingjun->I’d like to see that happen too. But ODL is not a standard body and GBP is not a standard either only users have the say.


<dbainbri>
Agreed ODL is not a standard body and GBP is not standard. The question I would pose back is can you accomplish the goal you are attempting to accomplish with FaaS by
  1. understanding if GBP can be used to implement you requirements
  2. If not, understand and contribute back to GBP modifications that allow it to meet your requirements
  3. Build FaaS as an abstraction (high level language) on top of GBP
The more projects added to ODL the more its direction is diluted and the more confused users of ODL might become. ODL is in real danger of becoming an experimental playground as opposed to the base of something that can be deployed in real customer networks. With projects that contradict and compete as opposed to a unified platform. What do we want ODL to become?
</dbainbri>

 

Xingjun's response is basically two-fold:

1.) The FaaS approach is bottom-up instead of top-down.

2.) Not everyone uses GBP.

 

To the second point, even if FaaS were implemented at this point not every one would use FaaS. The point being that the ODL project needs to converge on a core language that supports the control loop and I think it might be a better approach to start with a language that already exists and is a project and modify it to fits people’s needs as opposed to start a new project from scratch.

 

Xingjun-> There got be some reason behind why NOT everyone users GBP. Either it is not a right abstraction or it cannot cover all the use cases of all levels’ needs . From Network perspective, at one hand, FaaS provides high level abstraction bottom up and at the same time maintains network primitives which is much easier for users to migrate from the traditional way to use network or define network needs. Plus FaaS is not NIC or NEMO and is not at the same level abstraction as GBP and GBP could be well positioned on top of FaaS without any unnecessary overlapping efforts/abstraction.


<dbainbri>
I am not suggesting that GBP is perfect as is, but I am suggesting that instead of starting a new project that is meant to accomplish a similar goal that first we look to see if GBP actually has a short coming and can’t meet the needs and if so is it possible to modify GBP to meet the needs. I am also not suggesting that everything use GBP directly. It is perfectly reasonable to have abstractions on top of GBP, just like there are a multitude of higher level programming languages, but to have a cohesive control loop based controller, as opposed to a bunch of disjoint provisioning systems, ODL needs a core abstraction to which everything compiles.

As to why don’t more people use GBP, I think there are several reasons including:
  1. it didn’t exist when ODL started and it costs projects to change to use it and they have other priorities
  2. ODL has no clear cross-project direction in this area because ODL keeps arguing the 1000 flowers argument and this leads to more projects not a cohesive product direction
  3. People like developing projects in which they have a larger amount of control, and that leads to a behavior of new projects as opposed to working on existing projects
  4. Company politics
  5. Lack of understanding into which projects already exists and what they do
  6. It is easier to start a new project than contribute to an existing project
  7. Lack of the TSC ability (by design) to set a direction in this area.
  8. And likely more reaons
Put another way, if this project gets approved, and ODL history says it will be, what makes you think that all projects will start using it as the core technology? What ever your reason, I suspect that is the same or similar reason that GBP thought as well. So likely did any other project that started down this path.

I know this sounds like a harsh criticism and it likely feels like I am attempting to derail something in which you have put great thought and effort and at some level that is true. It is true, not because I think what you are proposing is a bad idea, but because unless ODL starts working towards a common abstraction it is, imo, in real danger of dying of its own weight as the community expends a huge amount of effort building more and more competitive core abstractions while other open source controllers spend more and more time building network control capability.

Has the FaaS project team looked at GBP and evaluated if the goals can be met by either using GBP as is or contributing to change it? If not, I would kindly request that this be done before continuing with this project. If after evaluating GBP you still feel that the goals of FaaS cannot be met by either using / modifying GBP or building FaaS as an abstraction (higher level language) on top of GBP, then I would humbly suggest that the TSC moderate a discussion as to understand why GBP can’t meet the need and recommend changes such that GBP can evolve into the core abstraction as it accepts contributions from the community.
</dbainbri>

Avèk respè,
/david

 

Avèk respè,

/david

 

 

--Colin

 

On Mon, Jun 29, 2015 at 4:16 PM, Xingjun Chu <Xingjun.Chu@...> wrote:

Thanks for your comments.  see my response https://wiki.opendaylight.org/view/Project_Proposals_talk:FaaS

 

From: Bainbridge, David [mailto:dbainbri@...]
Sent: Monday, June 29, 2015 3:52 PM
To: Xingjun Chu; project-proposals@...
Subject: Re: [Project-proposals] Project Proposal for review - Fabric As A service

 

 

 

From: <project-proposals-bounces@...> on behalf of Xingjun Chu <Xingjun.Chu@...>
Date: Monday, June 29, 2015 at 12:41 PM
To: "project-proposals@..." <project-proposals@...>
Subject: [Project-proposals] Project Proposal for review - Fabric As A service

 

Hi,

 

I have just posted a project proposal for project creation review.

 

Here is the link

 

https://wiki.opendaylight.org/view/Project_Proposals:FaaS

 

Thanks

 

Xingjun Chu

IP solutions

Huawei Technologies Canada Co. ltd

303 Terry Fox Drive, Suite 400

Kanata, Ontario Canada K2K 3J1

T:613-595-1900-1618

F: 613-595-1901


_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


xingjun chu
 

Thanks Colin. 

 

David, please see my defense inline ...

 

Regards

Xingjun

 

From: Bainbridge, David [mailto:dbainbri@...]
Sent: Tuesday, June 30, 2015 11:26 AM
To: Colin Dixon; Xingjun Chu
Cc: project-proposals@...
Subject: Re: [Project-proposals] Project Proposal for review - Fabric As A service

 

Colin,

 

Thank for the summary. A few comment in line …

 

Avèk respè,

/david

 

 

I like having the discussion on the wiki somewhere it's easier to find, but I also want to just give a really fast summary here so people know whether they should go look there.

In essence, David Bainbridge is saying that there is already a proliferation of "universal" abstractions for programming the network including:

* NIC

* GBP

* NEMO

 

In my personal view, I am seeing NIC and NEMO as DSLs that compile down to GBP, where GBP would be the core/common language of the controller processing engine.

Xingjun -> this is interesting. If GBP is the right abstraction why we put another layer on top of it, not mention if this is right implementation given those layers are intent to be at the same abstraction level ??

 

Likely also to some extent:

* VTN

* OVSDB netvirt

 

If GBP is to be the core/common language of the controller, then everything would have to resolve to a policy as opposed to directly manipulate OF for example. Thus things like VTN would be a DSL.

 

He'd like to see us converge on some of these rather than diverge seemingly with a preference for converging on GBP.

 

I would like us to converge on one, as I think the controller needs to become a control loop system always attempting to achieve a desired network state in the context of continuous change from the network and from further requests. To accomplish this I believe that a single core / common language is required and GBP is designed to support the control loop paradigm and is the most mature in ODL at this point.

Xingjun->I’d like to see that happen too. But ODL is not a standard body and GBP is not a standard either only users have the say.

 

Xingjun's response is basically two-fold:

1.) The FaaS approach is bottom-up instead of top-down.

2.) Not everyone uses GBP.

 

To the second point, even if FaaS were implemented at this point not every one would use FaaS. The point being that the ODL project needs to converge on a core language that supports the control loop and I think it might be a better approach to start with a language that already exists and is a project and modify it to fits people’s needs as opposed to start a new project from scratch.

 

Xingjun-> There got be some reason behind why NOT everyone users GBP. Either it is not a right abstraction or it cannot cover all the use cases of all levels’ needs . From Network perspective, at one hand, FaaS provides high level abstraction bottom up and at the same time maintains network primitives which is much easier for users to migrate from the traditional way to use network or define network needs. Plus FaaS is not NIC or NEMO and is not at the same level abstraction as GBP and GBP could be well positioned on top of FaaS without any unnecessary overlapping efforts/abstraction.

 

Avèk respè,

/david

 

 

--Colin

 

On Mon, Jun 29, 2015 at 4:16 PM, Xingjun Chu <Xingjun.Chu@...> wrote:

Thanks for your comments.  see my response https://wiki.opendaylight.org/view/Project_Proposals_talk:FaaS

 

From: Bainbridge, David [mailto:dbainbri@...]
Sent: Monday, June 29, 2015 3:52 PM
To: Xingjun Chu; project-proposals@...
Subject: Re: [Project-proposals] Project Proposal for review - Fabric As A service

 

 

 

From: <project-proposals-bounces@...> on behalf of Xingjun Chu <Xingjun.Chu@...>
Date: Monday, June 29, 2015 at 12:41 PM
To: "project-proposals@..." <project-proposals@...>
Subject: [Project-proposals] Project Proposal for review - Fabric As A service

 

Hi,

 

I have just posted a project proposal for project creation review.

 

Here is the link

 

https://wiki.opendaylight.org/view/Project_Proposals:FaaS

 

Thanks

 

Xingjun Chu

IP solutions

Huawei Technologies Canada Co. ltd

303 Terry Fox Drive, Suite 400

Kanata, Ontario Canada K2K 3J1

T:613-595-1900-1618

F: 613-595-1901


_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


David Bainbridge
 

Colin,

Thank for the summary. A few comment in line …

Avèk respè,
/david


I like having the discussion on the wiki somewhere it's easier to find, but I also want to just give a really fast summary here so people know whether they should go look there.

In essence, David Bainbridge is saying that there is already a proliferation of "universal" abstractions for programming the network including:
* NIC
* GBP
* NEMO

In my personal view, I am seeing NIC and NEMO as DSLs that compile down to GBP, where GBP would be the core/common language of the controller processing engine.

Likely also to some extent:
* VTN
* OVSDB netvirt

If GBP is to be the core/common language of the controller, then everything would have to resolve to a policy as opposed to directly manipulate OF for example. Thus things like VTN would be a DSL.

He'd like to see us converge on some of these rather than diverge seemingly with a preference for converging on GBP.

I would like us to converge on one, as I think the controller needs to become a control loop system always attempting to achieve a desired network state in the context of continuous change from the network and from further requests. To accomplish this I believe that a single core / common language is required and GBP is designed to support the control loop paradigm and is the most mature in ODL at this point.

Xingjun's response is basically two-fold:
1.) The FaaS approach is bottom-up instead of top-down.
2.) Not everyone uses GBP.

To the second point, even if FaaS were implemented at this point not every one would use FaaS. The point being that the ODL project needs to converge on a core language that supports the control loop and I think it might be a better approach to start with a language that already exists and is a project and modify it to fits people’s needs as opposed to start a new project from scratch.

Avèk respè,
/david



--Colin


On Mon, Jun 29, 2015 at 4:16 PM, Xingjun Chu <Xingjun.Chu@...> wrote:

Thanks for your comments.  see my response https://wiki.opendaylight.org/view/Project_Proposals_talk:FaaS

 

From: Bainbridge, David [mailto:dbainbri@...]
Sent: Monday, June 29, 2015 3:52 PM
To: Xingjun Chu; project-proposals@...
Subject: Re: [Project-proposals] Project Proposal for review - Fabric As A service

 

 

 

From: <project-proposals-bounces@...> on behalf of Xingjun Chu <Xingjun.Chu@...>
Date: Monday, June 29, 2015 at 12:41 PM
To: "project-proposals@..." <project-proposals@...>
Subject: [Project-proposals] Project Proposal for review - Fabric As A service

 

Hi,

 

I have just posted a project proposal for project creation review.

 

Here is the link

 

https://wiki.opendaylight.org/view/Project_Proposals:FaaS

 

Thanks

 

Xingjun Chu

IP solutions

Huawei Technologies Canada Co. ltd

303 Terry Fox Drive, Suite 400

Kanata, Ontario Canada K2K 3J1

T:613-595-1900-1618

F: 613-595-1901


_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals



Colin Dixon
 

I like having the discussion on the wiki somewhere it's easier to find, but I also want to just give a really fast summary here so people know whether they should go look there.

In essence, David Bainbridge is saying that there is already a proliferation of "universal" abstractions for programming the network including:
* NIC
* GBP
* NEMO

Likely also to some extent:
* VTN
* OVSDB netvirt

He'd like to see us converge on some of these rather than diverge seemingly with a preference for converging on GBP.

Xingjun's response is basically two-fold:
1.) The FaaS approach is bottom-up instead of top-down.
2.) Not everyone uses GBP.

--Colin


On Mon, Jun 29, 2015 at 4:16 PM, Xingjun Chu <Xingjun.Chu@...> wrote:

Thanks for your comments.  see my response https://wiki.opendaylight.org/view/Project_Proposals_talk:FaaS

 

From: Bainbridge, David [mailto:dbainbri@...]
Sent: Monday, June 29, 2015 3:52 PM
To: Xingjun Chu; project-proposals@...
Subject: Re: [Project-proposals] Project Proposal for review - Fabric As A service

 

 

 

From: <project-proposals-bounces@...> on behalf of Xingjun Chu <Xingjun.Chu@...>
Date: Monday, June 29, 2015 at 12:41 PM
To: "project-proposals@..." <project-proposals@...>
Subject: [Project-proposals] Project Proposal for review - Fabric As A service

 

Hi,

 

I have just posted a project proposal for project creation review.

 

Here is the link

 

https://wiki.opendaylight.org/view/Project_Proposals:FaaS

 

Thanks

 

Xingjun Chu

IP solutions

Huawei Technologies Canada Co. ltd

303 Terry Fox Drive, Suite 400

Kanata, Ontario Canada K2K 3J1

T:613-595-1900-1618

F: 613-595-1901


_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals



xingjun chu
 

Thanks for your comments.  see my response https://wiki.opendaylight.org/view/Project_Proposals_talk:FaaS

 

From: Bainbridge, David [mailto:dbainbri@...]
Sent: Monday, June 29, 2015 3:52 PM
To: Xingjun Chu; project-proposals@...
Subject: Re: [Project-proposals] Project Proposal for review - Fabric As A service

 

 

 

From: <project-proposals-bounces@...> on behalf of Xingjun Chu <Xingjun.Chu@...>
Date: Monday, June 29, 2015 at 12:41 PM
To: "project-proposals@..." <project-proposals@...>
Subject: [Project-proposals] Project Proposal for review - Fabric As A service

 

Hi,

 

I have just posted a project proposal for project creation review.

 

Here is the link

 

https://wiki.opendaylight.org/view/Project_Proposals:FaaS

 

Thanks

 

Xingjun Chu

IP solutions

Huawei Technologies Canada Co. ltd

303 Terry Fox Drive, Suite 400

Kanata, Ontario Canada K2K 3J1

T:613-595-1900-1618

F: 613-595-1901


David Bainbridge
 



From: <project-proposals-bounces@...> on behalf of Xingjun Chu <Xingjun.Chu@...>
Date: Monday, June 29, 2015 at 12:41 PM
To: "project-proposals@..." <project-proposals@...>
Subject: [Project-proposals] Project Proposal for review - Fabric As A service

Hi,

 

I have just posted a project proposal for project creation review.

 

Here is the link

 

https://wiki.opendaylight.org/view/Project_Proposals:FaaS

 

Thanks

 

Xingjun Chu

IP solutions

Huawei Technologies Canada Co. ltd

303 Terry Fox Drive, Suite 400

Kanata, Ontario Canada K2K 3J1

T:613-595-1900-1618

F: 613-595-1901


xingjun chu
 

Hi,

 

I have just posted a project proposal for project creation review.

 

Here is the link

 

https://wiki.opendaylight.org/view/Project_Proposals:FaaS

 

Thanks

 

Xingjun Chu

IP solutions

Huawei Technologies Canada Co. ltd

303 Terry Fox Drive, Suite 400

Kanata, Ontario Canada K2K 3J1

T:613-595-1900-1618

F: 613-595-1901