> >My concern is about wireless media which can experience large variations > >in signal/noise ratio, in the process generating transient "link down" > >indications. This could cause those connections to migrate to other > >media/interfaces. > > Wouldn't that be something that should be fixed in the driver for that > interface? Declaring a link to be down has significant implications on many > systems, this shouldn't be done at the drop of a hat for links where this > determination isn't easily made. Having drivers declare links down too soon > and then having the next layer ignore that is not a good solution, especially > because there are also link layers which can determine their up/down status > much more accurately. Drivers vary widely in their behavior. I have seen drivers that can take as long as 30 seconds to notice that the point of attachment is gone after pulling the plug. Other drivers notice the missing network announcements or low SNR on incoming data and react much sooner. However, even after sending a "link down", a "link up" can come soon after if a new point of attachment is discovered. So rather than treating a "link down" as a trigger, it is probably best to treat it as a "hint", lowering the timers. > >If the host has implemented the strong host model, then > >when the transient "link down" is resolved, the connection won't resume > >using the prior outbound interface. This could lead to applications > >experiencing sub-optimal conditions long-term based on a transient > >event. > > Hm, I must say that I don't know off the top of my head if shim6 will > automatically rehome to the primary address pair after some time. I'll have to > reread the specifications. Or does anyone else remember this? I don't think it will automatically re-home in the strong host model. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf