Subject: [Roll] Feed-back appreciated for RPL Revision -09 to be posted in 3 days!

From: JP Vasseur <[email-masked]>
Date: Wed, 9 Jun 2010 11:26:06 +0200

Dear WG,

One more time, thanks for your energy and involvement to keep us on  
track with our plan for RPL.

The cut-off date for the Virtual WG meeting that will take place on  
June 16 is this coming Friday and the RPL authors team has been  
working hard on the revision -09, which should solve a number of the  
opened tickets. Still there are a few items that triggered some  
discussion but we would need more feed-back from you to draw a  
consensus to move on.

1) Are we keeping the use of sibling (S Bit thread): see the detailed  
discussion on the ML.
https://svn.tools.ietf.org/wg/roll/trac/ticket/43

2) Use of MTU and SSLA option:
https://svn.tools.ietf.org/wg/roll/trac/ticket/42

Any quick feed-back on the list would be appreciated, for rev09.

Thanks.

JP.

---

From: Daniel Gavelle <[email-masked]>
Date: Wed, 09 Jun 2010 10:51:52 +0100

I think the MTU and SLLA options should not be in ROLL but only used in ND.

I haven't used the S bit in my implementation.

Daniel.

JP Vasseur wrote:
> The cut-off date for the Virtual WG meeting that will take place on June 
> 16 is this coming Friday and the RPL authors team has been working hard 
> on the revision -09, which should solve a number of the opened tickets. 
> Still there are a few items that triggered some discussion but we would 
> need more feed-back from you to draw a consensus to move on.
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
> 

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Jun 2010 13:06:46 +0200

Hi Daniel

Do you think that the MTU within the LLN should be the same?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Daniel Gavelle
> Sent: Wednesday, June 09, 2010 11:52 AM
> To: JP Vasseur
> Cc: ROLL WG
> Subject: Re: [Roll] Feed-back appreciated for RPL Revision -09 to be
posted in
> 3 days!
June

---

From: Daniel Gavelle <[email-masked]>
Date: Wed, 09 Jun 2010 12:38:31 +0100

Pascal,

I am interested in 6LowPAN, where RFC4944 fixes the MTU at 1280 octets 
so the MTU option isn't required.

If the MTU option is required by other link layers, why can't the MTU 
option be sent in ND?

Daniel.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Jun 2010 13:47:53 +0200

> If the MTU option is required by other link layers, why can't the MTU
option
> be sent in ND?

I return the question. How would that work?

Pascal

> From: Daniel Gavelle [mailto:[email-masked]]
> Sent: Wednesday, June 09, 2010 1:39 PM
> To: Pascal Thubert (pthubert)
> Cc: JP Vasseur; ROLL WG
posted in
> I am interested in 6LowPAN, where RFC4944 fixes the MTU at 1280 octets
so
> the MTU option isn't required.
> 
option
> be sent in ND?
> >> I think the MTU and SLLA options should not be in ROLL but only
used
> > in ND.
> >> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No:
> >> 3191371  Registered In England http://www.jennic.com

---

From: Daniel Gavelle <[email-masked]>
Date: Wed, 09 Jun 2010 13:10:25 +0100

Pascal,

If the link has a variable sized MTU, the MTU option can be sent in an 
RA, as in RFC 4861.  ND RS/RA can be done before sending DIS and joining 
a ROLL DAG.

Daniel.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 9 Jun 2010 15:32:04 +0200

Hi All,

Here is my opinion:
1) As support for siblings is a MAY in the current draft I don't see a need
to remove it although we didn't implemented in our code either.
2) I favor the possibility to use the MTU and SSLA options especially in
DIOs. Use of MTU might not be so useful if the MTU is agreed on a priori
like in 6lowpan. However it might serve as an (optional) way to distribute
the information between routers if it is not the case. The use of SSLA in
DIO solves a specific problem. Indeed the DIO is likely to be the first
message you receive from you parent meaning that your parent won't be in
your neighbor cache when you receive it. So according to RPL you are not
suppose to process the DIO. Putting the SSLA in the DIO would allow you to
create a ND entry in the stale state and then process the DIO.

Best,
Mathilde

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: mercredi, 9. juin 2010 11:26
To: ROLL WG
Subject: [Roll] Feed-back appreciated for RPL Revision -09 to be posted in
3days!

Dear WG,

Thanks.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Jun 2010 18:25:28 +0200

Hi Daniel:

