Subject: Re: [Roll] [roll] #41: Adding the SLLA and MTU options in the RPL spec ?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 6 Jun 2010 18:11:57 +0200

Dear WG:

Just as a reminder, we have a timer running on this decision. 
The current light consensus is to add SLLA and MTU options in DIO in RPL 09.
If someone opposes please speak up!

Pascal

> -----Original Message-----
> From: roll issue tracker [mailto:[email-masked]]
> Sent: Sunday, June 06, 2010 9:12 AM
> To: Pascal Thubert (pthubert); [email-masked]
> Cc: [email-masked]
> Subject: Re: [roll] #41: Adding the SLLA and MTU options in the RPL spec ?
> 
> #41: Adding the SLLA and MTU options in the RPL spec ?
> --------------------------------+-------------------------------------------
>  Reporter:  jpv@…               |        Owner:  pthubert@…
>      Type:  defect              |       Status:  closed
>  Priority:  minor               |    Milestone:
> Component:  rpl                 |      Version:
>  Severity:  Active WG Document  |   Resolution:  fixed
>  Keywords:                      |
> --------------------------------+-------------------------------------------
> Changes (by jpv@…):
> 
>   * status:  new => closed
>   * resolution:  => fixed
> 
> 
> Comment:
> 
>  This is a duplicate
> 
> --
> Ticket URL: <http://svn.tools.ietf.org/wg/roll/trac/ticket/41#comment:1>
> roll <http://tools.ietf.org/wg/roll/>

---

From: Philip Levis <[email-masked]>
Date: Mon, 7 Jun 2010 09:55:02 -0700

> If someone opposes please speak up!

Can you clearly explain what problem they solve?

We keep on cramming in more options and features; feedback from implementers has consistently been to make the protocol simpler.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Jun 2010 15:50:12 +0200

Hi Phil:

SLLA would be placed in (some) DIO, DAO and DIS. The goal would be to
provide a link layer address for the sender.

Today, the flow has to be

Parent                                              child

               DIO (to mcast)
---------------------------------------->
                  NS with SLLA opt
<----------------------------------------
               NA with TLLA opt
---------------------------------------->
                  DAO (to mac in TLLA)
<----------------------------------------

If we allow the option we get:

Parent                                              child

               DIO with SLLA opt
---------------------------------------->
                     DAO with SLLA opt 
<----------------------------------------

MTU would enable the root to force a consistent MTU over the LLN. If the
LLN is a stub, all packets going up would be below that MTU. The root
would still have to support PMTUD for packets coming from the outside.
Finally, if that MTU is 1280 like 6LoWPAN does, then the nodes in eth
RPL network do not have to care about PMTUD at all. Alternate would be
do support PMTUD and related costs within the LLN (RFC 1981).

Finally, we'll have to decide how we handle the sequence numbers (in
particular loss of sync),  whether we detect address duplication, and
whether we clean up routes from the top in case of an error.

Pascal

> From: Philip Levis [mailto:[email-masked]]
> Sent: Monday, June 07, 2010 6:55 PM
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Roll] [roll] #41: Adding the SLLA and MTU options in the
RPL
> spec ?
> > The current light consensus is to add SLLA and MTU options in DIO in
RPL
> 09.
> We keep on cramming in more options and features; feedback from
> implementers has consistently been to make the protocol simpler.
> 
> Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 08 Jun 2010 23:07:01 +0200

> provide a link layer address for the sender.

Why not using these options where they are already used?  That would 
save effort.

Alex

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Philip Levis <[email-masked]>
Date: Tue, 8 Jun 2010 17:24:52 -0700

> Today, the flow has to be

I guess my question is whether this matters. Nodes still have to  
handle NS and NA; this option is breaking the layer2/layer3 boundary  
to optimize a packet exchange. It's not clear that the optimization  
makes a real difference. Remember, there is a cost. I'd much rather  
spend effort optimizing bottlenecks that are discovered in  
implementations running in real environments (of which there will be  
some, I'm sure). The protocol spec keeps on growing with new ideas  
and options. Right now, the packet formats alone are over 20 pages  
(including security messages). When does it stop?

> do support PMTUD and related costs within the LLN (RFC 1981).

Can you give more details on how the MTU option works?

Phil

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 09 Jun 2010 07:46:45 -0400

> From: Philip Levis <[email-masked]>
> Date: Tue, 8 Jun 2010 17:24:52 -0700
> 

I agree with Phil on this one.  Adding an optimization
like this to the base spec just doesn't make sense.

                                  -Richard Kelsey