Genius supports aliveness monitoring of tunnels using lldp(which uses liblldp), but as Abhijit indicated this is inturn a payload inside “Openflow packet-out message”.
Thanks, Faseela From: genius-dev-boun...@lists.opendaylight.org [mailto:genius-dev-boun...@lists.opendaylight.org] On Behalf Of Abhijit Kumbhare Sent: Friday, July 21, 2017 6:07 AM To: Luis Gomez <ece...@gmail.com> Cc: netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org; openflowplugin-...@lists.opendaylight.org; rele...@lists.opendaylight.org; Robert Varga <n...@hq.sk>; controller-dev@lists.opendaylight.org Subject: Re: [genius-dev] [openflowplugin-dev] [controller-dev] Any takers for liblldp? <snip> I am not sure what this library does but if it is primarily used to process LLDP packets, today I do not see any protocol/plugin other than OpenFlow to send LLDP frames to controller. For that reason I do not see major issue in including this code in openflowplugin. On the other hand if we can replace this by an external library, that would be my first choice. </snip> Key question is whether the library can be used by any other means other than via OpenFlow. If yes - we should keep it outside. Otherwise - add it to OpenFlow Plugin. My understanding is that the code is not specific to OpenFlow and can be used as a generic LLDP packet library for constructing/decoding LLDP packets - and currently the only mechanism to use it is as a payload in an "OpenFlow packet out message". If that is correct - as Robert said - it makes sense to keep it as an external library. On Thu, Jul 20, 2017 at 4:49 PM, Luis Gomez <ece...@gmail.com<mailto:ece...@gmail.com>> wrote: > On Jul 20, 2017, at 3:43 PM, Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> > wrote: > > On 21/07/17 00:32, Sam Hague wrote: >> What was the reasoning not to absorb liblldp into the openflow project? >> Because lldp isn't part of openflow? That makes sense and I don't think >> we will find a project as this really is it's own protocol. > > I do not agree with that -- LLDP is a full-blown protocol, but liblldp > does not implement the data plane part of it (but hey, anyone could do > that using liblldp). I am not sure what this library does but if it is primarily used to process LLDP packets, today I do not see any protocol/plugin other than OpenFlow to send LLDP frames to controller. For that reason I do not see major issue in including this code in openflowplugin. On the other hand if we can replace this by an external library, that would be my first choice. > >> For the sake of finding a good place to park it, though, ofp is a good >> project since ofp uses the lib and genius and netvirt use ofp. > > I started off with thinking it would better be absorbed, but the mailing > list discussion made me see the benefit of it being a separate project. > >> If not, what was the consensus on if we could reduce the process >> requirements for making this it's own project? Could we just make the >> project and let it automatically get pass on the milestones? Make it >> such that we only have the startup costs to migrate it to a project, get >> it building and leave it on auto-pilot. > > The primary reason is that this is self-contained piece of code, which > depends on odlparent only and has utterly stable codebase. > > Note that odlparent is released independently of autorelease, which > means so can this project. > > That means we only have to build this project once per odlparent release > (if even necessary), test it once and then reuse it across downstream > projects. No -SNAPSHOTS involved. > > Hence yes, this is a project-on-autopilot. It just needs a caretaker. > > That does not preclude it from being a fully active project in the > future though. > > Regards, > Robert > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> > https://lists.opendaylight.org/mailman/listinfo/controller-dev _______________________________________________ openflowplugin-dev mailing list openflowplugin-...@lists.opendaylight.org<mailto:openflowplugin-...@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
