Hi Carsten and Richard >> On a related note, there is some discussion of what happens >> when a non-Edge-Router reboots (using a lollipop mechanism >> for TIDs), but I didn't see anything about what happens if >> an Edge Router reboots. Is the expectation that the >> whiteboard will be kept in non-volatile storage? > >That would help. >(If you don't do that, it will be hard to avoid a blackout for about a >registration lifetime, unless we have something like an "ER reboot >sequence" disseminated through the network. Which will bring a >galopping herd of re-registrations, unless dithered, which will cause >blackouts for the dithering period.)
This is a similar discussion we had designing similar features like MIP Home Agent and IPv6 ND proxy in general. The usual conclusion is that High Availability is in practice often proprietary and left to implementation. You do not necessarily do it the same way when you have 2 routers, 2 forwarding blades in a same router, etc.... In a limited deployment that can afford a lapse while the re-registrations happen, we can live with simple, low cost routers like home gateways. If you need more, then you buy an higher-end router that has HA facilities. Now if we can do something to make our protocol better, for instance by finding a better way to use the secondary binding then fine and we are certainly open to proposals in this matter. Just that we don't want to mandate the ultimate weapon on the smaller, simpler systems. Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Carsten Bormann >Sent: mardi 9 juin 2009 20:36 >To: Richard Kelsey >Cc: [email protected] >Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] > >> In particular, I think that it would be >> unfortunate if forwarding messages between two LoWPANs >> required that any router doing such forwarding have a >> whiteboard. Is this the case? > >Right now, the architecture is that packets only enter and leave a >LoWPAN through an ER. >ERs have whiteboards and (if multiple) are interconnected by a fast >backbone link. > >Can you give more details of a scenario where this is suboptimal? > >> Would it be possible to avoid the need for a whiteboard in a >> network by only using IPv6 addresses derived from EUI64s? >> While conflicts are still possible, they are very unlikely >> (outside of development and testing, where they can happen >> with some regularity). > >I've got one word for you: counterfeiting. > >(So the point is less the detection of IPv6 address collisions but of >EUI-64 collisions, indeed.) > >> 802.15.4 16-bit addresses could >> still be used for link-layer next-hop addresses, as that >> requires only local, and not global, conflict detection. > >How does local conflict detection work when nodes tend to attach to >routers they haven't seen before? >Of course, a node could have many 16-bit short addresses if we were >using the cluster approach (with separate PAN IDs per router). >Is that what you are hinting at? > >(Such an approach would cost some header compression efficiency, at >about 8 bytes per message.) > >> On a related note, there is some discussion of what happens >> when a non-Edge-Router reboots (using a lollipop mechanism >> for TIDs), but I didn't see anything about what happens if >> an Edge Router reboots. Is the expectation that the >> whiteboard will be kept in non-volatile storage? > >That would help. >(If you don't do that, it will be hard to avoid a blackout for about a >registration lifetime, unless we have something like an "ER reboot >sequence" disseminated through the network. Which will bring a >galopping herd of re-registrations, unless dithered, which will cause >blackouts for the dithering period.) > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
