Subject: 6MAN WG Last Call:draft-ietf-6man-rpl-option

From: Brian Haberman <[email-masked]>
Date: Mon, 15 Nov 2010 16:52:53 -0500

All,
     This starts a 6MAN WG Last Call on advancing:

Title     : RPL Option for Carrying RPL Information in
            Data-Plane Datagrams
Author(s) : J. Hui, J. Vasseur
Filename  : draft-ietf-6man-rpl-option-01.txt
Pages     : 16
Date      : 2010-10-22

as a Proposed Standard.  Substantive comments should be sent to the
mailing list and/or the WG co-chairs.  Editorial comments can be
directed to the document authors.  This last call will end on December
6, 2010.

Regards,
Brian & Bob

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 15 Nov 2010 17:16:41 -0800

Support.

-Vishwas

On Mon, Nov 15, 2010 at 1:52 PM, Brian Haberman
<[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 16 Nov 2010 15:58:17 +0100

Hi Brian:

RPL made a pass to clean up the interface with the HbH spec whereby:

- RPL defines the bits and bytes that need to be transported, and when
the information needs to be transported in a packet
- HbH (this spec) defines how the RPL packet information is placed in
and obtained from the packet

Considering that the specs are homogeneous at this time, it is mostly
editorial, but I'd rather that:

1)  section 3 does not redefine O, R, F, Rank and instance.
IMHO, it should simply say that those fields are defined in RPL as part
of the RPL Packet Information.
Eg;

  SenderRank:  16-bit field set to zero by the source and to
         DAGRank(rank) by a router that forwards inside the RPL network.
->
  SenderRank:  16-bit field as defined in [RPL] section 11.2. Loop
Avoidance and Detection

2)  section 4 does not mandate when the HbH is used. RPL does that.

   Routers MUST include a RPL Option when forwarding datagrams that do
   not already contain a RPL Option. If one does not already exist,
   routers MUST use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to
-> 
   RPL controls when and which information is to be placed in a packet.
   If RPL requires to place RPL Packet Information in a packet that does
not
   already contain a RPL Option, the router MUST insert the Option using
   IPv6-in-IPv6 tunneling, as specified in [RFC2473] to

Also, it is unclear when looking at a packet within the RPL domain
whether IP in IP was used or not. A RPL node may use a "transport"
without IP in IP when it generates a packet, whereas a packet coming
from the outside will have IP in IP.
I'd suggest to use a bit out of the 5 spare to indicate tunnel vs.
transport. Based on the bit, we can have a crisper text in section 5,
indicating how to strip the packet from the Option.
- if the bit is on indicating the tunnel mode, then the router will
decapsulate the packet
- if the bit is off indicating the transport mode, then the router
removes the Option and recomputes the upper layer checksum.

Finally, I'd suggest that we make the MUST use IP in IP a SHOULD,
allowing for extreme cases that IP in IP is not used and referencing
draft-hui-6man-rpl-headers for the risks involved.

What do you think?

Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Brian Haberman
> Sent: Monday, November 15, 2010 10:53 PM
> To: IPv6 WG Mailing List
> Cc: Bob Hinden
> Subject: 6MAN WG Last Call:draft-ietf-6man-rpl-option
> 
> All,
directed to
> the document authors.  This last call will end on December 6, 2010.
> 
> Regards,
> Brian & Bob

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 16 Nov 2010 17:54:56 +0100

Hi again Brian:

I'm taking one thing back though. Unless I miss something, there's
probably no need to recomputed any checksum even in transport mode,
since the next header is that of the ULP...

Pascal

Of
> Pascal Thubert (pthubert)
> Sent: Tuesday, November 16, 2010 3:58 PM
> To: Brian Haberman; IPv6 WG Mailing List
> Cc: Bob Hinden
> Subject: RE: 6MAN WG Last Call:draft-ietf-6man-rpl-option
> 
> Hi Brian:
> 
the
> information needs to be transported in a packet
and
> obtained from the packet
> IMHO, it should simply say that those fields are defined in RPL as
part of the
> RPL Packet Information.
Avoidance
> and Detection
>    If RPL requires to place RPL Packet Information in a packet that
does not
> Also, it is unclear when looking at a packet within the RPL domain
whether IP
> in IP was used or not. A RPL node may use a "transport"
from
> the outside will have IP in IP.
indicating
> how to strip the packet from the Option.
decapsulate
> the packet
removes the
> Option and recomputes the upper layer checksum.
> 
allowing
> for extreme cases that IP in IP is not used and referencing
draft-hui-6man-
> rpl-headers for the risks involved.
> 
> What do you think?
> 
> Pascal