Subject: Re: [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Oct 2010 10:55:12 -0400

Thanks, Margaret, for your thorough and helpful review.

- Ralph

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 21 Oct 2010 10:48:17 -0400

Hi Ralph, Jari and others,

As a member of the IP directorate, I was encouraged to review
draft-ietf-roll-rpl-12.txt.

In general, I support the RPL effort, and I think that the IETF should
publish the RPL protocol as a standards track RFC.  This protocol has
already been adopted by a couple of industry standards bodies for
inclusion in their "profiles", and it is likely to be widely deployed
in the future.

However, I have several concerns about approving version -12 of this
specification, at this time.  Here are my concerns, roughly in  
descending
order of importance:

(0) The specification of RPL is, IMO, substantially incomplete without
     the corresponding specifications from the 6man group:
     draft-ietf-6man-rpl-option-00.txt and
     draft-ietf-6man-rpl-routing-header-00.  The 6man-rpl-option draft
     has only recently been adopted by the 6man WG (July 2010), and
     both 6mand drafts still need more work before they will be ready
     for publication, IMO.  Given that the RPL draft normatively
     references the 6man drafts, RPL cannot be published as an RFC
     until the 6man drafts are also approved for publication as RFCs.
     Since the three drafts are very tightly coupled, I don't think it
     makes sense to approve the RPL specification now (thus making it
     difficult to change) before the 6man drafts are also ready for
     publication.

(1) IMO, there are a couple of important technical issues with this
     specification that should be addressed before it is approved.

     (a) Section 11.2.2.1 of the document current says:

             "A RPL router that forwards a packet in the RPL network
             MUST check if the packet includes an IPv6 Hop-by-Hop RPL
             Option, and that the RPL Option contains RPL Packet
             Information (Figure 32).  If not, then the RPL router MUST
             insert a RPL Option with RPL Packet Information as
             specified in [I-D.ietf-6man-rpl-option].  If the router is
             an ingress router that injects the packet into the RPL
             network, the router MUST set the RPLInstanceID field in
             the RPL Packet Information.  The details of how that
             router determines the mapping to a RPLInstanceID are out
             of scope for this specification and left to future
             specification.

             "A router that forwards a packet to outside the RPL
             network MUST remove the RPL Option as specified in
             [I-D.ietf-6man-rpl-option]."

         There are at least two significant issues with this
         description:

             - When the RPL header is added to the packet, there is no
               guarantee that there will already be a hop-by-hop
               options header in the packet.  If not, it will need to
               be inserted, too.  Depending on how this is done, it
               could cause the next header field to change in the IPv6
               header, thus invalidating the pseudo-header checksum on
               packets that are received from outside of the RPL
               instance and are destined to somewhere inside the RPL
               instance.
             - Removing an option from a packet may, depending on how
               it is done, have similar issues.  Could this result in
               sending an empty hop-by-hop option header?  Or would
               the hop-by-hop header be removed if it is now empty?
             - Inserting a header into a packet increases the size
               of the packet, and could result in MTU/fragmentation
               issues.

             I realize that the 6man draft talks about tunneling these
             packets, which would resolve the checksum issues listed
             above.  The MTU/fragmentation issues still apply, though.

             The 6man draft currently addresses the MTU issues by
             saying that you should use a link with a high-enough MTU
             but there are issues with that, as well: (1) 6lowpan,
             which is the only link type I know of that RPL has been
             run over to date, has an MTU of 1280, not 1280+++ as
             required by the 6lowpan spec, and (2) there is no
             explanation of what RPL routers should do if adding the
             RPL header results in a packet that won't fit --
             presumably send a "packet too big" error, but with what
             MTU size indicated?

             At the very least, this section of the RPL draft is
             incompatible with the 6man draft.  Since these
             options are essential to RPL operation, this is one
             of the reasons I don't think we should approve this
             document before the 6man draft is finished -- because
             we've left some very hard problems for the 6man spec
             to solve, and I'm not convinced they can be solved
             without changes to the RPL spec.

     (b) The draft indicates that a RPL node can forward a packet
         upwards within a particular DAG, by sending it to a lower- 
ranked
         node within that DAG.  It also indicates that a particular RPL
         node may be in more than one DAG.  The RPL option doesn't
         contain a DAG ID...  So, I am wondering:

         So, if RPL Node A, who happens to be in two DAGs (DAG 1 and
         DAG 2) wants to forward a packet out on to the Internet using
         the border router for DAG 1, but it can't reach that border
         router directly, it forwards the packet to a lower-ranked node
         in DAG 1, right?  Let's call this node Node B.

         What if Node B is _also_ in DAG 1 and DAG 2?  How does Node B
         know that the packet should be forwarded in DAG 1 and not
         DAG 2?

(2) It is my understanding that the Routing area requires multiple
     interoperable implementations of a specification in order to
     publish the specification, and I don't think that RPL currently
     meets that requirement.

     RPL has two major, non-interoperable operating modes -- storing
     node and non-storing node, and a lot of functionality that is only
     applicable in cases where the RPL network is connected to a
     non-RPL network, or there is more than one active DAG within a
     single RPL instance.

     While there are two groups (that I am aware of) who have begun
     interoperability testing of RPL, it is my understanding that one
     of those groups last tested version -06 or -07 of the RPL spec,
     which was quite different from the current version, and that they
     only tested storing mode.  The other group has only tested
     non-storing mode, and has only tested in a single-DAG environment,
     with no routing outside the RPL instance.  This second group just
     started testing the -12 version earlier this month, and has not
     fully tested even the non-storing mode, single DAG
     functionality. Also, to my knowledge, no information about the
     coverage or results of this testing is publicly available.

(3) There are also a couple of minor technical issues with the  
specification
     that should be addressed before it is published.

     (a) The description of the Pad1 option (section 6.7.2) says both
         that it is used for inserting one or two octets or padding,
         and that if more than octet of padding is needed, the PadN
         option should be used.

     (b) The description of the RPL option is unclear to me.  In
         section 6.7.1, Figure 19 shows the "RPL Option Generic
         Format".  There are then several types of RPL options
         describe.  However, in section 11.2, Figure 32, there is a RPL
         option defined that doesn't appear to contain a type.
         Furthermore, there is a RPL option defined
         draft-ietf-6man-rpl-option that shows an option with a type
         (RPL) length, and a set of sub-TLVs.  The option in Figure 32
         doesn't have a TLV format, and it isn't clear to me whether a
         single RPL option (as decribed in the 6man draft) can contain
         many of the RPL options described in the RPL spec, or only
         one.  Am I missing something here?

(4) I also wonder why it is necessary to list 10 authors on this
     specification.  I haven't been able to find any justification for
     why this document should be an exception to the "5 authors or
     less" rule.  In similar cases in the past, WGs have chosen to list
     no more than a few people as editors on the first page, and to
     include a list of authors later in the draft in an "Authors" or
     "Contributors" section, and I think that should probably be done
     in this case.

Thanks,
Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 23 Oct 2010 08:54:14 -0400

Hi Jari,

You're welcome.

Please let me know when the problems I discussed are fixed.  Some  
parts of this draft need some substantial changes, and after they are  
made, I would like to make sure that the solution they come up with  
really works WRT MTU/fragmentation issues, checksum-related issues,  
and fitting into the current IP conceptual model well enough not to  
violate any basic principles.  It isn't possible to do a detailed  
review at this point, because of the state of the specification now  
(various conflicting statements between multiple documents).

I think someone (and by that I guess I am volunteering myself) should  
also review the RPL and 6lowpan ND stuff as a whole and understand how  
it relates to regular ND and whether it will work.  I am not sure that  
the things that RPL says about 6lowpan ND are even true.  For  
instance, I don't think 6lowpan ND provides neighbor unreachability  
detection, but I could be wrong...

There are some ways in which 6lowpan/RPL nodes will be quite different  
than regular IPv6 nodes, and I think we need to make sure that those  
differences are both sound technically, and justified by the  
environmental expectations.  I worry that some of the differences may  
unnecessary.

Thanks,
Margaret

On Oct 22, 2010, at 2:05 AM, Jari Arkko wrote:

> Thanks for your review, Margaret.
>
> Jari
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Oct 2010 09:05:49 +0300

Jari

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Oct 2010 08:14:23 +0200

Hi Margaret,

I also would like to thank you for your thoughtful review; that was very useful.

Picking up on the interaction between 6LoWPAN-ND and RPL:

On Oct 23, 2010, at 14:54, Margaret Wasserman wrote:

> I think someone (and by that I guess I am volunteering myself) should also review the RPL and 6lowpan ND stuff as a whole and understand how it relates to regular ND and whether it will work.  

While I think we are reasonably covered with respect to the relationship between 4861 and 6LoWPAN-ND, the interaction between the latter and RPL is indeed interesting.

> For instance, I don't think 6lowpan ND provides neighbor unreachability detection, but I could be wrong...

Actually, the proper support for NUD was one of the considerations that went into 6LoWPAN-ND's makeover early this year.  But still, the mutual expectations need to be checked.  In particular, RPL appears to assume hosts take part in the routing protocol, and 6LoWPAN-ND supports hosts that don't.  I'd be certainly interested in an effort to look at the entire system of protocols between 6LoWPAN, 6man, and RPL.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Oct 2010 08:30:59 +0200

On Oct 21, 2010, at 16:48, Margaret Wasserman wrote:
[in her RPL review about RPL's various forms of encapsulation:]

> (1) 6lowpan,
>            required by the 6lowpan spec,

(I think you meant 6man/RPL spec at the end.)

Indeed.

However, the number 1280 is somewhat arbitrary for 6LoWPAN, as we have to piece L3 packets together out of ~100 byte L2 fragments anyway.  The actual adaptation layer format is fine with any MTU up to 2047; we just chose the lowest MTU possible*) in IPv6 as a concession for constrained nodes (and 1280 still is quite heavy for some of them).

So it is not unconceivable that 6LoWPAN could help RPL routers by adding a mode that extends the MTU somewhat.
Of course, the details of such an extension would need to be defined, preferably in conjunction with the rest of the 6man/RPL stack.

Gruesse, Carsten

*) The assumption was that, as a stub network, a 6LoWPAN would not need to support tunneling.
That assumption may have been wrong.

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 24 Oct 2010 22:01:09 -0400

> (I think you meant 6man/RPL spec at the end.)

Yes, I did.  The 6man/RPL spec says it will only work on networks that  
have an MTO of 1280+40-something+128+something unspecified.  And,  
6lowpan currently specifies an MTU of 1280 (which is fine).

> However, the number 1280 is somewhat arbitrary for 6LoWPAN, as we  
> have to piece L3 packets together out of ~100 byte L2 fragments  
> anyway.  The actual adaptation layer format is fine with any MTU up  
> to 2047; we just chose the lowest MTU possible*) in IPv6 as a  
> concession for constrained nodes (and 1280 still is quite heavy for  
> some of them).

Even if the number _were_ 2047, you would still need to do something  
special with the MTU to make this work.  For instance the tunnel  
encapsulator (in this case the border router) would want to present a  
lower MTU (presumably 1280) for this network on interfaces outside the  
RPL instance, while presenting the full size MTU on internal  
interfaces.  This isn't a huge technical problem to resolve, but the  
expected behaviour would need to be properly specified, IMO.

> So it is not unconceivable that 6LoWPAN could help RPL routers by  
> adding a mode that extends the MTU somewhat.
> Of course, the details of such an extension would need to be  
> defined, preferably in conjunction with the rest of the 6man/RPL  
> stack.

Exactly.

Thanks for the feedback!
Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 24 Oct 2010 22:05:28 -0400

On Oct 24, 2010, at 2:14 AM, Carsten Bormann wrote:
>> I think someone (and by that I guess I am volunteering myself)  
>> should also review the RPL and 6lowpan ND stuff as a whole and  
>> understand how it relates to regular ND and whether it will work.
>
> While I think we are reasonably covered with respect to the  
> relationship between 4861 and 6LoWPAN-ND, the interaction between  
> the latter and RPL is indeed interesting.

I'm not saying that I know of any specific problems in this area, but  
I'd like to make sure we do a good cross-document review of ND will  
work in the RPL/6lowpan environment, in addition to how RPL itself  
works, before the RPL documents are published as RFCs.  Given their  
interdependence, it probably makes sense to review the model now and  
make sure we understand how it will work before approving any of the  
documents.

>
>> For instance, I don't think 6lowpan ND provides neighbor  
>> unreachability detection, but I could be wrong...
>
> Actually, the proper support for NUD was one of the considerations  
> that went into 6LoWPAN-ND's makeover early this year.  But still,  
> the mutual expectations need to be checked.  In particular, RPL  
> appears to assume hosts take part in the routing protocol, and  
> 6LoWPAN-ND supports hosts that don't.  I'd be certainly interested  
> in an effort to look at the entire system of protocols between  
> 6LoWPAN, 6man, and RPL.

Thanks for the correction.  There have been enough changes in this  
area (6lowpan and RPL) over he past year that, even though I am  
working on a product that implements these specs, I have had trouble  
keeping up.

Margaret

---

From: JP Vasseur <[email-masked]>
Date: Sun, 24 Oct 2010 23:31:12 -0700

On Oct 24, 2010, at 7:05 PM, Margaret Wasserman wrote:

> I'm not saying that I know of any specific problems in this area, but I'd like to make sure we do a good cross-document review of ND will work in the RPL/6lowpan environment, in addition to how RPL itself works, before the RPL documents are published as RFCs.  Given their interdependence,

Let me just make sure that this point is clear though. There is no dependence between 6lowpan and RPL. It turns out
that several 6lowpan networks (in particular HC) will use of RPL but there are also several other networks without 
6lowpan at all, and we need to make sure that this is no dependency at all.

> it probably makes sense to review the model now and make sure we understand how it will work before approving any of the documents.
> 
>> 
> Thanks for the correction.  There have been enough changes in this area (6lowpan and RPL) over he past year that, even though I am working on a product that implements these specs, I have had trouble keeping up.
> 
> Margaret
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Oct 2010 12:12:02 -0400

On Oct 25, 2010, at 2:31 AM, JP Vasseur wrote:
> Let me just make sure that this point is clear though. There is no  
> dependence between 6lowpan and RPL. It turns out
> that several 6lowpan networks (in particular HC) will use of RPL but  
> there are also several other networks without

Good point.

We do need to make sure, though, that RPLs use of ND is consistent  
both with "generic" IPv6 ND and 6lowpan ND, though, right?

In my opinion, we should also do a full review of the RPL drafts and  
the 2 or 3 related 6man drafts, once they have been updated to be more  
consistent, to make sure that the whole system is properly specified  
and will function properly (as far as we can tell).

BTW, I am not trying/expecting to hold up the publication of RPL as an  
RFC by suggesting that we do a review of the full set of circularly  
referenced documents (RPL and the 2 or 3 related 6man drafts) for  
consistency/correctness before the IESG approves any of them.  RPL  
can't be published as an RFC until all of the documents it normatively  
references are approved for publication, anyway.

Margaret

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 25 Oct 2010 23:45:41 -0700

Hi Margaret,

Thanks for the comments. Here are a few things regarding 6lowpan-nd NUD.

> 6lowpan ND provides neighbor unreachability detection, but I could be
> wrong...
[SC>] 
     6lowpan-nd  hosts do perform NUD through registration and refreshing
the registration. NUD can be implicitly performed by data communication
using upper layer protocols as suggested in rfc 4861. And when a node wakes
up from sleep, it does NUD in order to make sure its default router is still
reachable.

The routers (6LR and 6LBR) also perform NUD on hosts for unreachability
detection. [ section 6 of
http://www.ietf.org/id/draft-ietf-6lowpan-nd-14.txt]

> There are some ways in which 6lowpan/RPL nodes will be quite different
than regular IPv6 nodes
[SC>] In regular IPv6, there is a router and a host - in 6lowpan-nd, there
is a third entity which is 6LR.
[SC>] One major difference between  6lowpan and RPL LLN are that RPL assumes
that all nodes are routers/forwarders while 6lowpan-nd assumes the network
is composed of hosts and routers. 6lowpan-nd assumes that the 6LRs first
come up as hosts during the startup and are capable of registering
themselves with their neighboring routers and autoconfiguring addresses
before turning themselves into routers when a routing protocol is run on
them. 
6lowpan-nd also expects that the 6LR will inject neighbor
attachment/detachment information into the routing protocol. Similarly,
it assumes that the routing protocol is capable of deleting an NCE should it
finds out that one of its registered node has moved away without
de-registering.
Also 6lowpan-nd is not dependent on any particular routing protocol running
on the router.

Hope it clarifies a little bit.  We are working on some more
cleanup/polishing on the ND document for clarity.

-Samita

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Oct 2010 14:07:56 -0400

Hi Samita,

> cleanup/polishing on the ND document for clarity.

Thanks for the explanation.  It definitely helped.

I'm still trying to figure out a model in my head for how all of these  
things fit together...

Margaret

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Oct 2010 08:35:00 +0200

Le 26/10/2010 08:45, Samita Chakrabarti a écrit :
[discussion around RPL and 6LoWPAN]
> [SC>] One major difference between  6lowpan and RPL LLN are that RPL
> assumes that all nodes are routers/forwarders while 6lowpan-nd
> assumes the network is composed of hosts and routers.

I have a humble opinion on this topic.

In RPL, the assumption that a node is an IP router/forwarder with a
single interface and a unique subnet prefix - is very hard to grasp
conceptually to me.  I am afraid there may be a big misunderstanding and
may stem from a misunderstanding of the underlying link layer.  One such
misunderstanding is the common assumption that a single-interfaced
machine forwarding a packet will not disturb the originator.  This may
lead to trying to solve imaginary link layer problems with IP forwarding.

This problem is not new.  I have seen it with 802.11s mesh ancestors to
run RIP at link layer.

This one-interface-forwarder work may signify inspiration to some
one-interface link layer designs, but it is pointless to IP.

Finally, only if we talk multiple interfaces on a router/forwarder,
eventually of different types, and multiple subnet prefixes, then the
problem becomes relevant to IP routing.  Unfortunately RPL makes no
distinction between these two situations.

IMHO,

Alex

> 6lowpan-nd assumes that the 6LRs first come up as hosts during the
> startup and are capable of registering themselves with their
> neighboring routers and autoconfiguring addresses before turning
> themselves into routers when a routing protocol is run on them.
> attachment/detachment information into the routing protocol.
> Similarly, it assumes that the routing protocol is capable of
> deleting an NCE should it finds out that one of its registered node
> has moved away without de-registering. Also 6lowpan-nd is not
> dependent on any particular routing protocol running on the router.
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Oct 2010 10:44:38 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    Alexandru> In RPL, the assumption that a node is an IP router/forwarder with a
    Alexandru> single interface and a unique subnet prefix - is very hard to grasp
    Alexandru> conceptually to me.  I am afraid there may be a big misunderstanding and
    Alexandru> may stem from a misunderstanding of the underlying link layer.  One such
    Alexandru> misunderstanding is the common assumption that a single-interfaced
    Alexandru> machine forwarding a packet will not disturb the originator.  This may
    Alexandru> lead to trying to solve imaginary link layer problems
    Alexandru> with IP forwarding.

Are you saying that administrative types might try to solve problems
using their wired-LAN experience of a single broadcast domain?

RPL builds what is essentially a kind of NBMA network, only it has
limited broadcasts.  Maybe the wireless experts on the list can tell me
the technical term for a broadcast media where not all nodes can hear
all others... maybe the word is "radio" :-)

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.