[ethbridge-discuss] [dme at sun.com: What next for the ethbridge project?]

[James Carlson]

David Edmondson writes:
> With the recent surge of interest[1] in the ethernet bridging
> implementation, it seems worth reviewing the current state and
> discussing some possible next steps.

Agreed.  (As I said in the project announcement, I was hoping to have
discussions like this one on networking-discuss, because they're wider
than just the RBridges project team details.  If you can redirect
there, that'd be helpful.)

> 1. The currently available code is around 18 months old.
> 2. It's not integrated into the ON build.
> 3. It has a few bugs.
> 4. The STP implementation is not complete.
> 5. The "DLPI promiscuous mode loopback" problem is not addressed.

Also, one of the leaders (Mike Ditto) is gone and the project state is
unclear.

> As a side-effect of the Solaris on Xen[2] project we did some work on
> 2, 3 and 5 (mostly Dong-Hai). In the end we didn't use that work, so
> it's sitting around in a workspace somewhere un-loved.

It'd be good to get that stuff up on opensolaris.org, at least.

> The RBridges project[3] has an interest in ethernet bridging, and the
> web page suggests that perhaps the implementation from "this" project
> would be useful.

Yes.  At this point, we don't know.

For what it's worth, RBridges is just _me_ right now.  It's a little
thin.  We have more people (Paul Jakma and Rishi) coming on board in a
couple of months, depending on their current projects.  So, some
things, such as who is going to do the underlying bridging support,
have been ignored.

I'd like to have someone else do the underlying generic bridging work
because they're motivated.  That'd be great, and I'd welcome
collaboration with an active ethbridge project.  Failing that, though,
we'll have to figure out what makes sense for our project, even if
that means reinventing a wheel.

This is the sort of thing that an active Networking Community should
also help drive.  :-/

> So, what to do next? Here are some options that occurred to me:
> 
> * Produce an updated version of the code in its' current form
>   (i.e. standalone build, no DLPI changes),
> * Produce an ON derived gate with the bridging code and DLPI
>   promiscious mode changes integrated,
> * Nothing - leave things limping along,
> * Abandon the current bits and close down the project.

In order to determine which of these is the right direction, I think
it'd be helpful to have a design document for the existing bridging
code.  Does that exist?  Other than a README and a few discussions, I
don't see one.

If we don't have that, it'd be good to have access to the source.  I
assume that the 19-month-old ethbridge-0.9.tar.gz isn't the latest
stuff ... does anyone know what is?  (Should I contact Dong-Hai or
someone else?)

> The first of these would be relatively simple and, presumably, useful
> to the people who are using the existing code.
> 
> The second would be more useful to some (due to the loopback changes),
> but is incomplete (the loopback changes were not finished) and more
> difficult to build (because you have to build ON). This version would
> work as well as the first when built.

I suspect that (1) would be the quickest way to a prototype.  Given
the complexities in the rest of the RBridges project -- handling TRILL
and updating IS-IS with bridging data -- I'm very much in favor of
having prototype bits around for significant chunks.  (This is why I
ported the Quagga IS-IS code to Solaris first.)

For RBridges, we need to get the learned MAC addresses up into user
space where the IS-IS work is done.  This is also where something like
STP (as a control plane item) ought to be running.  We also need to
control L2 forwarding entries from user space.  I think we share a lot
of architectural issues.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677