[Ns-developers] 802.11s code review

[Gustavo Carneiro]

2009/3/16 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> 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.


I am still no following.  I thought a .11s MAC layer would have its own
private instance of a routing agent.  Why would you have one routing agent
managing more than one .11s card?  Is that described in the .11s draft, or
any other standard?


>
>
> 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)


The BridgeNetDevice is a (virtual) netdevice because it makes interaction
with IPv4 much simpler.  You can assign a single IPv4 address to this
virtual interface.  When IP sends packets to BridgeNetDevice, the packet is
flooded to the entire bridged network, and IP routing works correctly
because there is only one interface representing the entire bridged network
segment.

The alternative would be to define a new API to tell IPv4 something like
"look, this, this, and that netdevice all are on the same L2 network, so
when you send packets send to all of them, not just one".  I think a
BridgeNetDevice is a simpler approach to the problem.  That this is the
approach followed by Linux [1] lends weight to this opinion.

[1] http://www.linuxfoundation.org/en/Net:Bridge


> >
> > 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
>
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert