Subject: [Roll] RA-DIO timer

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 15 Jul 2009 16:54:47 +0200

Hi all,
 
ND specifies rules as to when unsolicited RAs are sent (RFC4861 section
6.2.4). Is it the intention here to update ND? If separate timers are
maintained and do not timeout at the same time, what is the use of
putting the DIO in a RA?
 
Best,
Julien

---

From: JP Vasseur <[email-masked]>
Date: Wed, 15 Jul 2009 17:10:04 +0200

Hi,

On Jul 15, 2009, at 4:54 PM, Julien Abeille (jabeille) wrote:

> Hi all,
>
> ND specifies rules as to when unsolicited RAs are sent (RFC4861  
> section 6.2.4). Is it the intention here to update ND?

I hope not ...

> If separate timers are maintained and do not timeout at the same  
> time, what is the use of putting the DIO in a RA?
>
> Best,
> Julien
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Jul 2009 17:36:49 +0200

On Jul 15, 2009, at 16:54, Julien Abeille (jabeille) wrote:

> Is it the intention here to update ND?

There is certainly an intention to have an optimized ND in 6LoWPAN.
http://tools.ietf.org/html/draft-ietf-6lowpan-nd

I don't know if any other ROLL LLNs can live with 4861 as is.

Gruesse, Carsten

---

From: JP Vasseur <[email-masked]>
Date: Wed, 15 Jul 2009 17:49:29 +0200

> I don't know if any other ROLL LLNs can live with 4861 as is.

To be determined ... we are right now in the process of agreeing on  
the basics but I completely agree with Julien's point of view here. We  
do need to be cautious here and resist from the attempt of modifying  
all existing IP protocols if not needed.

Cheers.

JP.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Jul 2009 18:41:27 +0200

On Jul 15, 2009, at 17:49, JP Vasseur wrote:

> the attempt of modifying all existing IP protocols

That would indeed take a lot of time.

My observation is that 4861 ND as is is much more useful for Ethernets  
than for LLNs.

But then a ROLL protocol could simply leave open what is used to carry  
its announcement traffic and leave it to a specific link-layer mapping  
to piggyback it on beacons, RAs, whatever.
The RA embedding could be defined to maximize the commonality between  
LLNs that optimize ND LoWPAN-style.

Gruesse, Carsten