What I read below is that for RPL over foo (foo != 6LoWPAN),  you'd run
ND RA as the dissemination protocol for the MTU information. I suggest
that is a very bad idea. 
RPL DIO is very optimized as a dissemination protocol, in particular
with the use of trickle. And we don't want 2 mechanisms in parallel
doing the same thing.
So unless we merge (back) RA and DIO, I'd suggest that RPL routers use
RPL when they disseminate information about the subnet and do not bother
about RAs from other routers.

Today, RPL operation does not depend on RAs at all. In fact, it is the
other way around. RPL handles everything multihop, whereas RA is used
for router to host communication.
In that model, we expect RPL to disseminate information that can then be
incorporated by the routers in their RAs for local distribution to their
attached hosts.
That is what we do with PIO and RIO. MTU would be the same.

Pascal

> Sent: Wednesday, June 09, 2010 2:10 PM
posted in
> If the link has a variable sized MTU, the MTU option can be sent in an
RA, as
> in RFC 4861.  ND RS/RA can be done before sending DIS and joining a
ROLL
> DAG.
> >>>>> 16 is this coming Friday and the RPL authors team has been
working
> >>> hard
> >>>>> Still there are a few items that triggered some discussion but
we
> >>> would

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 10 Jun 2010 11:15:05 -0700

Hi Daniel and Pascal

I agree with Pascal here.

In my view of a LLN network: Routers form the sub-net cloud while hosts 
just "connect" to that cloud. How routers form and maintain that cloud 
should not be handled by ND (in my opinion). I see routers using the 
routing protocol to exchange sub-net information amongst themselves, 
while hosts use RS/RA to request sub-net information from nearby 
routers. Both routers and hosts may use NS/NA to perform 
address-resolution and NUD one hop away only.

Dario

Pascal Thubert (pthubert) wrote:
>>>> If the MTU option is required by other link layers, why can't the
>>>>         
> MTU
>   
>>> option
>>>       
>>>> be sent in ND?
>>>>         
>>>> Subject: Re: [Roll] Feed-back appreciated for RPL Revision -09 to
>>>>         
> be
>   
>>> posted in
>>>       
>>>> 3 days!
>>>>
>>>> Pascal,
>>>>
>>>> If the MTU option is required by other link layers, why can't the
>>>>         
> MTU
>   
>>> option
>>>       
>>>> be sent in ND?
>>>>
>>>> Daniel.
>>>>
>>>>
>>>>
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>             
>>> Behalf
>>>       
>>>>> Of
>>>>>           
>>>>>> Daniel Gavelle
>>>>>> Subject: Re: [Roll] Feed-back appreciated for RPL Revision -09 to
>>>>>>             
>>> be
>>>       
>>>>> posted in
>>>>>           
>>>>>> 3 days!
>>>>>>
>>>>>>> One more time, thanks for your energy and involvement to keep us
>>>>>>>               
>>> on
>>>       
>>>>>>> The cut-off date for the Virtual WG meeting that will take place
>>>>>>>               
>>> on
>>>       
>>>>> June
>>>>>           
>>>>>>> on the revision -09, which should solve a number of the opened
>>>>>>>               
>>>>> tickets.
>>>>>           
>>>>>>> 1) Are we keeping the use of sibling (S Bit thread): see the
>>>>>>>               
>>>>> detailed
>>>>>           
>>>>>>> discussion on the ML.

---

From: Daniel Gavelle <[email-masked]>
Date: Fri, 11 Jun 2010 09:23:38 +0100

Dario,

In a 6LowPAN network, the routers will need to do 6LowPAN-ND RS/RA in 
order to distribute the compression contexts.  I suppose the context 
(CO) option from 6LowPAN-ND could also be added to ROLL.  However, I 
prefer using 6LowPAN-ND for context and prefix dissemination and ROLL 
for routing.

Also, if the prefix / context information is distributed in ROLL, either 
hosts need to support ROLL or routers need to support two methods for 
prefix distribution: RS/RA (for hosts) and prefix distribution in ROLL.

Daniel.

Dario Tedeschi wrote:
>> that is a very bad idea. RPL DIO is very optimized as a dissemination 
>> protocol, in particular

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Jun 2010 13:24:33 +0200

Hi Daniel:

I respect your preference for the Context Option though mine would be
the opposite. 
I do not mind so much for that case because 1) the option is specific to
6LoWPAN 2) there can be other ways to get a context that's neither RA
nor RPL. 

MTU is different anyway because it impacts RPL operation. If the MTU is
1500 and a node does not support that MTU then it cannot be a router and
should stay a leaf. 

I do not think that RPL should depend on the 6LoWPAN RA dissemination
for its own operation. 

If you main problem is RPL over 6LoWPAN networks, this can trivially be
handled by saying that the MTU option is not used if the RPL network has
an MTU of 1280.

You'll note that the RH4 draft recommends a higher MTU when source route
is in use.
 
Pascal

> Sent: Friday, June 11, 2010 10:24 AM
> To: Dario Tedeschi
> Cc: Pascal Thubert (pthubert); ROLL WG
posted in
> prefer using 6LowPAN-ND for context and prefix dissemination and ROLL
for
> routing.
> 
> Also, if the prefix / context information is distributed in ROLL,
either hosts
> need to support ROLL or routers need to support two methods for prefix
> distribution: RS/RA (for hosts) and prefix distribution in ROLL.
> 
> Daniel.
> 
> 
> Dario Tedeschi wrote:
> > Hi Daniel and Pascal
> >
> > In my view of a LLN network: Routers form the sub-net cloud while
> > hosts just "connect" to that cloud. How routers form and maintain
that
> > cloud should not be handled by ND (in my opinion). I see routers
using
> > the routing protocol to exchange sub-net information amongst
> > themselves, while hosts use RS/RA to request sub-net information
from
> > nearby routers. Both routers and hosts may use NS/NA to perform
> >> What I read below is that for RPL over foo (foo != 6LoWPAN),  you'd
> >> run ND RA as the dissemination protocol for the MTU information. I
> >> suggest that is a very bad idea. RPL DIO is very optimized as a
> >> dissemination protocol, in particular with the use of trickle. And
we
> >> don't want 2 mechanisms in parallel doing the same thing.
> >> So unless we merge (back) RA and DIO, I'd suggest that RPL routers
> >> use RPL when they disseminate information about the subnet and do
not
> >> bother about RAs from other routers.
> >>
> >> Today, RPL operation does not depend on RAs at all. In fact, it is
> >> the other way around. RPL handles everything multihop, whereas RA
is
> >> used for router to host communication.
> >> In that model, we expect RPL to disseminate information that can
then
> >> be incorporated by the routers in their RAs for local distribution
to
> >> their attached hosts.
be
> >>>
> >> posted in
> >>
> >>> 3 days!
> >>>
> >>> Pascal,
> >>>
> >>> If the link has a variable sized MTU, the MTU option can be sent
in
> >>> an
3191371
> Registered In England http://www.jennic.com

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 11 Jun 2010 14:24:48 -0700

Hi Daniel

> prefer using 6LowPAN-ND for context and prefix dissemination and ROLL 
A CO is link-layer information so some might argue that it does not 
below in a routing protocol. Fair enough, but lets be practical here: 
RPL provides a robust way of distributing information amongst routers in 
a LLN network. Why not use it.
> either hosts need to support ROLL or routers need to support two 
> methods for prefix distribution: RS/RA (for hosts) and prefix 
> distribution in ROLL.
I'm not advocating hosts use ROLL, so lets look at your second option 
where routers need to support two methods for prefix distribution: Even 
if a network only used 6LoWPAN ND for prefix distribution, routers still 
need two methods: One-hop RS/RA for router-host prefix distribution and 
RA+ARBO to deal with router-to-router prefix distribution. In fact if 
you look at an RA+ARBO message, it looks remarkably similar to a DIO 
message (where the Version and Address fields in the ARBO can be equated 
to the Version and DAGID fields in the DIO, respectively). Seems to me, 
6LoWPAN ND (with multi-hop) is trying to do the work of a routing 
protocol. I think "Neighbor Discovery" should be taken a bit more 
literally in that it is a protocol for discovering your neighbors and 
not for distributing network configuration (the exception being that one 
would like a host to auto-configure).

Hope you have good weekend
Dario
>> that cloud should not be handled by ND (in my opinion). I see routers 
>> using the routing protocol to exchange sub-net information amongst 
>> themselves, while hosts use RS/RA to request sub-net information from 
>>> that is a very bad idea. RPL DIO is very optimized as a 
>>> dissemination protocol, in particular
>>> then be

---

From: Joakim Eriksson <[email-masked]>
Date: Sat, 12 Jun 2010 11:46:18 +0200

Hello,

> a LLN network. Why not use it.

Another important thing that RPL provides is control over which
DODAG you receive and accept configuration from. With RS/RA there
will not be any  RPL-awareness. If a specific prefix is to be
used only for a specific RPL-instance it will require much more
complex reasoning to figure out which prefix would be for which
RPL-instance when using only RS/RA. The contexts might be ok to
share over the whole LLN (I guess that we might end up with
unwanted complexities otherwise).

Best regards,
-- Joakim Eriksson, SICS

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 14 Jun 2010 09:42:57 +0100

Dario / Pascal,

I can see that sending PIO / CO / MTU in DIO messages has some 
advantages.  Since there is already a mechanism in 6LowPAN-ND for this, 
I am concerned that allowing these messages to be carried in RPL will 
result in interoperability issues.

I suppose the best way forward for the RPL specification is to allow 
these options as a MAY.  Alliances like Zigbee and IPSO would then 
ensure interoperability by requiring one method in their stack profile 
specifications.

Regarding the MTU, I can see how this is needed for networks using a 
mixed Ethernet / 6LowPAN MAC, bridged at layer 2.  However, within the 
6LowPAN, where the MTU is fixed, routers should be allowed to ignore the 
option.  Also stack profiles that are aimed at 6LowPAN only MACs should 
be allowed to exclude the MTU option in their specification.

Daniel.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Jun 2010 11:43:56 +0200

Hi Daniel:

Sure; 

those options would not be present in every packet either, but probably
at least present in a DIO that'd be stimulated by a DIS. So they MAY be
present in packets DIS/DIO.

My sense is that the diffusion in ND is already a MAY because there is
an expectation that the routing protocol in place (eg RPL) already does
the job, in which case that piece of ND is not done.

I suggested that the ND draft be split and that ND focuses on the piece
that are clearly in its land (eg DAD) but no success so far. At the
moment, we have both a confusing overlap and features that are not
necessarily fully covered.  

Especially DAD for large scale networks worries me:
- I can't see a node registering to many LBRs mostly if they are far
away from one another. RPL contains a node within one DODAG.
- I can't see EUI-64 LLAs being used in normal operations, so I can't
see how stateless compression will work for non DAD'ed address

I can see how a backbone can help solve that problem and I developed the
ideas in draft-thubert-6lowpan-backbone-router-02.txt that I just
submitted. There is text about RPL in there since the backbone operation
abstracts the LLN operation into a registration mechanism that can be
instantiated by either ND or RPL. If RPL cannot use 6LoWPAN for DAD,
either because 6LoWPAN ND is not used in the LLN or because 6LoWPAN ND
does not scale to the needs, we can add the unique ID to the DAO transit
info that will serve the purpose of detecting dups.
 
Cheers,

Pascal

> Sent: Monday, June 14, 2010 10:43 AM
> To: Dario Tedeschi
> Subject: PIO, CO and MTU options in DIOs
> 
> Dario / Pascal,
> 
advantages.
> Since there is already a mechanism in 6LowPAN-ND for this, I am
concerned
> that allowing these messages to be carried in RPL will result in
interoperability
> issues.
these
> options as a MAY.  Alliances like Zigbee and IPSO would then ensure
> interoperability by requiring one method in their stack profile
specifications.
> Regarding the MTU, I can see how this is needed for networks using a
mixed
> Ethernet / 6LowPAN MAC, bridged at layer 2.  However, within the
> option.  Also stack profiles that are aimed at 6LowPAN only MACs
should be
> allowed to exclude the MTU option in their specification.
> 
> 
> Daniel.
> 
> 
> 
> Dario Tedeschi wrote:
> > Hi Daniel
> >
> > Daniel Gavelle wrote:
> >> Dario,
> >>
> > RPL provides a robust way of distributing information amongst
routers
> > in a LLN network. Why not use it.
> >>
> > where routers need to support two methods for prefix distribution:
> > Even if a network only used 6LoWPAN ND for prefix distribution,
> > routers still need two methods: One-hop RS/RA for router-host prefix
> > distribution and
> > message (where the Version and Address fields in the ARBO can be
> > equated to the Version and DAGID fields in the DIO, respectively).
> > Seems to me, 6LoWPAN ND (with multi-hop) is trying to do the work of
a
> > routing protocol. I think "Neighbor Discovery" should be taken a bit
> > more literally in that it is a protocol for discovering your
neighbors
> > and not for distributing network configuration (the exception being
> > that one would like a host to auto-configure).
> >
> >>> that cloud should not be handled by ND (in my opinion). I see
> >>> routers using the routing protocol to exchange sub-net information
> >>> amongst themselves, while hosts use RS/RA to request sub-net
> >>> information from nearby routers. Both routers and hosts may use
> >>> NS/NA to perform address-resolution and NUD one hop away only.
> >>>
> >>> Dario
> >>>
> >>>> we don't want 2 mechanisms in parallel doing the same thing.
> >>>> not bother about RAs from other routers.
> >>>>
> >>>> is used for router to host communication.
> >>>> then be incorporated by the routers in their RAs for local
> >>>> distribution to their attached hosts.
> >>>>> in an
> >>>>> in RFC 4861.  ND RS/RA can be done before sending DIS and
joining
> >>>>> a
> >>>>>>> I am interested in 6LowPAN, where RFC4944 fixes the MTU at
1280
> >>>>>>> octets
> >>>>>>>>> Subject: Re: [Roll] Feed-back appreciated for RPL Revision
-09
> >>>>>>>>>> One more time, thanks for your energy and involvement to
> keep
> >>>>>>>>>> us
> >>>>>>>>>>
> >>>>>> on
> >>>>>>
3191371

