[DNA] RE: Feedback on draft-iab-link-indications

[Alper Yegin <alper.yegin@samsung.com>]

> > Well, this is a L2 design issue imho. Once it assesses the situation
as
> > link down and takes actions accordingly (including delivering a link
> > down event notification), the consumer of the L2 notification has
> > nothing to do but take it.
> 
> The problem is that in some scenarios (such as mesh networks) it is
> sometimes unclear whether a link is "up" or "down".  The up/down model
> assumes that a link is either in a state where it has low loss ("up")
or
> very high loss ("down").  In adhoc mesh networks there can be
intermediate
> states were loss is low in one direction and high in the other
direction
> (asymmetry);  

How is the interface treated in that case? It is like "link up for
transmission, down for reception". Is this how it is presented to the IP
stack, and the forwarding takes this into account somehow?

> or where loss is intermediate in one or both directions.
> 
> Even in 802.11 Infrastructure mode, link "up"/"down" indications are
> heavily implementation dependent.  A link can have very high loss
("down")
> at one rate, and be usable ("up") at another rate.  Tests show that
rate
> negotiation performance can vary widely.  Some implementations are
fast,
> others are very slow to recognize when the link has disappeared
entirely.

Yes, I agree correct and consistent implementation of link up/down on
the L2 is important.

> Plus, even if the link to one AP is "down" there may be other APs in
> the same SSID, so that Reassociation may be possible.  So if there is
an
> alternative link that can be brought "up" then it may make sense to
> suppress sending a "down" indication after rate negotiation fails.

Maybe. The downside is, if the L2 is going to suppress the events, it
better know which ones to suppress. This requires pushing some of the
logic from upper-layer to L2. After all, the consumers of L2
notifications are the ones that know which ones are interesting.

> >    2.5.  Remoting implications
> >
> > When an access network element other than the L2 access device needs
to
> > react to link events, remoting the notification is necessary. Please
see
> > http://yegin.org/alper/draft-yegin-l2-triggers-00.txt.
> 
> This is taken care of by existing routing protocols when the route
> metric takes L2 into account (such as ETX).  For example, with ETX an
> increase in L2 loss will result in an increase in the routing metric
which
> will cause downstream nodes to find alternate paths.  If the link goes
> down, then the route metric goes to infinity.

The simple example I had was sending an unsolicited router advertisement
as soon as a new host attaches to the network. That happens with
cdma2k/3GPP2, though the L2 attachment point and first hop router are
the same (PDSN).

> > This is due to the insecure design of that link-layer. What can we
do
> > about it within the scope of L2 notifications and their consumers?
If
> > the L2 is tricked into doing something, and it is simply notifying
the
> > upper-layers after the fact, done is done...
> 
> The problem is caused because 802.11F spoofs a multicast packet
indicating
> that the host has attached before the host has authenticated itself.
The
> problem would not occur if the AP did nothing and let the host's first
> sent packet cause learning to occur in the switches.  Since the AP
cannot
> forward STA packets until authentication completes,  switch learning
> cannot occurr prematurely this way.

I understand. I think this is just an example of a incorrectly
implemented link up on IEEE 802.11 and how it breaks things. If we
characterize the text like that, than I can understand how it fits this
document.

Alper