[Ns-developers] 802.11s code review

[Mathieu Lacage]

On Mon, 2009-03-16 at 15:07 +0000, Gustavo Carneiro wrote:
> 
> 
> 2009/3/16 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> I really do not understand why you need an inner learning bridge
> inside a .11s mesh point netdevice.  I do not understand what the

The idea would not be to have an inner learning bridge within a mesh
device: it would be to reuse the glue between a node and the
forwarding/learning function of a learning bridge and move that
common/reused clue in a NetDevice intermediate base class such that both
the learning bridge and the routing device share this code.

>  concept of "port" inside a netdevice means.  Last time I saw a .11s
>  draft (a couple of years ago), I saw nothing of this sort; all I saw
> was a tree formed by mesh portal announcements, and routing was either
> "send to the mesh portal" or "discover route using AODV-like or
> OLSR-like protocol", nothing at all like learning bridge was used for
> intra-mesh forwarding.  So without understanding this "port" concept,
> I really cannot comment on this.  Perhaps the 802.11s standard has
> evolved, but I wouldn't know because I am not following...

I believe, that within the context of this code, a 'port' is merely a
network card which the layer-2 routing protocol will manage. What is
central to this code seems to be the idea that you don't have to run the
same layer-2 routing protocol over all network cards. 

Note, that, of course, you could chose to implement the routing protocol
on top of the netdevices, at a layer logically equivalent to ip and arp,
instead of within one of the netdevices. I am not sure what would be the
pros and cons of this solution. Well, I can see that it would be simpler
to understand the code but, I don't understand enough about this to know
what would be the cons. Well, actually, you probably know why the
BridgeNetDevice is a NetDevice subclass instead of being an aggregate to
the Node which manages all incoming packets and devices, right ? Would
you mind spell this out for me ? (yes, I am asking because I can't
remember)
> 
> One major comment I would have is, stop calling classes L2This and
> L2That.  Layer 2 is too broad a term to be used in this context.
> Maybe Ieee802Xxx, or MeshXxx.

Yes, the current naming is somewhat confusing.
> 
> Another major comment on style is that the "design patterns" guys
> usually say it is bad to design too much inheritance-oriented.  Here I
> see LearningBridgeNetDevice --> L2RoutingNetDevice --> NetDevice.  The
> design patterns gurus often say you should use aggregation instead of
> inheritance when possible.  So ask yourselves, could the same problem
> be solved via aggregation instead of inheritance without noticeably
> complicating things?

Well, I sort of already asked myself this question: the current code is
really not very trivial to follow and I can see a lot of duplication
with the bridge code/API so, I would see value in avoiding both the code
duplication and simplifying a bit the code paths to avoid another level
of indirection. Right now, the l2routingnetdevice duplicates code from
bridgenetdevice and duplicates information from its associated
l2routingprotocol: an l2routingprotocol can't really exist without an
associated l2routingnetdevice.

Mathieu