---

From: Philip Levis <[email-masked]>
Date: Mon, 14 Jun 2010 08:51:52 -0700

On Jun 14, 2010, at 1:42 AM, Daniel Gavelle wrote:

> Dario / Pascal,
> 
> I can see that sending PIO / CO / MTU in DIO messages has some advantages.  Since there is already a mechanism in 6LowPAN-ND for this, I am concerned that allowing these messages to be carried in RPL will result in interoperability issues.
> 
> I suppose the best way forward for the RPL specification is to allow these options as a MAY.  Alliances like Zigbee and IPSO would then ensure interoperability by requiring one method in their stack profile specifications.
> 
> Regarding the MTU, I can see how this is needed for networks using a mixed Ethernet / 6LowPAN MAC, bridged at layer 2.  However, within the 6LowPAN, where the MTU is fixed, routers should be allowed to ignore the option.  Also stack profiles that are aimed at 6LowPAN only MACs should be allowed to exclude the MTU option in their specification.

There are existing mechanisms for MTU discovery; we shouldn't add another one.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Jun 2010 21:32:42 +0200

Phil, 

In the art, MTU within a subnet is supposed to be constant, enforced by
RAs. Anyway PMTU discovery is reactive and has a lot of overhead,
including states in the nodes.

Please think twice,

Pascal

Of
> Philip Levis
> Sent: Monday, June 14, 2010 5:52 PM
> To: [email-masked]
> Cc: ROLL WG
> Subject: Re: [Roll] PIO, CO and MTU options in DIOs
> 
> 
> advantages.  Since there is already a mechanism in 6LowPAN-ND for
this, I
> am concerned that allowing these messages to be carried in RPL will
result in
> interoperability issues.
these
specifications.
should be
> There are existing mechanisms for MTU discovery; we shouldn't add
another
> one.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 18 Jun 2010 19:41:55 +0200

Hi,

On Jun 11, 2010, at 11:24 PM, Dario Tedeschi wrote:

> Hi Daniel
>
> Daniel Gavelle wrote:
>> Dario,
>>
>> In a 6LowPAN network, the routers will need to do 6LowPAN-ND RS/RA  
>> in order to distribute the compression contexts.  I suppose the  
>> context (CO) option from 6LowPAN-ND could also be added to ROLL.   
>> However, I prefer using 6LowPAN-ND for context and prefix  
>> dissemination and ROLL for routing.
> below in a routing protocol. Fair enough, but lets be practical  
> here: RPL provides a robust way of distributing information amongst  
> routers in a LLN network. Why not use it.

We need to be very careful here and take a great care at preserving  
the architecture. We had over the past decade (or even more)  
discussion about using a protocol X in support of a service that would  
typically belong to another protocol or even another layer ! You could  
use RPL for discovery, time synchronization, application overlay, ...  
but it is architecturally not the best thing to do. RPL is for routing  
only.

> I'm not advocating hosts use ROLL, so lets look at your second  
> option where routers need to support two methods for prefix  
> distribution: Even if a network only used 6LoWPAN ND for prefix  
> distribution, routers still need two methods: One-hop RS/RA for  
> router-host prefix distribution and RA+ARBO to deal with router-to- 
> router prefix distribution. In fact if you look at an RA+ARBO  
> message, it looks remarkably similar to a DIO message (where the  
> Version and Address fields in the ARBO can be equated to the Version  
> and DAGID fields in the DIO, respectively). Seems to me, 6LoWPAN ND  
> (with multi-hop) is trying to do the work of a routing protocol. I  
> think "Neighbor Discovery" should be taken a bit more literally in  
> that it is a protocol for discovering your neighbors and not for  
> distributing network configuration (the exception being that one  
>>> information from nearby routers. Both routers and hosts may use NS/ 
>>> NA to perform address-resolution and NUD one hop away only.
>>>
>>> Dario
>>>
>>>>> joining a
>>>>>>>>> -09 to
>>>>>>>>>> keep us