Re: [Roll] [6tisch] Thomas' remarks on draft-robles-roll-useofrplinfo-00

Ines Robles <mariainesrobles@googlemail.com> Sat, 04 July 2015 06:44 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57251A8871 for <roll@ietfa.amsl.com>; Fri, 3 Jul 2015 23:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.923
X-Spam-Level:
X-Spam-Status: No, score=0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19SJAlNacCAC for <roll@ietfa.amsl.com>; Fri, 3 Jul 2015 23:44:26 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9981A886F for <roll@ietf.org>; Fri, 3 Jul 2015 23:44:25 -0700 (PDT)
Received: by laar3 with SMTP id r3so104477362laa.0 for <roll@ietf.org>; Fri, 03 Jul 2015 23:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OZX9My4IHDkPN71k2u2c3/ePfX2WGrcImvXdbB1bxAg=; b=r1Q+vqUIUikUQQUWUIl7JPikdJpGC7QrAacgugkf9p7xjdw4rGU2QdQuS6O2zncDLS RUgp8JUogfgAI3u1PNw9i+x0HrAfd90FV+Rzqvph/JYfwlT0MCW7ogpFFtFgCvmaDew2 /e+2HGz6CJlWSdEFVYhit5LHc/Od2gRYun6uyzokE7GODUmC4++mgH3fpJO/UTTOvx7T S87JQGrBCVqrhKJ5lELzhw30fc/A5e+AFLDVClCZOZzwpvW5T9kJ8QyxKZrsiSQl24QW xjhnMdWKFAqQPzZY/UYJXXtozVOPqf2kckM3B+A+oDH1XLEN+QV1F7WVH9nisag+4fZX K0LA==
MIME-Version: 1.0
X-Received: by 10.112.222.133 with SMTP id qm5mr39194250lbc.86.1435992263550; Fri, 03 Jul 2015 23:44:23 -0700 (PDT)
Received: by 10.25.208.70 with HTTP; Fri, 3 Jul 2015 23:44:23 -0700 (PDT)
Received: by 10.25.208.70 with HTTP; Fri, 3 Jul 2015 23:44:23 -0700 (PDT)
In-Reply-To: <CAMsDxWT66cPm4CxOyU5Cth2qgka66+NBe7Eas92-T86qubrbSw@mail.gmail.com>
References: <CADJ9OA_bRQv8rkkgwK1Q8pQ1=pB_Cd8iJ-Dk72z4uRwsJO-T+Q@mail.gmail.com> <CADrU+d+xV0doeAdYmHnLh-iAkq9_tMg4y_nB=gUkHu5baPD2Dw@mail.gmail.com> <CAMsDxWT66cPm4CxOyU5Cth2qgka66+NBe7Eas92-T86qubrbSw@mail.gmail.com>
Date: Sat, 4 Jul 2015 09:44:23 +0300
Message-ID: <CAP+sJUfVh5rXv-WV0biQhs2BckmxhziZszYWBV+CAn=O_XwKiQ@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
To: roll <roll@ietf.org>, Xavi Vilajosana <xvilajosana@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary=001a11346db0c4ed20051a0700e2
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/vabpP0jeM3-6wv9yBA8-2KotC2Y>
Subject: Re: [Roll] [6tisch] Thomas' remarks on draft-robles-roll-useofrplinfo-00
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Jul 2015 06:44:32 -0000

Ok, Thanks for the suggestions Xavi :-). We will work on that.
Cheers
On 4 Jul 2015 06:58, "Xavier Vilajosana" <xvilajosana@eecs.berkeley.edu>
wrote:

