On 11/26/2015 07:15 AM, Mikael Abrahamsson wrote:
On Thu, 26 Nov 2015, Ray Hunter (v6ops) wrote:
I have read this draft and find it interesting.
The use of host routes would seem appealing to avoid
1) any need for stateful "home agent" and multiple forwarding
2) renumbering of the end nodes when roaming
3) relatively small number of hosts compared to the complexity of the
topology
Use of RFC7217 addresses would seem appropriate, but that assumes
that DAD really is reliable at the time a node attaches to the
homenet for the first time.
Wouldn't it be better to adopt
https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02
and just give every device its own /64 and move that around?
My worry about the whole L3 approach is how long does it take to
re-establish packet flows after the L2 wifi handover between APs
compared to an L2 only solution?
What's the benefit/downside of this approach compared to having
roaming nodes actively take part in the HNCP acting as "multi-homed
routers" with an internal (invariant) /64 VLAN used to bind to
applications?
I'd say this approach adds one more layer that needs to come up before
packets can start flowing again, especially since it would require
routing protocol participation as well, I'd imagine.
If 802.11 can assure L2 handover in 1 second (I don't know how long
the handover time is, just guessing), how much are we willing to add
in time because of L3 mechanisms added on top of this, before packet
flows are up and running again?
Even if it's a 1/2 second, the l2 handover is still far too long for,
say, real time flows. Isn't this why you want to
do make-before-break if at all possible? at that point, time-to-flow is
less of an issue, right?
Mike
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
