Re: [DNA-BOF] Using L2 to provide Instantaneous MD & ND

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Bernard,

Bernard Aboba wrote:
>>Also the reachability based on reception of broadcast beacons
>>is not sufficient to determine that the AP can hear your transmissions.
>>Probe-Request/Response may work, as will authentication,
>>but not passive beacon reception.
> 
> 
> On the fringes of coverage it is possible for a station to be able to hear
> the Beacons and Probe Responses and possibly even to successfully complete
> an Association/Reassociation exchange.  However, attempting to send
> substantial amounts of data will fail.
> 
> In general the reachability test is *essential* because L2 hints are
> intrinsically fallible.  We have learned this lesson in many painful ways
> over the years.
> 
> 
>>Certainly there is value in receiving indications which
>>help distinguish L2 or L3 handover events.
>>Unless there is a predictable protocol and standard for
>>deploying such prefix information, it will always
>>have to be considered a 'weak' hint.
> 
> 
> I'd argue that even if there were a standard, that the "hint" would still
> be "weak" -- by which I mean that a reachability test would still be
> required to confirm it.

Yes I agree (and didn't mean to cause confusion
in this case, was it that our definitions of 'strong'
hints aren't exactly the same?)

> 
>>Is it worth having a standard way to provide this
>>information, so that we can guarantee that it gives a
>>strong hint?
> 
> 
> I don't think that a standard can by itself make the hint strong.  You'd
> have to make the probability of a misleading hint negligible, so that a
> reachability test could be dispensed with.  An example of a strong hint
> might be a cached RA that is only dispensed when the station has been
> securely associated to the VLAN that it was received from.  Note that
> nothing like this has yet been proposed in IEEE 802.

Indeed, it works though (I implemented JinHyeock's idea).
There were no VLAN's involved in the test case.

Really, the function is L3 oriented (IPv6 datagram carried
in a standard data frame) so I'd guess that it's not
explicitly IEEE, though it overlaps.

In this example L3 bidirectional reachability is not
established with the Cached RA. It may be moved
off the critical path though.

>>Perhaps, but I think that such a protocol looks like
>>something able to be better handled by CAPWAP than DNA.
> 
> 
> CAPWAP is defining a "split" AP model.  It is not dealing with handoff
> optimization.  That is the task of the IEEE 802 Handoff Executive
> Committee Study Group (ECSG).

The configuration may be L3 oriented though
containing IP prefixes and router information.
This could be handled by using capwap, radius, etc...
(rather than the advertisment of handoff
data which would be L2 based, in Paul's idea).
Which is why I mentioned capwap.

Alternatively, 802 could handle the
configuration using IAPP/Radius..

In either case the configuration is outside
the scope of DNA, even if the IEs for the prefixes
were.

Greg