> Dear Ines, Michael,
>
> It would be also very good to have several examples (drawings) detailing
> how Extension headers are placed in the outer IPv6 header and how this
> extension headers coexist (or are concatenated) with other extension
> headers (non-RPL) such as IPv6 Fragment Header , IPv6 Hop-by-Hop Options
> Header, IPv6 Header --Inner-- (EID 7), etc.. The drawings can also show
> how a sequence of extension headers is followed by a transport layer
> protocol such as UDP and if this affects HC. The examples can be
> complemented with the byte streams of that headers as clarification
> examples or to verify compliance.
>
> It would also be good to comment about header compression and all the
> possibilities we have or at least point to the RFCs that detail how
> extension headers are compressed and when compression cannot be applied or
> any other consideration.
>
> I think this draft is very valuable for most of us. Thanks for the work!
>
> regards,
> Xavi
>
> 2015-07-03 18:55 GMT+02:00 Robert Cragie <robert.cragie@gridmerge.com>om>:
>
>> Hi all,
>>
>> Happy to help out - I will take a closer look next week.
>>
>> A couple of points on first cursory read:
>>
>> 1) The control plane and data plane concepts should be distinct. By all
>> means talk about control plane (i.e. RPL messages) and how they are
>> formatted but keep this distinct from the structure of data plane packets
>> used where RPL is used for routing. It is the data plane where IP-in-IP,
>> RPL HbH and source routing headers are used and where the focus of the
>> document should really be.
>> 2) In the data plane, there are potentially two sorts of leaf node to
>> consider: a) RPL-aware and b) not RPL-aware. This is important as it
>> determines whether IP-in-IP is needed between nodes in a 6LoWPAN.
>>
>> Robert
>>
>> On 3 July 2015 at 14:52, Thomas Watteyne <watteyne@eecs.berkeley.edu>
>> wrote:
>>
>>> Ines, Michael,
>>> Please find my remarks about draft-robles-roll-useofrplinfo-00 below.
>>> Thomas
>>>
>>> ----
>>>
>>> TW> overall comments
>>> TW> - this is a super important informational draft, which
>>> TW>   clears up a lot of questions
>>> TW> - I think it would be very useful to have more example
>>> TW>   packets. We are building such information for the upcoming 6TiSCH
>>> TW>   plugtest, so I can help there.
>>> TW> - After this is done I would recommend to ask explicitly for
>>> TW>   reviewers. Robert Cragie should be
>>> TW>   on the list of people to ask; he has provided very useful info
>>> TW>   during our discussions.
>>>
>>>
>>> ROLL Working Group                                           M.I. Robles
>>> Internet-Draft                                                  Ericsson
>>> Intended status: Informational                             M. Richardson
>>> Expires: December 29, 2015                                           SSW
>>>                                                            June 27, 2015
>>>
>>>
>>>               When to use RFC 6553, 6554 and IPv6-in-IPv6
>>>                    draft-robles-roll-useofrplinfo-00
>>>
>>> Abstract
>>>
>>>    This document states different cases where RFC 6553, RFC 6554 and
>>>    IPv6-in-IPv6 encapsulation is required to set the bases to help
>>>    defining the compression of RPL routing information in LLN
>>>    environments.
>>>
>>> Status of This Memo
>>>
>>>    This Internet-Draft is submitted in full conformance with the
>>>    provisions of BCP 78 and BCP 79.
>>>
>>>    Internet-Drafts are working documents of the Internet Engineering
>>>    Task Force (IETF).  Note that other groups may also distribute
>>>    working documents as Internet-Drafts.  The list of current Internet-
>>>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>>>
>>>    Internet-Drafts are draft documents valid for a maximum of six months
>>>    and may be updated, replaced, or obsoleted by other documents at any
>>>    time.  It is inappropriate to use Internet-Drafts as reference
>>>    material or to cite them other than as "work in progress."
>>>
>>>    This Internet-Draft will expire on December 29, 2015.
>>>
>>> Copyright Notice
>>>
>>>    Copyright (c) 2015 IETF Trust and the persons identified as the
>>>    document authors.  All rights reserved.
>>>
>>>    This document is subject to BCP 78 and the IETF Trust's Legal
>>>    Provisions Relating to IETF Documents
>>>    (http://trustee.ietf.org/license-info) in effect on the date of
>>>    publication of this document.  Please review these documents
>>>    carefully, as they describe your rights and restrictions with respect
>>>    to this document.  Code Components extracted from this document must
>>>    include Simplified BSD License text as described in Section 4.e of
>>>    the Trust Legal Provisions and are provided without warranty as
>>>    described in the Simplified BSD License.
>>>
>>>
>>>
>>> Robles & Richardson    Expires December 29, 2015                [Page 1]
>>> Internet-Draft                 Useof6553                       June 2015
>>>
>>>
>>> Table of Contents
>>>
>>>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>>>    2.  Terminology and Requirements Language . . . . . . . . . . . .   2
>>>    3.  Sample/reference topology . . . . . . . . . . . . . . . . . .   3
>>>    4.  Example flow from leaf to root  . . . . . . . . . . . . . . .   4
>>>      4.1.  Non-storing . . . . . . . . . . . . . . . . . . . . . . .   5
>>>      4.2.  Storing . . . . . . . . . . . . . . . . . . . . . . . . .   5
>>>    5.  Example flow from leaf to Internet  . . . . . . . . . . . . .   6
>>>      5.1.  Non-storing . . . . . . . . . . . . . . . . . . . . . . .   6
>>>      5.2.  Storing . . . . . . . . . . . . . . . . . . . . . . . . .   7
>>>    6.  Example flow from leaf to leaf  . . . . . . . . . . . . . . .   7
>>>      6.1.  Traditional storing . . . . . . . . . . . . . . . . . . .   7
>>>      6.2.  Traditional non-storing . . . . . . . . . . . . . . . . .   7
>>>      6.3.  P2P non-storing . . . . . . . . . . . . . . . . . . . . .   7
>>>    7.  Example flow from Internet to leaf  . . . . . . . . . . . . .   7
>>>      7.1.  Storing . . . . . . . . . . . . . . . . . . . . . . . . .   7
>>>      7.2.  Non-storing . . . . . . . . . . . . . . . . . . . . . . .   7
>>>    8.  Example flow from root to leaf  . . . . . . . . . . . . . . .   7
>>>      8.1.  Storing . . . . . . . . . . . . . . . . . . . . . . . . .   7
>>>      8.2.  Non-storing . . . . . . . . . . . . . . . . . . . . . . .   7
>>>    9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
>>>    10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
>>>    11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
>>>    12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
>>>      12.1.  Normative References . . . . . . . . . . . . . . . . . .   8
>>>      12.2.  Informative References . . . . . . . . . . . . . . . . .   8
>>>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
>>>
>>>
>>> 1.  Introduction
>>>
>>>    RPL [RFC6550] defines RPL Option to transmit routing information.
>>>    RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop Option RPL
>>>    Information,such as information to avoid and detect loops.  RFC 6554
>>>    [RFC6554] defines the use of Extension header for Source Routing.
>>> TW> this is a bit confusing to me. AFAICT:
>>> TW> - RFC6550 defines the RPL routing protocol
>>> TW> - RFC6553 defines the "RPL option", carried within the IPv6
>>> Hop-by-Hop
>>> TW>   header to  quickly identify inconsistencies in the routing topology
>>> TW> - RFC6554 defines the "RPL Source Route Header", an IPv6 Extension
>>>       Header to deliver datagrams within a RPL routing domain
>>>
>>>    Several discussions in
>>> TW> the
>>>    ROLL/6lo/6tisch
>>> TW> 6tisch -> 6TiSCH
>>>    Mailing Lists took place
>>>    focusing in the definition
>>> TW> of
>>>    how to compress RPL Information in
>>>    constrained environment.  ROLL Virtual Interim Meeting (02-2015)
>>>    concluded that there is a need to define how to use RFC 6553, RFC6554
>>> TW> you have to decide whether you use "RFC 123" or "RFC123". I would
>>> TW> recommend you replace this by a hyperlink
>>>    and tunneling (IP-in-IP)
>>> TW> I would say "and IP-in-IP encapsulation"
>>>    to be able to set the correct environment
>>>    for compression.
>>>
>>> 2.  Terminology and Requirements Language
>>>
>>> TW> you're actually not using any of this language in the draft.
>>> TW> if you keep it that way, and since the draft is informational
>>> TW> I would recommend to remove this section
>>>
>>>
>>>
>>>
>>> Robles & Richardson    Expires December 29, 2015                [Page 2]
>>> Internet-Draft                 Useof6553                       June 2015
>>>
>>>
>>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>>    document are to be interpreted as described in RFC 2119 [RFC2119].
>>>
>>>    Terminology defined in [RFC7102]
>>>
>>> 3.  Sample/reference topology
>>>
>>>    In a typical topology we found
>>> TW> "we found" reads strange. What about "A RPL network is composed of
>>> TW> ...[6LR,6LBR]... logically organized in a DODAG structure".
>>>    6LBR (6LoWPAN Border Router), 6lR
>>> TW> 6LR
>>>    (6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf connected in a DODAG
>>>    (Destination Oriented Directed Acyclic Graph).  Between these
>>>    entities messages such as DIS, DIO and DAO are transmitted.  RPL
>>>    defines the RPL Control message as an ICMPv6 information message with
>>>    a Type of 155.
>>> TW> RPL defines the RPL Control message, a new ICMPv6 message with
>>> TW> Type 155. DIS, DIO and DAO messages are all RPL Control messages
>>> TW> but with different Code values.
>>>    RPL supports two modes of Downward traffic: Storing,
>>>    it is fully stateful or Non-Storing it is fully source routed.  Any
>>>    given RPL Instance is either storing or non-storing.
>>> TW> please specify that a RPL Instance is either fully storing or fully
>>> TW> non-storing, i.e. a RPL Instance with a combination of storing and
>>> TW> non-storing nodes is not supported
>>>
>>>                              +--------------+
>>>                              | Upper Layers |
>>>                              |              |
>>>                              +--------------+
>>>                              |   RPL        |
>>>                              |              |
>>>                              +--------------+
>>>                              |   ICMPv6     |
>>>                              |              |
>>>                              +--------------+
>>>                              |   IPv6       |
>>>                              |              |
>>>                              +--------------+
>>>                              |   6LoWPAN    |
>>>                              |              |
>>>                              +--------------+
>>>                              |   PHY-MAC    |
>>>                              |              |
>>>                              +--------------+
>>>
>>>
>>>
>>>                             Figure 1: RPL Stack
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Robles & Richardson    Expires December 29, 2015                [Page 3]
>>> Internet-Draft                 Useof6553                       June 2015
>>>
>>>
>>>                                           +---------+
>>>                                       +---+Internet |
>>>                                       |   +---------+
>>>                                       |
>>>                                  +----+--+
>>>                                  |DODAG  |
>>>                        +---------+Root   +----------+
>>>                        |         |6LBR   |          |
>>>                        |         +----+--+          |
>>>                        |              |             |
>>>                        |              |             |
>>>                        |              |             |
>>>                  +-----+-+         +--+---+      +--+---+
>>>                  |6LR    |         |      |      |      |
>>>            +-----+       |         |      |      |      |
>>>            |     |       |         |      |      |      +------+
>>>            |     +-----+-+         +-+----+      +-+----+      |
>>>            |           |             |             |           |
>>>            |           |             |             |           |
>>>            |           |             |             |           |
>>>          +-+---+     +-+---+      +--+--+       +- --+     +---+-+
>>>          |Leaf |     |     |      |     |       |    |     |     |
>>>          |6LN  |     |     |      |     |       |    |     |     |
>>>          +-----+     +-----+      +-----+       +----+     +-----+
>>>
>>>
>>>                     Figure 2: A reference RPL Topology
>>> TW> I would add a "." at end of each caption
>>>
>>>    In different scenarios the use of RFC 6553, RFC 6554 and tunneling
>>>    can take place:
>>> TW> I would say that a combination of RFC6553, RFC6554 and IP-in-IP
>>> TW> encapsulation is used for the following traffic flows:
>>>
>>>    -Flow from leaf to root
>>> TW> remove newlines?
>>>    -Flow from leaf to Internet
>>>
>>>    -Flow from leaf to leaf
>>>
>>>    -Flow from Internet to leaf
>>>
>>>    -Flow from leaf to root
>>> TW> duplicate
>>>
>>> 4.  Example flow from leaf to root
>>>
>>>    A leaf node generates DAO and DIS messages and in general does not
>>>    accept them.
>>> TW> what do you mean by "accept"?
>>>    Additionally, this kind of nodes
>>> TW> node
>>>    accepts DIO messages,
>>>    but in general do
>>> TW> does
>>>    not generate them.  (In inconsistency A leaf node
>>>    generates DIO with infinite rank, to fix it).
>>> TW> A -> a
>>>
>>>
>>>
>>>
>>> Robles & Richardson    Expires December 29, 2015                [Page 4]
>>> Internet-Draft                 Useof6553                       June 2015
>>>
>>>
>>> 4.1.  Non-storing
>>>
>>>    In non-storing
>>> TW> mode
>>>    in this case
>>> TW> remove "in this case"
>>>    the leaf node uses Hop-By-Hop option (RFC
>>>    6553) to indicate the routing information to send messages to the
>>>    DODAG root, this message is going to be analyzed in each node until
>>>    arrive the DODAG root.
>>>
>>>    RFC 6554 was created to strictly send information between RPL routers
>>>    in the same RPL routing domain.  How it would be in 6554?
>>> TW> I assume a "TODO" missing before last sentence?
>>>
>>>    TBD: Tunneling is necessary in case that there is information to send
>>>    outside RPL Domain and other cases?
>>>
>>>                           +------+
>>>                           |      |
>>>                           | 6LBR |
>>>                           |      |
>>>                           +---+--+
>>>                               |
>>>                               |  LoWPAN_HC
>>>                               |  Route= 6LN-6LR-6LBR
>>>                        ^      |
>>>                        |  +---+-+
>>>                        |  |     |
>>>                        |  | 6LR |
>>>                        |  |     |
>>>                        |  +--+--+
>>>                        |     |   LoWPAN_HC
>>>                        |     |   Route= 6LN-6LR-6LBR
>>>                        |     |
>>>                        +     |
>>>                           +--+--+
>>>                           | 6LN |
>>>                           |     |
>>>                           |     |
>>>                           +-----+
>>>
>>>               Figure 3: From leaf to Root - Non-Storing Mode
>>>
>>> TW> I don't fully understand what message this figure conveys
>>> TW> I would use A B and C to name the nodes, and write their role
>>> TW> next to them
>>>
>>>
>>>
>>> 4.2.  Storing
>>>
>>>    IP6 6553{X,Y] ?ipip payload.
>>> TW> something's wrong
>>>    In storing mode is suitable the use of
>>>    RFC 6553 to send RPL Information through HBH field checking the
>>>    routing table to find out where to send the message.
>>> TW> I don't understand "checking the routing table to find out where
>>> TW> to send the message"
>>>    It may include
>>>    IP-in-IP encapsulation to transmit information not related with the
>>>    RPL domain.
>>> TW> I would expand this info
>>>
>>>
>>>
>>>
>>>
>>> Robles & Richardson    Expires December 29, 2015                [Page 5]
>>> Internet-Draft                 Useof6553                       June 2015
>>>
>>>
>>>                       +------+
>>>                       |      |
>>>                       | 6LBR |
>>>                       |      |
>>>                       +---+--+
>>>                           |
>>>                           |  LoWPAN_HC
>>>                           |  0x63|HBH Data
>>>                    ^      |
>>>                    |  +---+-+
>>>                    |  |     |
>>>                    |  | 6LR | 6LR check in routing table
>>>                    |  |     |
>>>                    |  +--+--+
>>>                    |     |   LoWPAN_HC
>>>                    |     |   0x63|HBH Data
>>>                    |     |
>>>                    +     |
>>>                       +--+--+
>>>                       | 6LN |
>>>                       |     |
>>>                       |     |
>>>                       +-----+
>>>
>>>                 Figure 4: From leaf to Root - Storing Mode
>>>
>>> 5.  Example flow from leaf to Internet
>>>
>>> 5.1.  Non-storing
>>>
>>>    In this case the IP-in-IP encapsulation should take place to send
>>>    information not related to the RPL domain inside of the RPL domain.
>>>
>>>    RPL information from RFC 6553 should not go out to Internet.  The
>>>    router sould
>>> TW> typo
>>>    take this information out before send the packet to
>>>    Internet.  The HBH Option is going to be analyzed in each node to the
>>>    root.
>>> TW> illustrate this with a fig?
>>>
>>>    Related to RFC 6554 the Source Header route is added and removed by
>>>    DODAG root.  However, RFC 6554 was created to strictly send
>>>    information between RPL routers in the same RPL routing domain.  How
>>>    it would be in 6554?
>>> TW> this paragraph relates to down traffic, right? The name of the
>>> section
>>> TW> is "from leaf to Internet"
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Robles & Richardson    Expires December 29, 2015                [Page 6]
>>> Internet-Draft                 Useof6553                       June 2015
>>>
>>>
>>> 5.2.  Storing
>>>
>>>    In storing the information of RFC 6553 should take away by DODAG root
>>>    before go to Internet.
>>> TW> but as well in non-storing, no?
>>>
>>> 6.  Example flow from leaf to leaf
>>>
>>>    can leafs insert appropriate headers, without ipip?  In [RFC6550] RPL
>>>    allows a simple one-hop P2P optimization for both storing and non-
>>>    storing networks.  A node may send a P2P packet destined to a one-hop
>>>    neighbor direclty
>>> TW> typo
>>>    to that node.  Section 9 in [RFC6550].
>>> TW> I would say that IP-in-IP is not needed in this case
>>>
>>> 6.1.  Traditional storing
>>> TW> why "Traditional"?
>>>    The route go through an ancestor that knows the route to the
>>>    destination, using HBH [RFC6553] to carry RPL Information.
>>>
>>> 6.2.  Traditional non-storing
>>>
>>>    The route go through the DODAG root, using source routing [RFC6554].
>>>
>>> 6.3.  P2P non-storing
>>>
>>>    (p2p storing?  TBD)
>>>
>>> 7.  Example flow from Internet to leaf
>>>
>>>    A DODAG root do not add routing extension to incoming packets, it
>>>    instead uses tunneling.
>>>
>>> 7.1.  Storing
>>>
>>>    DODAG root adds the HBH header [RFC6553] and send the packet downward
>>>    to the destination.
>>>
>>> 7.2.  Non-storing
>>>
>>>    DODAG root is going to add the source route header [RFC6554]
>>>
>>> 8.  Example flow from root to leaf
>>>
>>> 8.1.  Storing
>>>
>>>    DODAG root adds the HBH header [RFC6553] and send the packet downward
>>>    to the destination.
>>>
>>> 8.2.  Non-storing
>>>
>>>
>>>
>>>
>>> Robles & Richardson    Expires December 29, 2015                [Page 7]
>>> Internet-Draft                 Useof6553                       June 2015
>>>
>>>
>>>    DODAG root is going to add the source route header [RFC6554]
>>>
>>> 9.  IANA Considerations
>>>
>>>    There are no IANA considerations related to this document.
>>>
>>> 10.  Security Considerations
>>>
>>>    TBD.
>>> TW> I would replace TBD by TODO, per usual covention
>>>
>>> 11.  Acknowledgements
>>> TW> typo
>>>
>>>    This work is partially funded by the FP7 Marie Curie Initial Training
>>>    Network (ITN) METRICS project (grant agreement No.  607728)
>>>
>>> 12.  References
>>>
>>> 12.1.  Normative References
>>>
>>>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>>>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>>>
>>>    [RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
>>>               Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
>>>               Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
>>>               Lossy Networks", RFC 6550, March 2012.
>>>
>>>    [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
>>>               Power and Lossy Networks (RPL) Option for Carrying RPL
>>>               Information in Data-Plane Datagrams", RFC 6553, March
>>>               2012.
>>>
>>>    [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
>>>               Routing Header for Source Routes with the Routing Protocol
>>>               for Low-Power and Lossy Networks (RPL)", RFC 6554, March
>>>               2012.
>>>
>>> 12.2.  Informative References
>>>
>>>    [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
>>>               Lossy Networks", RFC 7102, January 2014.
>>>
>>> Authors' Addresses
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Robles & Richardson    Expires December 29, 2015                [Page 8]
>>> Internet-Draft                 Useof6553                       June 2015
>>>
>>>
>>>    Maria Ines Robles
>>>    Ericsson
>>>    Hirsalantie 11
>>>    Jorvas  02420
>>>    Finland
>>>
>>>    Email: maria.ines.robles@ericsson.com
>>>
>>>
>>>    Michael C. Richardson
>>>    Sandelman Software Works
>>>    470 Dawson Avenue
>>>    Ottawa, ON  K1Z 5V7
>>>    CA
>>>
>>>    Email: mcr+ietf@sandelman.ca
>>>    URI:   http://www.sandelman.ca/
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Robles & Richardson    Expires December 29, 2015                [Page 9]
>>>
>>>
>>> _______________________________________________
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>