|
I realize that my tone may have come across as overly critical of the ONOS work. I think that they have a very clean, simple architecture of how their controller should work. That is vastly to their credit and we should aspire to come up with as clean a message about our architecture—or at least when it comes to state and how that state is replicated.
I just wanted to point out that there are also still issues that we (and probably they) need to resolve that their approach doesn't solve and some places where the cleanliness of their slides is slightly misleading.
--Colin
tsc-bounces@... wrote on 10/01/2013 04:25:41 PM:
> From: Colin Dixon/Austin/IBM@IBMUS
> To: Christopher Price <christopher.price@...>
> Cc: tsc-bounces@..., "tsc@..."
> <tsc@...>
> Date: 10/01/2013 04:26 PM
> Subject: Re: [OpenDaylight TSC] The Minutes from the TSC Meeting on
> September 26th have been posted to the wiki
> Sent by: tsc-bounces@...
>
> I think Chris nails the key point here:
> It's amazing how much a nice GUI, good documentation, and a crisp
> message can do for perception. This is something we should really
> look to focus on as a community, as engineers we are more likely to
> discuss things we want to fix, or publish limitations as we want to
> find the best way to overcome them. We should also look, come
> December, to promote the fantastic capabilities and values we will
> have achieved in ODL by that time in any way possible.
>
> Other points below:
>
> w.r.t. Titan:
>
> I'm not 100% sure, but I think a graph database would fall in the
> "nice, but maybe overkill" category of things.
>
> From their page: http://thinkaurelius.github.io/titan/
> "Titan is a scalable graph database optimized for storing and
> querying graphs containing hundreds of billions of vertices and
> edges distributed across a multi-machine cluster."
>
> Unless we're really thinking that we want a single topology database
> for the whole Internet, that seems like overkill. If we do, we
> should probably be having other discussions as well.
>
> w.r.t. Consistency Model
> My understanding was that they said the following:
> 1.) Zookeeper keeps the mapping of controllers to switches
> 2.) All other state is stored in cassandra with essentially no guarantees
>
> They say inconsistency will last "a short time" for (2), but what
> they actually mean from a technical perspective is "a potentially
> unboundedly long time" and they present none of the details around
> how you heal inconsistent state—which is where all of the hard parts
> are. The also don't say what happens if we have a network partition
> and need to remap the switch-controller mapping despite being on the
> minority side of the partition and thus unable to change our Zookeeper state.
>
> We certainly have a lot of things in our house to get in order—for
> instance figuring out what the actual consistency model provided by
> Infinispan actually is—but I also feel like the reason their
> solution seems clean is because it's relatively simple and doesn't
> attack some of the bigger problems directly.
>
> That's not to say that they're solution isn't good. It sounds like
> the start of a great architecture and we would probably do well to
> observe it and figure out what we want to do.
>
> --Colin
>
> tsc-bounces@... wrote on 10/01/2013 11:44:23 AM:
> > From: Christopher Price <christopher.price@...>
> > To: Ken Gray <kgray@...>, Phil Robb
> > <probb@...>, "tsc@..."
> > <tsc@...>
> > Date: 10/01/2013 11:44 AM
> > Subject: Re: [OpenDaylight TSC] The Minutes from the TSC Meeting on
> > September 26th have been posted to the wiki
> > Sent by: tsc-bounces@...
> >
> > Hi Ken,
> >
> > Re ONOS: Great comments and good to re-float some of the
> > outstanding topics we have as of yet not concluded in ODL. (at least
> > in a communicable manner)
> > I would like to start by prefacing that I believe while ONOS and ODL
> > have similarities they are not equivalent in what is being achieved
> > by the programs. I do think we should look to interop and align
> > where these similarities exist as they have a number of very good
> > ideas on how to achieve OF control and orchestration.
> >
> > It's amazing how much a nice GUI, good documentation, and a crisp
> > message can do for perception. This is something we should really
> > look to focus on as a community, as engineers we are more likely to
> > discuss things we want to fix, or publish limitations as we want to
> > find the best way to overcome them. We should also look, come
> > December, to promote the fantastic capabilities and values we will
> > have achieved in ODL by that time in any way possible.
> >
> > I also believe that the data, distribution, and persistency model
> > (any by reference technology) topic is a key area to address in ODL
> > next year. In my opinion this is a technology focus area in
> > distributed systems that makes more impact on a solution than the
> > quality of the software itself. I'm not convinced the ONOS solution
> > has the right answer yet to scale to their targets and am not sure
> > the right answer for ONOS will be the right answer for the ODL.
> > On the other hand opinions are cheap and I'm liberal with mine, I
> > really want to explore and work on this particular topic in gory
> > detail as a component of the next ODL release.
> >
> > I expect the right forums to work out these topics is in the
> > projects that address/encompass them. If they don't exist, or are
> > understaffed, we can create or join them. (As an answer that may
> > feel like a glib response, but it is our agreed MO)
> >
> > Regards,
> > Chris
> >
> > From: Ken Gray <kgray@...>
> > Date: Tuesday, October 1, 2013 8:49 AM
> > To: Phil Robb <probb@...>, "tsc@..." <
> > tsc@...>
> > Subject: Re: [OpenDaylight TSC] The Minutes from the TSC Meeting on
> > September 26th have been posted to the wiki
> >
> > Thanks, Phil. I'd like to thank Dave for arranging/suggesting for
> > the ONOS folks (Guru et al) to come in and present. I had seen
> > their presentation some time ago, and it looks even more polished
> > now. I'm left with a "where do we go from here" feeling.
> >
> > IMO, the presentation brings back out a couple of dormant topics and
> > probably casts our a few new ones for consideration as well.
> >
> > First, I was impressed with how well prepared they were to discuss
> > their consistency models and how their infrastructure supported
> > these. While they use different tooling and have a different
> > mission, they were pretty crisp on the role of Zookeeper in the
> > switch to master binding and their HA constructs (the visual
> > demonstration was pretty appealing) and overall clustering via
> > Cassandra. Can we demonstrate similar capabilities and/or be this
> > crisp when we launch?
> >
> > Second, the layer they added with Titan and how it fed their GUI was
> > very interesting – and again I wondered how ODL tooling compares (we
> > have a Topology service via a model and data structure, but Titan is
> > a graph database)?
> >
> > Finally, on the "where do we go from here" points (knowing full well
> > that we DO have a launch of our own in December and that they have a
> > separate mission - they are single protocol):
> >
> > What of their technologies would fit well with ODL (e.g. should we
> > be considering adding new infra to mimic theirs or adapting our own?
> > Are there reasons why Infinispan and the Zookeeper/Cassandra
> > paradigm aren't interchangeable? Could we use Titan in any way? ETC)?
> >
> > Because they are one of the few remaining ONGOING developments in
> > OpenFlow, can_we/should_we interoperate somehow?
> >
> > What are the ONOS/ON.Lab guys interested in collaborating on … if anything?
> >
> > So, I'm interested in what forum we work these things out ….
> >
> > From: Phil Robb <probb@...>
> > Date: Tue, 1 Oct 2013 09:43:28 -0600
> > To: "tsc@..." <tsc@...>
> > Subject: [OpenDaylight TSC] The Minutes from the TSC Meeting on
> > September 26th have been posted to the wiki
> >
> > Please review them at your convenience and let me know if there are
> > any edits needed.
> >
> > Thanks,
> >
> > Phil.
> > --
> > Phil Robb
> > Director - Networking Solutions
> > The Linux Foundation
> > (O) 970-229-5949
> > (M) 970-420-4292
> > Skype: Phil.Robb
> > _______________________________________________ TSC mailing list
> > TSC@... https://lists.opendaylight.org/mailman/
> listinfo/tsc
> > _______________________________________________
> > TSC mailing list
> > TSC@...
> > https://lists.opendaylight.org/mailman/listinfo/tsc
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
Hi Ken, my comments inline ... On 01-Oct-13 17:49, Ken Gray wrote: Thanks, Phil. I'd like to thank Dave for arranging/suggesting for the ONOS
folks (Guru et al) to come in and present. I had seen their presentation some
time ago, and it looks even more polished now. I'm left with a "where do we go
from here" feeling.
IMO, the presentation brings back out a couple of dormant topics and probably
casts our a few new ones for consideration as well.
First, I was impressed with how well prepared they were to discuss their
consistency models and how their infrastructure supported these. While they use
different tooling and have a different mission, they were pretty crisp on the
role of Zookeeper in the switch to master binding and their HA constructs (the
visual demonstration was pretty appealing) and overall clustering via Cassandra.
Can we demonstrate similar capabilities and/or be this crisp when we launch? Well i was not impressed with how they run Dijkstra on the graph distributed over Cassandra. I would argue that running Dijkstra on several topologies is a bread and butter of the controller. Now if you spread the edges on the DHT DB and later on you have to fetch from DB all in memory and you need to run Dijkstra and then spread again the result of Dijkstra seems inefficient. In ODP with Infinispan we keep all in memory already and the topology DB is a replicated cache exactly because of Dijkstra, this way on topology reroute you have it all in place. I think you can start to get benefit of using DHT only if you can run in map-reduce fashion the Dijkstra, and there are implementations googling around, but given the SPT is needed in all the controller nodes anyway i wonder if it's really that efficient to spread that calculation to later on spread the same SPT to all the nodes. So bottom line i know there are many fan of NoSQL databases around, but i fail to see how to use it efficiently in the most simple case, the network graph DB maintenance and the run of the algorithms on it. I know page-rank of Google is necessarily done in map-reduce fashion due to the size of the graph, but i don't think (and i'm ignorant here) they do the page-rank on every page change and expect that to complete. The other point didn't impress me was, given the cassandra doesn't provide notification when a key,value map change how can you actually react to this event without introducing race conditions. Let say and edge is updated and a controller need to react to that event, if you send it out-of-band you don't know if that notification will arrive the destination controller node before the cassandra update will arrive and there is no way to synchronize it because you don't know when the receiving controller will be able to see that edge. With infinispan this is easily solved because when the update arrives on the destination node than the same thread calls the ICacheUpdateAware. Second, the layer they added with Titan and how it fed their GUI was very
interesting – and again I wondered how ODL tooling compares (we have a Topology
service via a model and data structure, but Titan is a graph database)? Well Titan is a just a graph DB only built to scale on DHT but without the Faunus map-reduce again you are back to square to run an algo on it that involves all the vertex you need to create an in-memory snapshot. Finally, on the "where do we go from here" points (knowing full well that we DO
have a launch of our own in December and that they have a separate mission -
they are single protocol):
What of their technologies would fit well with ODL (e.g. should we be
considering adding new infra to mimic theirs or adapting our own? Are there
reasons why Infinispan and the Zookeeper/Cassandra paradigm aren't
interchangeable? Could we use Titan in any way? ETC)? They are indeed interchangeable, someone can think to build the clustering.services contract backed by cassandra and zookeper but the ICacheUpdateAware will not be reliable because the out-of-band synchronization issue. My 2 cents, Giovanni Because they are one of the few remaining ONGOING developments in OpenFlow,
can_we/should_we interoperate somehow?
What are the ONOS/ON.Lab guys interested in collaborating on … if anything?
So, I'm interested in what forum we work these things out ….
From: Phil Robb <probb@... <mailto:probb@...>>
Date: Tue, 1 Oct 2013 09:43:28 -0600
To: "tsc@... <mailto:tsc@...>"
<tsc@... <mailto:tsc@...>>
Subject: [OpenDaylight TSC] The Minutes from the TSC Meeting on September 26th
have been posted to the wiki
Please review them at your convenience and let me know if there are any edits
needed.
Thanks,
Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
_______________________________________________ TSC mailing list
TSC@... <mailto:TSC@...>
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
-- Giovanni Meo Via del Serafico, 200 Telephone: +390651644000 00142, Roma Mobile: +393480700958 Italia Fax: +390651645917 VOIP: 8-3964000 “The pessimist complains about the wind; the optimist expects it to change; the realist adjusts the sails.” -- Wm. Arthur Ward IETF credo: "Rough consensus and running code"
|
|
|
I think Chris nails the key point here:
It's amazing how much a nice GUI, good documentation, and a crisp message can do for perception. This is something we should really look to focus on as a community, as engineers we are more likely to discuss things we want to fix, or publish limitations as we want to find the best way to overcome them. We should also look, come December, to promote the fantastic capabilities and values we will have achieved in ODL by that time in any way possible.
Other points below:
w.r.t. Titan:
I'm not 100% sure, but I think a graph database would fall in the "nice, but maybe overkill" category of things.
From their page: http://thinkaurelius.github.io/titan/
"Titan is a scalable graph database optimized for storing and querying graphs containing hundreds of billions of vertices and edges distributed across a multi-machine cluster."
Unless we're really thinking that we want a single topology database for the whole Internet, that seems like overkill. If we do, we should probably be having other discussions as well.
w.r.t. Consistency Model
My understanding was that they said the following:
1.) Zookeeper keeps the mapping of controllers to switches
2.) All other state is stored in cassandra with essentially no guarantees
They say inconsistency will last "a short time" for (2), but what they actually mean from a technical perspective is "a potentially unboundedly long time" and they present none of the details around how you heal inconsistent state—which is where all of the hard parts are. The also don't say what happens if we have a network partition and need to remap the switch-controller mapping despite being on the minority side of the partition and thus unable to change our Zookeeper state.
We certainly have a lot of things in our house to get in order—for instance figuring out what the actual consistency model provided by Infinispan actually is—but I also feel like the reason their solution seems clean is because it's relatively simple and doesn't attack some of the bigger problems directly.
That's not to say that they're solution isn't good. It sounds like the start of a great architecture and we would probably do well to observe it and figure out what we want to do.
--Colin
tsc-bounces@... wrote on 10/01/2013 11:44:23 AM:
> From: Christopher Price <christopher.price@...>
> To: Ken Gray <kgray@...>, Phil Robb
> <probb@...>, "tsc@..."
> <tsc@...>
> Date: 10/01/2013 11:44 AM
> Subject: Re: [OpenDaylight TSC] The Minutes from the TSC Meeting on
> September 26th have been posted to the wiki
> Sent by: tsc-bounces@...
>
> Hi Ken,
>
> Re ONOS: Great comments and good to re-float some of the
> outstanding topics we have as of yet not concluded in ODL. (at least
> in a communicable manner)
> I would like to start by prefacing that I believe while ONOS and ODL
> have similarities they are not equivalent in what is being achieved
> by the programs. I do think we should look to interop and align
> where these similarities exist as they have a number of very good
> ideas on how to achieve OF control and orchestration.
>
> It's amazing how much a nice GUI, good documentation, and a crisp
> message can do for perception. This is something we should really
> look to focus on as a community, as engineers we are more likely to
> discuss things we want to fix, or publish limitations as we want to
> find the best way to overcome them. We should also look, come
> December, to promote the fantastic capabilities and values we will
> have achieved in ODL by that time in any way possible.
>
> I also believe that the data, distribution, and persistency model
> (any by reference technology) topic is a key area to address in ODL
> next year. In my opinion this is a technology focus area in
> distributed systems that makes more impact on a solution than the
> quality of the software itself. I'm not convinced the ONOS solution
> has the right answer yet to scale to their targets and am not sure
> the right answer for ONOS will be the right answer for the ODL.
> On the other hand opinions are cheap and I'm liberal with mine, I
> really want to explore and work on this particular topic in gory
> detail as a component of the next ODL release.
>
> I expect the right forums to work out these topics is in the
> projects that address/encompass them. If they don't exist, or are
> understaffed, we can create or join them. (As an answer that may
> feel like a glib response, but it is our agreed MO)
>
> Regards,
> Chris
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, October 1, 2013 8:49 AM
> To: Phil Robb <probb@...>, "tsc@..." <
> tsc@...>
> Subject: Re: [OpenDaylight TSC] The Minutes from the TSC Meeting on
> September 26th have been posted to the wiki
>
> Thanks, Phil. I'd like to thank Dave for arranging/suggesting for
> the ONOS folks (Guru et al) to come in and present. I had seen
> their presentation some time ago, and it looks even more polished
> now. I'm left with a "where do we go from here" feeling.
>
> IMO, the presentation brings back out a couple of dormant topics and
> probably casts our a few new ones for consideration as well.
>
> First, I was impressed with how well prepared they were to discuss
> their consistency models and how their infrastructure supported
> these. While they use different tooling and have a different
> mission, they were pretty crisp on the role of Zookeeper in the
> switch to master binding and their HA constructs (the visual
> demonstration was pretty appealing) and overall clustering via
> Cassandra. Can we demonstrate similar capabilities and/or be this
> crisp when we launch?
>
> Second, the layer they added with Titan and how it fed their GUI was
> very interesting – and again I wondered how ODL tooling compares (we
> have a Topology service via a model and data structure, but Titan is
> a graph database)?
>
> Finally, on the "where do we go from here" points (knowing full well
> that we DO have a launch of our own in December and that they have a
> separate mission - they are single protocol):
>
> What of their technologies would fit well with ODL (e.g. should we
> be considering adding new infra to mimic theirs or adapting our own?
> Are there reasons why Infinispan and the Zookeeper/Cassandra
> paradigm aren't interchangeable? Could we use Titan in any way? ETC)?
>
> Because they are one of the few remaining ONGOING developments in
> OpenFlow, can_we/should_we interoperate somehow?
>
> What are the ONOS/ON.Lab guys interested in collaborating on … if anything?
>
> So, I'm interested in what forum we work these things out ….
>
> From: Phil Robb <probb@...>
> Date: Tue, 1 Oct 2013 09:43:28 -0600
> To: "tsc@..." <tsc@...>
> Subject: [OpenDaylight TSC] The Minutes from the TSC Meeting on
> September 26th have been posted to the wiki
>
> Please review them at your convenience and let me know if there are
> any edits needed.
>
> Thanks,
>
> Phil.
> --
> Phil Robb
> Director - Networking Solutions
> The Linux Foundation
> (O) 970-229-5949
> (M) 970-420-4292
> Skype: Phil.Robb
> _______________________________________________ TSC mailing list
> TSC@... https://lists.opendaylight.org/mailman/listinfo/tsc
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
If they are amenable, an API review of both sides leading to a discussion
of whether we can meet in the middle (kind of a methodology introduction
and the outcomes from each, then an overlay for commonality/gaps). Then,
maybe a bit (I'm stretching here, so mind the gap) of trying to map the
evolving topology model into Titan (perhaps re-using their
repository/tools or maybe spawning a project to do so with ours).
That's just what I can pull out of my ...er, pocket.
toggle quoted message
Show quoted text
On 10/1/13 3:12 PM, "David Meyer" <dmm@...> wrote: On Tue, Oct 1, 2013 at 11:02 AM, Ken Gray <kgray@...> wrote:
My one clarification is that the ONOS guys are probably going to still
get
some "share" of OpenFlow deployment, particularly in R&E. Maybe if they
don't "integrate" some of their IP, one of the things we COULD do is
explore the E-W federation interface ...or maybe we can talk about how
our
model-driven SAL creates API, review the model and agree (at least) on a
common OpenFlow API. Though I don't want/need/desire to do the ONF's
work
FOR them, this would be a good test for the efficacy of the modeling
paradigm ...can the API we create be usable by ONOS ...and so forth. All great ideas Ken. What concrete steps would you suggest we take to
get us moving forward on these ideas?
I know .. "stop it already" ...but, still ..just thinking a bit about
what
we can do together if there is no direct integration. Nice ideas.
--dmm
On 10/1/13 1:06 PM, "David Meyer" <dmm@...> wrote:
On Tue, Oct 1, 2013 at 8:49 AM, Ken Gray <kgray@...> wrote:
Thanks, Phil. I'd like to thank Dave for arranging/suggesting for the
ONOS
folks (Guru et al) to come in and present. I had seen their
presentation
some time ago, and it looks even more polished now. I'm left with a
"where
do we go from here" feeling. Thnx/my pleasure. Thanks to Anees for doing the logistical work.
IMO, the presentation brings back out a couple of dormant topics and
probably casts our a few new ones for consideration as well.
First, I was impressed with how well prepared they were to discuss
their
consistency models and how their infrastructure supported these.
While
they
use different tooling and have a different mission, they were pretty
crisp
on the role of Zookeeper in the switch to master binding and their HA
constructs (the visual demonstration was pretty appealing) and overall
clustering via Cassandra. Can we demonstrate similar capabilities
and/or be
this crisp when we launch?
Excellent point. While we've briefly discussed consistency models
we've yet to get the kind of clear articulation we saw from the ONOS
folks. And of course consistency models are core to the scalability of
a distributed system, so this is a discussion we need to continue.
Second, the layer they added with Titan and how it fed their GUI was
very
interesting and again I wondered how ODL tooling compares (we have a
Topology service via a model and data structure, but Titan is a graph
database)?
Also a good point. Graph DBs seem very popular for this application,
and in theory make at least part of an application's job easier.
Finally, on the "where do we go from here" points (knowing full well
that we
DO have a launch of our own in December and that they have a separate
mission - they are single protocol):
What of their technologies would fit well with ODL (e.g. should we be
considering adding new infra to mimic theirs or adapting our own? Are
there
reasons why Infinispan and the Zookeeper/Cassandra paradigm aren't
interchangeable? Could we use Titan in any way? ETC)?
All good questions.
Because they are one of the few remaining ONGOING developments in
OpenFlow,
can_we/should_we interoperate somehow?
Not sure what you mean here. Can you elaborate?
What are the ONOS/ON.Lab guys interested in collaborating on Š if
anything?
The definitely want to find a way to work with us, which is how this
all started.
So, I'm interested in what forum we work these things out Š. One possibility would be do invite the ONOS folks back to the TWS call
during which we give a similar presentation describing our consistency
model, HA, MD-SAL, ... They we could start to tease this apart where
we might adapt eachother's technology(ies).
--dmm
From: Phil Robb <probb@...>
Date: Tue, 1 Oct 2013 09:43:28 -0600
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] The Minutes from the TSC Meeting on
September
26th have been posted to the wiki
Please review them at your convenience and let me know if there are
any
edits needed.
Thanks,
Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
_______________________________________________ TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
On Tue, Oct 1, 2013 at 11:02 AM, Ken Gray <kgray@...> wrote: My one clarification is that the ONOS guys are probably going to still get
some "share" of OpenFlow deployment, particularly in R&E. Maybe if they
don't "integrate" some of their IP, one of the things we COULD do is
explore the E-W federation interface ...or maybe we can talk about how our
model-driven SAL creates API, review the model and agree (at least) on a
common OpenFlow API. Though I don't want/need/desire to do the ONF's work
FOR them, this would be a good test for the efficacy of the modeling
paradigm ...can the API we create be usable by ONOS ...and so forth. All great ideas Ken. What concrete steps would you suggest we take to get us moving forward on these ideas? I know .. "stop it already" ...but, still ..just thinking a bit about what
we can do together if there is no direct integration. Nice ideas. --dmm
On 10/1/13 1:06 PM, "David Meyer" <dmm@...> wrote:
On Tue, Oct 1, 2013 at 8:49 AM, Ken Gray <kgray@...> wrote:
Thanks, Phil. I'd like to thank Dave for arranging/suggesting for the
ONOS
folks (Guru et al) to come in and present. I had seen their
presentation
some time ago, and it looks even more polished now. I'm left with a
"where
do we go from here" feeling. Thnx/my pleasure. Thanks to Anees for doing the logistical work.
IMO, the presentation brings back out a couple of dormant topics and
probably casts our a few new ones for consideration as well.
First, I was impressed with how well prepared they were to discuss their
consistency models and how their infrastructure supported these. While
they
use different tooling and have a different mission, they were pretty
crisp
on the role of Zookeeper in the switch to master binding and their HA
constructs (the visual demonstration was pretty appealing) and overall
clustering via Cassandra. Can we demonstrate similar capabilities
and/or be
this crisp when we launch?
Excellent point. While we've briefly discussed consistency models
we've yet to get the kind of clear articulation we saw from the ONOS
folks. And of course consistency models are core to the scalability of
a distributed system, so this is a discussion we need to continue.
Second, the layer they added with Titan and how it fed their GUI was
very
interesting and again I wondered how ODL tooling compares (we have a
Topology service via a model and data structure, but Titan is a graph
database)?
Also a good point. Graph DBs seem very popular for this application,
and in theory make at least part of an application's job easier.
Finally, on the "where do we go from here" points (knowing full well
that we
DO have a launch of our own in December and that they have a separate
mission - they are single protocol):
What of their technologies would fit well with ODL (e.g. should we be
considering adding new infra to mimic theirs or adapting our own? Are
there
reasons why Infinispan and the Zookeeper/Cassandra paradigm aren't
interchangeable? Could we use Titan in any way? ETC)?
All good questions.
Because they are one of the few remaining ONGOING developments in
OpenFlow,
can_we/should_we interoperate somehow?
Not sure what you mean here. Can you elaborate?
What are the ONOS/ON.Lab guys interested in collaborating on Š if
anything?
The definitely want to find a way to work with us, which is how this
all started.
So, I'm interested in what forum we work these things out Š. One possibility would be do invite the ONOS folks back to the TWS call
during which we give a similar presentation describing our consistency
model, HA, MD-SAL, ... They we could start to tease this apart where
we might adapt eachother's technology(ies).
--dmm
From: Phil Robb <probb@...>
Date: Tue, 1 Oct 2013 09:43:28 -0600
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] The Minutes from the TSC Meeting on
September
26th have been posted to the wiki
Please review them at your convenience and let me know if there are any
edits needed.
Thanks,
Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
_______________________________________________ TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
My one clarification is that the ONOS guys are probably going to still get
some "share" of OpenFlow deployment, particularly in R&E. Maybe if they
don't "integrate" some of their IP, one of the things we COULD do is
explore the E-W federation interface ...or maybe we can talk about how our
model-driven SAL creates API, review the model and agree (at least) on a
common OpenFlow API. Though I don't want/need/desire to do the ONF's work
FOR them, this would be a good test for the efficacy of the modeling
paradigm ...can the API we create be usable by ONOS ...and so forth.
I know .. "stop it already" ...but, still ..just thinking a bit about what
we can do together if there is no direct integration.
toggle quoted message
Show quoted text
On 10/1/13 1:06 PM, "David Meyer" <dmm@...> wrote: On Tue, Oct 1, 2013 at 8:49 AM, Ken Gray <kgray@...> wrote:
Thanks, Phil. I'd like to thank Dave for arranging/suggesting for the
ONOS
folks (Guru et al) to come in and present. I had seen their
presentation
some time ago, and it looks even more polished now. I'm left with a
"where
do we go from here" feeling. Thnx/my pleasure. Thanks to Anees for doing the logistical work.
IMO, the presentation brings back out a couple of dormant topics and
probably casts our a few new ones for consideration as well.
First, I was impressed with how well prepared they were to discuss their
consistency models and how their infrastructure supported these. While
they
use different tooling and have a different mission, they were pretty
crisp
on the role of Zookeeper in the switch to master binding and their HA
constructs (the visual demonstration was pretty appealing) and overall
clustering via Cassandra. Can we demonstrate similar capabilities
and/or be
this crisp when we launch?
Excellent point. While we've briefly discussed consistency models
we've yet to get the kind of clear articulation we saw from the ONOS
folks. And of course consistency models are core to the scalability of
a distributed system, so this is a discussion we need to continue.
Second, the layer they added with Titan and how it fed their GUI was
very
interesting and again I wondered how ODL tooling compares (we have a
Topology service via a model and data structure, but Titan is a graph
database)?
Also a good point. Graph DBs seem very popular for this application,
and in theory make at least part of an application's job easier.
Finally, on the "where do we go from here" points (knowing full well
that we
DO have a launch of our own in December and that they have a separate
mission - they are single protocol):
What of their technologies would fit well with ODL (e.g. should we be
considering adding new infra to mimic theirs or adapting our own? Are
there
reasons why Infinispan and the Zookeeper/Cassandra paradigm aren't
interchangeable? Could we use Titan in any way? ETC)?
All good questions.
Because they are one of the few remaining ONGOING developments in
OpenFlow,
can_we/should_we interoperate somehow?
Not sure what you mean here. Can you elaborate?
What are the ONOS/ON.Lab guys interested in collaborating on Š if
anything?
The definitely want to find a way to work with us, which is how this
all started.
So, I'm interested in what forum we work these things out Š. One possibility would be do invite the ONOS folks back to the TWS call
during which we give a similar presentation describing our consistency
model, HA, MD-SAL, ... They we could start to tease this apart where
we might adapt eachother's technology(ies).
--dmm
From: Phil Robb <probb@...>
Date: Tue, 1 Oct 2013 09:43:28 -0600
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] The Minutes from the TSC Meeting on
September
26th have been posted to the wiki
Please review them at your convenience and let me know if there are any
edits needed.
Thanks,
Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
_______________________________________________ TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
On Tue, Oct 1, 2013 at 8:49 AM, Ken Gray <kgray@...> wrote: Thanks, Phil. I'd like to thank Dave for arranging/suggesting for the ONOS
folks (Guru et al) to come in and present. I had seen their presentation
some time ago, and it looks even more polished now. I'm left with a "where
do we go from here" feeling. Thnx/my pleasure. Thanks to Anees for doing the logistical work.
IMO, the presentation brings back out a couple of dormant topics and
probably casts our a few new ones for consideration as well.
First, I was impressed with how well prepared they were to discuss their
consistency models and how their infrastructure supported these. While they
use different tooling and have a different mission, they were pretty crisp
on the role of Zookeeper in the switch to master binding and their HA
constructs (the visual demonstration was pretty appealing) and overall
clustering via Cassandra. Can we demonstrate similar capabilities and/or be
this crisp when we launch?
Excellent point. While we've briefly discussed consistency models we've yet to get the kind of clear articulation we saw from the ONOS folks. And of course consistency models are core to the scalability of a distributed system, so this is a discussion we need to continue.
Second, the layer they added with Titan and how it fed their GUI was very
interesting – and again I wondered how ODL tooling compares (we have a
Topology service via a model and data structure, but Titan is a graph
database)?
Also a good point. Graph DBs seem very popular for this application, and in theory make at least part of an application's job easier.
Finally, on the "where do we go from here" points (knowing full well that we
DO have a launch of our own in December and that they have a separate
mission - they are single protocol):
What of their technologies would fit well with ODL (e.g. should we be
considering adding new infra to mimic theirs or adapting our own? Are there
reasons why Infinispan and the Zookeeper/Cassandra paradigm aren't
interchangeable? Could we use Titan in any way? ETC)?
All good questions.
Because they are one of the few remaining ONGOING developments in OpenFlow,
can_we/should_we interoperate somehow?
Not sure what you mean here. Can you elaborate?
What are the ONOS/ON.Lab guys interested in collaborating on … if anything?
The definitely want to find a way to work with us, which is how this all started. So, I'm interested in what forum we work these things out …. One possibility would be do invite the ONOS folks back to the TWS call during which we give a similar presentation describing our consistency model, HA, MD-SAL, ... They we could start to tease this apart where we might adapt eachother's technology(ies). --dmm
From: Phil Robb <probb@...>
Date: Tue, 1 Oct 2013 09:43:28 -0600
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] The Minutes from the TSC Meeting on September
26th have been posted to the wiki
Please review them at your convenience and let me know if there are any
edits needed.
Thanks,
Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
_______________________________________________ TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
Christopher Price <christopher.price@...>
Hi Ken,
Re ONOS: Great comments and good to re-float some of the outstanding topics we have as of yet not concluded in ODL. (at least in a communicable manner)
I would like to start by prefacing that I believe while ONOS and ODL have similarities they are not equivalent in what is being achieved by the programs. I do think we should look to interop and align where these similarities exist as they have a number
of very good ideas on how to achieve OF control and orchestration.
It's amazing how much a nice GUI, good documentation, and a crisp message can do for perception. This is something we should really look to focus on as a community, as engineers we are more likely to discuss things we want to fix, or publish limitations
as we want to find the best way to overcome them. We should also look, come December, to promote the fantastic capabilities and values we will have achieved in ODL by that time in any way possible.
I also believe that the data, distribution, and persistency model (any by reference technology) topic is a key area to address in ODL next year. In my opinion this is a technology focus area in distributed systems that makes more impact on a solution
than the quality of the software itself. I'm not convinced the ONOS solution has the right answer yet to scale to their targets and am not sure the right answer for ONOS will be the right answer for the ODL.
On the other hand opinions are cheap and I'm liberal with mine, I really want to explore and work on this particular topic in gory detail as a component of the next ODL release.
I expect the right forums to work out these topics is in the projects that address/encompass them. If they don't exist, or are understaffed, we can create or join them. (As an answer that may feel like a glib response, but it is our agreed MO)
Regards,
Chris
From: Ken Gray < kgray@...>
Date: Tuesday, October 1, 2013 8:49 AM
To: Phil Robb < probb@...>, " tsc@..." < tsc@...>
Subject: Re: [OpenDaylight TSC] The Minutes from the TSC Meeting on September 26th have been posted to the wiki
Thanks, Phil. I'd like to thank Dave for arranging/suggesting for the ONOS folks (Guru et al) to come in and present. I had seen their presentation some time ago, and it looks even more polished now. I'm left with a "where do we go from here" feeling.
IMO, the presentation brings back out a couple of dormant topics and probably casts our a few new ones for consideration as well.
First, I was impressed with how well prepared they were to discuss their consistency models and how their infrastructure supported these. While they use different tooling and have a different mission, they were pretty crisp on the role of Zookeeper in
the switch to master binding and their HA constructs (the visual demonstration was pretty appealing) and overall clustering via Cassandra. Can we demonstrate similar capabilities and/or be this crisp when we launch?
Second, the layer they added with Titan and how it fed their GUI was very interesting – and again I wondered how ODL tooling compares (we have a Topology service via a model and data structure, but Titan is a graph database)?
Finally, on the "where do we go from here" points (knowing full well that we DO have a launch of our own in December and that they have a separate mission - they are single protocol):
What of their technologies would fit well with ODL (e.g. should we be considering adding new infra to mimic theirs or adapting our own? Are there reasons why Infinispan and the Zookeeper/Cassandra paradigm aren't interchangeable? Could we use Titan in
any way? ETC)?
Because they are one of the few remaining ONGOING developments in OpenFlow, can_we/should_we interoperate somehow?
What are the ONOS/ON.Lab guys interested in collaborating on … if anything?
So, I'm interested in what forum we work these things out ….
From: Phil Robb < probb@...>
Date: Tue, 1 Oct 2013 09:43:28 -0600
To: " tsc@..." < tsc@...>
Subject: [OpenDaylight TSC] The Minutes from the TSC Meeting on September 26th have been posted to the wiki
Please review them at your convenience and let me know if there are any edits needed.
Thanks,
Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
|
|
|
Thanks, Phil. I'd like to thank Dave for arranging/suggesting for the ONOS folks (Guru et al) to come in and present. I had seen their presentation some time ago, and it looks even more polished now. I'm left with a "where do we go from here" feeling.
IMO, the presentation brings back out a couple of dormant topics and probably casts our a few new ones for consideration as well.
First, I was impressed with how well prepared they were to discuss their consistency models and how their infrastructure supported these. While they use different tooling and have a different mission, they were pretty crisp on the role of Zookeeper in
the switch to master binding and their HA constructs (the visual demonstration was pretty appealing) and overall clustering via Cassandra. Can we demonstrate similar capabilities and/or be this crisp when we launch?
Second, the layer they added with Titan and how it fed their GUI was very interesting – and again I wondered how ODL tooling compares (we have a Topology service via a model and data structure, but Titan is a graph database)?
Finally, on the "where do we go from here" points (knowing full well that we DO have a launch of our own in December and that they have a separate mission - they are single protocol):
What of their technologies would fit well with ODL (e.g. should we be considering adding new infra to mimic theirs or adapting our own? Are there reasons why Infinispan and the Zookeeper/Cassandra paradigm aren't interchangeable? Could we use Titan in
any way? ETC)?
Because they are one of the few remaining ONGOING developments in OpenFlow, can_we/should_we interoperate somehow?
What are the ONOS/ON.Lab guys interested in collaborating on … if anything?
So, I'm interested in what forum we work these things out ….
From: Phil Robb < probb@...>
Date: Tue, 1 Oct 2013 09:43:28 -0600
To: " tsc@..." < tsc@...>
Subject: [OpenDaylight TSC] The Minutes from the TSC Meeting on September 26th have been posted to the wiki
Please review them at your convenience and let me know if there are any edits needed.
Thanks,
Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
|
|
|
Please review them at your convenience and let me know if there are any edits needed.
Thanks,
Phil. -- Phil Robb
Director - Networking Solutions
The Linux Foundation (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb
|
|
|
