Re: [nox-dev] Preparing for Nox 0.6.0

[Justin Pettit]

On Nov 4, 2009, at 11:22 AM, Martin Casado wrote:

The goal is certainly for Nox 0.6 to support all 1.0 features.   
However, that will happen after wire protocol compatibility  
(shooting for this Friday ... though that might slip).


I'd just like to point out that the final feature set for OpenFlow 1.0  
has not yet been defined.  We will make NOX compatible with the  
current 1.0 description as defined in the OpenFlow spec as it stands  
now.  The final specification of OpenFlow 1.0 will likely be decided  
in early December.  We should have a short turnaround when it's  
finalized, though.


--Justin



___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Preparing for Nox 0.6.0

[Martin Casado]

Hi Amin,

These are all good points.

I'm a little hesitant to advocate using events as a scratch pad for 
distribution.  While that is one approach there are many others.  For 
example, the approach we've toyed with is to put all distributable data 
in a replicated database or DHT.   In this model, state distribution is 
done via the databases and events are only local.  We've found this to 
be a simpler method of reasoning about the scalability limits (which 
converge on the read/mod/write throughput of the db backends).  That 
said, it clearly has high value for debugging.


In response to your last question, there isn't any support for this in 
the core code base.  We know of some deployments which use Linux HA and 
a replicated cdb, but all the soft state must be reconstructed on 
failover.  Certainly for production deployments this is a high-priority 
item, but not on the immediate-term roadmap.


.martin




Hi Martin,

I meant requiring the originators to add themselves (I can think of
workarounds to have it work implicitly, but they are
compiler/architecture specific).

This feature is not only useful for debugging, it can also be used to
deploy multiple NOX controllers to control a single network: On each
controller *capture a set of ofp_msg_events* (e.g., only a small
portion of packet_in events change the controller state) and
*replay/dispatch* them on the others. We need to discard any outgoing
ofp packets caused by the replayed events and for that we need to keep
track of what events triggered other events/messages.

Also, to find out which events are *important* (i.e., alter the
controller state), the controller and the running applications need to
mark events explicitly. In other words, it is the
controller/application developer's job to specify which events should
be propagated to other controllers. This part also requires the
feature mentioned above. That is because if a non-ofp_msg_event is
marked we should be able to trace back to the original ofp_msg_event
and mark it. Am I right about the ofp_msg_events being the driving
force of NOX operation?

And my last question: Is there currently anyway for two NOX instances
to synchronize their states for fail over? If not, are there any plans
to provide such a feature? Is there any way for a
controller/application to store its transient state on disk? What
happens in a production network with hundreds of switches when the
controller crashes and comes back up in a few seconds? Should it
rediscover the topology, host-ip-mac bindings, etc. from scratch?


Cheers,
Amin

  

Regarding tracing the event call stack.  This would certainly be a useful
debugging tool.  However, the nature of events is that the infrastructure is
decoupled from the senders and receivers so it isn't clear to me how we'd
mark the originator an a general way without requiring the originators to
add themselves.  I'm certainly open to ideas ...




Thanks,
Amin
  



___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Preparing for Nox 0.6.0

[Amin Tootoonchian]

Hi Martin,

I meant requiring the originators to add themselves (I can think of
workarounds to have it work implicitly, but they are
compiler/architecture specific).

This feature is not only useful for debugging, it can also be used to
deploy multiple NOX controllers to control a single network: On each
controller *capture a set of ofp_msg_events* (e.g., only a small
portion of packet_in events change the controller state) and
*replay/dispatch* them on the others. We need to discard any outgoing
ofp packets caused by the replayed events and for that we need to keep
track of what events triggered other events/messages.

Also, to find out which events are *important* (i.e., alter the
controller state), the controller and the running applications need to
mark events explicitly. In other words, it is the
controller/application developer's job to specify which events should
be propagated to other controllers. This part also requires the
feature mentioned above. That is because if a non-ofp_msg_event is
marked we should be able to trace back to the original ofp_msg_event
and mark it. Am I right about the ofp_msg_events being the driving
force of NOX operation?

And my last question: Is there currently anyway for two NOX instances
to synchronize their states for fail over? If not, are there any plans
to provide such a feature? Is there any way for a
controller/application to store its transient state on disk? What
happens in a production network with hundreds of switches when the
controller crashes and comes back up in a few seconds? Should it
rediscover the topology, host-ip-mac bindings, etc. from scratch?


Cheers,
Amin

> Regarding tracing the event call stack.  This would certainly be a useful
> debugging tool.  However, the nature of events is that the infrastructure is
> decoupled from the senders and receivers so it isn't clear to me how we'd
> mark the originator an a general way without requiring the originators to
> add themselves.  I'm certainly open to ideas ...


Thanks,
Amin

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Preparing for Nox 0.6.0

[Martin Casado]

I very much agree that third party packaging needs to be added to Nox.  
The next release has much better support for this but could still use 
some improvements. Thanks for the comment, will keep it in mind.  And if 
you have any ideas of a convenient use model, please share. :)

.martin


Hello Martin,
This very good news! :)


