<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> wrote: > > > On Jul 20, 2017, at 3:43 PM, Robert Varga <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 > > https://lists.opendaylight.org/mailman/listinfo/controller-dev > > _______________________________________________ > openflowplugin-dev mailing list > 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
