Hi Zach:
> b) Explicitly say what the 6LR should do in this case. If we explicitly forbid a > 6LR from attaching to two different LoWPANs at the same time, then this > fixes this potential problem (it can obviously still attach to multiple default > routers in the same LoWPAN). This way the host -> 6LR -> 6LBR attachments > are always under the same authoritative border router (which might be a > coordinated one as pointed out above). Inside a given instance, RPL has made that exact same decision. A router can only attach to one DODAGID. Nodes get the configuration from that router, that is authoritative for the prefixes and everything else the routers need to operate RPL. OTOH, RPL also demands that a node can attach to multiple parents, that is an absolute MUST for us. RPL ensures that the parents all report to a same root. Cheers, Pascal > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Zach Shelby > Sent: Friday, June 11, 2010 11:48 AM > To: Erik Nordmark > Cc: [email protected] > Subject: Re: [6lowpan] Multiple 6LBRs > > On Jun 11, 2010, at 12:25 PM, Erik Nordmark wrote: > > > On 06/11/10 01:18 AM, Daniel Gavelle wrote: > >> Erik, > >> > >> I agree that it is very important to keep the contexts in sync within > >> a network. I can also see that the L2 security can be used to > >> separate networks. Given these two conditions, when would there be a > >> need for two 6LBRS in a network to have different addresses / version > number spaces? > > > > There is a difference between how I would build a product today using the > specification, and what we should support in the specification. > > > > In a product, especially one that uses compression contexts, it makes sense > having the ABRO originate from a logical management entity to ensure that > all the 6LBRs send out the same information. But that belongs in the vendor's > product spec. > > > > But for general applicability to route-over networks I think allowing the > 6LBRs to be autonomous is the right thing to do in the protocol specification. > > > > Thus the protocol specification isn't the same as the product specification. > > Yep, I agree with Erik here. In an enterprise environment you will be able to > manage the whole 6LBR infrastructure (and the contexts), so we are OK > there. In home environments you will probably keep LoWPANs separate > using L2 encryption. > > However as public/urban 6LoWPAN networks become more common (we > are deploying one right now in Oulu, Finland), there will be situations where > a 6LR will hear RAs originated from different authoritative border routers > with different points of attachment to the Internet (and different sets of > context). We have two choices what to do in this situation: > > a) Say nothing about it. Here we have a risk that a poor 6LR implementation > will start mixing contexts, or will even advertise two sets of RAs - which is > obviously broken. This is the case Daniel (and myself) are concerned about. > > b) Explicitly say what the 6LR should do in this case. If we explicitly forbid a > 6LR from attaching to two different LoWPANs at the same time, then this > fixes this potential problem (it can obviously still attach to multiple default > routers in the same LoWPAN). This way the host -> 6LR -> 6LBR attachments > are always under the same authoritative border router (which might be a > coordinated one as pointed out above). > > Zach > > > > > Erik > > > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lowpan > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