One of the principles of NOX/OpenFlow is the emergence of new 
technologies (protocols, applications...). Then it would be good if 
the user can create their own space in the directory NOX.  As a 
suggestion, it would be nice to have a small section in the next 
version (documentation) on this subject.  Well I've done it here in 
our project (remove all our modules of the coreapps/examples 
directory) and had a little work, first because I needed to recompile 
the NOX, second because it did not work in the root directory 
(noxcore/src)(why?). I needed to create it within the 
(noxcore/src/netapps), ie: noxcore/src/netapps/myapps.


For example, let's say that some team is working with data center, a 
workspace for your application would noxcore/src/dcapps and not 
noxcore/src/(coreapps|netapps|webapps)/dcapps, OK?!


Atenciosamente,

Macapuna - Unicamp


On Mon, Nov 2, 2009 at 1:24 AM, Martin Casado > wrote:


Hi all,

We're going to start preparing to put Nox 0.6.0 up on noxrepo.
 This release will include significant improvements to the netapps
 (authenticator, routing, topology), debugging, documentation, and
OpenFlow 1.0 wire support.  Because there will be some changes to
the API, we'll be developing within a separate branch for the time
being.
If anyone has significant outstanding patches that they'd like to
see get into 0.6, please let me know.  The current 0.5 code base
will not be supported going forward.
Otherwise, this shouldn't disrupt any ongoing work.
thanks,
Martin

___
nox-dev mailing list
nox-dev@noxrepo.org 
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org




--
Carlos Macapuna




___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Preparing for Nox 0.6.0

[Martin Casado]

Hi Amin,

The goal is certainly for Nox 0.6 to support all 1.0 features.  However, 
that will happen after wire protocol compatibility (shooting for this 
Friday ... though that might slip).


Regarding tracing the event call stack.  This would certainly be a 
useful debugging tool.  However, the nature of events is that the 
infrastructure is decoupled from the senders and receivers so it isn't 
clear to me how we'd mark the originator an a general way without 
requiring the originators to add themselves.  I'm certainly open to 
ideas ...


.martin


Hi Martin,

Will the upcoming NOX release be OpenFlow 1.0 feature compatible and
not just OpenFlow 1.0 candidate wire protocol compatible?

One more question: It seems that it is currently impossible to trace
an event and a NOX generated OpenFlow message back to their originator
events (e.g., a Packet_in_event may cause other events to be
dispatched and some OpenFlow messages to be sent out). It would be
useful to have an entry in the Event and OpenFlow Message classes to
pinpoint their originators. It seems that this needs only a few
changes to the code base and enables NOX (& third-party applications)
to have a high level view of NOX operation. I am working on OpenFlow
control plane distribution and this feature would be quite useful for
that I believe.


Thanks,
Amin

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
  



___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Preparing for Nox 0.6.0

[Amin Tootoonchian]

Hi Martin,

Will the upcoming NOX release be OpenFlow 1.0 feature compatible and
not just OpenFlow 1.0 candidate wire protocol compatible?

One more question: It seems that it is currently impossible to trace
an event and a NOX generated OpenFlow message back to their originator
events (e.g., a Packet_in_event may cause other events to be
dispatched and some OpenFlow messages to be sent out). It would be
useful to have an entry in the Event and OpenFlow Message classes to
pinpoint their originators. It seems that this needs only a few
changes to the code base and enables NOX (& third-party applications)
to have a high level view of NOX operation. I am working on OpenFlow
control plane distribution and this feature would be quite useful for
that I believe.


Thanks,
Amin

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Preparing for Nox 0.6.0

[Macapuna, Carlos A. B.]

Hello Martin,
This very good news! :)


One of the principles of NOX/OpenFlow is the emergence of new technologies
(protocols, applications...). Then it would be good if the user can create
their own space in the directory NOX.  As a suggestion, it would be nice to
have a small section in the next version (documentation) on this subject.
Well I've done it here in our project (remove all our modules of the
coreapps/examples directory) and had a little work, first because I needed
to recompile the NOX, second because it did not work in the root directory
(noxcore/src)(why?). I needed to create it within the (noxcore/src/netapps),
ie: noxcore/src/netapps/myapps.

For example, let's say that some team is working with data center, a
workspace for your application would noxcore/src/dcapps and not
noxcore/src/(coreapps|netapps|webapps)/dcapps, OK?!

Atenciosamente,

Macapuna - Unicamp


On Mon, Nov 2, 2009 at 1:24 AM, Martin Casado  wrote:

> Hi all,
>
> We're going to start preparing to put Nox 0.6.0 up on noxrepo.  This
> release will include significant improvements to the netapps
>  (authenticator, routing, topology), debugging, documentation, and OpenFlow
> 1.0 wire support.  Because there will be some changes to the API, we'll be
> developing within a separate branch for the time being.
> If anyone has significant outstanding patches that they'd like to see get
> into 0.6, please let me know.  The current 0.5 code base will not be
> supported going forward.
> Otherwise, this shouldn't disrupt any ongoing work.
> thanks,
> Martin
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>



-- 
Carlos Macapuna
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org