Subject: Re: [6lowpan] "cry out loud" vs. "white board"

From: "Porcu Giorgio" <[email-masked]>
Date: Thu, 20 Mar 2008 13:21:50 +0100

WARNING: contains banned part

Subject: Re: [6lowpan] "cry out loud" vs. "white board"
From: "Porcu Giorgio" <[email-masked]>
To: <[email-masked]>
Date: Thu, 20 Mar 2008 13:21:50 +0100
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>

WARNING: contains banned part

Subject: RE: "cry out loud" vs. "white board"
From: "Porcu Giorgio" <[email-masked]>
To: <[email-masked]>
Date: Thu, 20 Mar 2008 13:21:50 +0100

Hi all,
Pascal wrote:
>>I tried to capture this idea in
>>http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. ...
>>So, what do you think?
In my opinion it's a very good draft and I agree it would be a good idea to try to reduce broadcast traffic for ND.

For this reason, the "white board" approach is very appealing, but I have some questions about it...
Tell me if I'm wrong: the main idea is that there is a logical centralized "white board" that includes all the IP addresses from multiple PANs.

But what happens within a PAN when a backbone router crashes? How can a node get routing info about other nodes belonging to its same PAN if it can't access the white board residing on the crashed backbone router? The nodes may keep their own routing cache, but this is not a completely reliable approach.

Is that point interesting for the WG? (maybe is out of scope of this specific draft)
Let me know if you have any thoughts about this (or if this problem it's been yet analized by the WG :p)

Regards
Giorgio

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Mar 2008 13:43:53 +0100

On Mar 20 2008, at 13:21, Porcu Giorgio wrote:

> But what happens within a PAN when a backbone router crashes? How  
> can a =
> node get routing info about other nodes belonging to its same PAN if  
> it =
> can't access the white board residing on the crashed backbone  
> router? =

I'd say: The "backbone router" as a SPOF is a problem *if* the network  
can do anything useful without the "backbone router".

If it can't (e.g., the whole point is connecting the sensors to some  
other node on the Internet), then the network can just fall apart (of  
course, the failure still needs to be battery-efficient, and there  
needs to be an orderly re-bootstrap when the/a backbone router comes  
up again).

If it can: you need to elect a new coordinator.  That might work best  
if there is a backup coordinator in operation all the time.
Multiple coordinator candidates do cause all the partition/merge  
problems that I won't go into right now.

A coordinator is also a useful thing to have for key management, so I  
believe it is best to think of the address management and key  
management problems in combination.

Gruesse, Carsten

PS.: Giorgio: You need to fix your mail setup: you should never send  
ms-tnef towards the Internet; I'm not sure how many people could even  
read your message.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 26 Mar 2008 18:20:37 +0100

Hi Giorgio:

Please see inline

>In my opinion it's a very good draft and I agree it would be a good 
>idea to try to reduce broadcast traffic for ND.
>
>Tell me if I'm wrong: the main idea is that there is a logical 
>centralized "white board" that includes all the IP addresses from
multiple PANs.

[Pascal] Right; but there can and should be multiple backbone routers
interconnected by a backbone, thus the name. Because the second half of
the BbR feature is ND-proxy so that any node on the backbone is
virtually on the same link as any device behind a BbR.

>
>But what happens within a PAN when a backbone router crashes? How can a

>node get routing info about other nodes belonging to its same PAN if it

>can't access the white board residing on the crashed backbone router? 
>The nodes may keep their own routing cache, but this is not a
completely reliable approach.
[Pascal] When the BbR crashes, that's mostly the same as if you are a
mobile node and your MIP6 Home Agent crashes. Active (similar to MIP6
route optimized) connections with the PAN are maintained, conections to
the outside (similar to via the HA) are dropped. New connections with
unresolved MAC addresses can not be started, and new nodes can not be
inserted. That was acceptable for RFC 3775, I guess that is still.
There's ample space for HSRP/proprietary hot standby solution for backup
when needed.

>Is that point interesting for the WG? (maybe is out of scope of this 
>specific draft) Let me know if you have any thoughts about this (or if 
>this problem it's been yet analized by the WG :p)
>
[Pascal] Well, we are supposed to consider how to implement ND in a
LoWPAN. BbR is a ND solution that adds the concept of backbone to the
picture. That concept comes from real users feedback and we should not
ignore it...

Pascal