Hi. At the moment, the controller port is not eligible for slicing (the limitation being no virtual port apart from IN_PORT). We expect to relax this restriction as we move forward (and this also being platform dependent).
There are two cases where the problem might exist : a) between datapath and secchan, and b) between the switch and the controller. We still haven't ended up on a nice abstraction for that, and whether slicing is the right way to do so. For in-band control, there shouldn't be any fundamental problem to implement slicing. When using out-of-band, it becomes more complex (is this a management port, does it support queueing, how is it configured etc). Also, IIRC discovery doesn't introduce any LLDP rule, packets are going to the controller using the "unknown packet" path. It will definitely be easier to handle this in the future if the packets match to a predefined flow entry. Thanks, Y. On Mon, Dec 21, 2009 at 1:08 PM, kk yap <[email protected]> wrote: > Hi, > > cc-ed Yiannis and Dan in case they are not subscribed to this list. > > My understanding is that it can be done, but I suspect it will be > platform specific. Can Glen comment on this? We have some > discussions when applying queues to OFPP_LOCAL. > > Regards > KK > > 2009/12/21 Martin Casado <[email protected]>: > > I agree that if the problem is timeout due to loss from overload, then > the > > only solution is prioritization. > > > > Question for the slicing folks, does slicing extend to the control > channel > > (packets set to the controller?) > > > > > >> I can have a try, but I dont expect the new algorithm will solve my > >> problem. :) > >> > >> On Mon, Dec 21, 2009 at 12:36 AM, Rob Sherwood > >> <[email protected]> wrote: > >> > >>> > >>> Hello Guanyao, > >>> > >>> I don't work for Nicira, but there are some well known scaling issues > >>> with the algorithm used by the discovery protocol. I'm hoping that > >>> this week I should be able to get around to an improved algorithm > >>> that, if you're interested in previewing, I can send you a copy. > >>> > >>> - Rob > >>> . > >>> > >>> > >>> > >>> On Fri, Dec 18, 2009 at 2:44 PM, Martin Casado <[email protected]> > wrote: > >>> > >>>> > >>>> Yeah, it could be due to high-loss from load (unfortunately). > >>>> > >>>> You could try increasing the timeout value in discovery.py. If you > >>>> don't > >>>> have dynamic link events, this should be able to survive temporary > >>>> timeouts. > >>>> > >>>> What switches are you using? > >>>> > >>>> > >>>>> > >>>>> In my program the discovery module times out links sometimes, causing > >>>>> my program not working well. I will debug to find out details why the > >>>>> link fails. Actually they are not supposed to fail. Maybe it's > because > >>>>> of huge data. > >>>>> > >>>>> On Fri, Dec 18, 2009 at 8:41 AM, Martin Casado <[email protected]> > >>>>> wrote: > >>>>> > >>>>> > >>>>>> > >>>>>> The goal is to detect link failures, so one would hope that would be > >>>>>> the > >>>>>> most common failure mode. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> I assume LLDP packets are sent periodically. If there is no LLDP, > >>>>>>> what > >>>>>>> will be the most possible reason? The controller or the switch is > too > >>>>>>> busy? > >>>>>>> > >>>>>>> On Thu, Dec 17, 2009 at 3:07 PM, Martin Casado <[email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Discovery times out links when no LLDP packets have been received > >>>>>>>> over > >>>>>>>> some > >>>>>>>> timeout period. Timer values are documented within discovery.py. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> It seems this module will periodically construct the topology. I > >>>>>>>>> dont > >>>>>>>>> know why it will periodically time_out the links. I want to know > in > >>>>>>>>> what situations the links will time_out. > >>>>>>>>> Thanks. > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> nox-dev mailing list > >>>>>>>>> [email protected] > >>>>>>>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> _______________________________________________ > >>>> nox-dev mailing list > >>>> [email protected] > >>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >>>> > >>>> > >> > >> _______________________________________________ > >> nox-dev mailing list > >> [email protected] > >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >> > > > > > > _______________________________________________ > > nox-dev mailing list > > [email protected] > > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > > > > _______________________________________________ > nox-dev mailing list > [email protected] > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > -- Yiannis .
_______________________________________________ nox-dev mailing list [email protected] http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
