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

Ines Robles <mariainesrobles@googlemail.com> Sat, 04 July 2015 03:05 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 3A9C11B2A24 for <roll@ietfa.amsl.com>; Fri, 3 Jul 2015 20:05:34 -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 yxUv1Yc752Jx for <roll@ietfa.amsl.com>; Fri, 3 Jul 2015 20:05:28 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 84FB91B330D for <roll@ietf.org>; Fri, 3 Jul 2015 20:05:27 -0700 (PDT)
Received: by lagx9 with SMTP id x9so101489114lag.1 for <roll@ietf.org>; Fri, 03 Jul 2015 20:05:26 -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=9gktXBvA/kvaDCPlY0G74XKUp4QoTD7xtzt83GLE7n4=; b=cuAOPBcpunrhhx78rlsz1Z0Gusg6Afe6SC1+Aqw6hKid3BTGLZySbTjLVfY9k3gpk+ h+HN1cqxamXfIZsyf6Reo3fVI9TJzXIX56rL0FZ86oFuiVZ5tI4EqEJChkeroXKITkkw OtEoTMphd1Az/xLmbze1KR0ctEdtX6FKrFYTBoKa8Uopfs0OmB/ZyIgD12KN1e2nhsNd iheSAM4XhOi2LkxQdqLIIsx9mZmWrs3omfY1zgfPkCZ0dWWUnkILFKiBoTxfkkZDfv1W lXFUXSzIe627Y3dLsYDhSBPBnERsoYbZMzLirUAoczcNlT9zD/zshnMdGRolwCMsheuH oNMg==
MIME-Version: 1.0
X-Received: by 10.152.26.163 with SMTP id m3mr38598511lag.86.1435979125937; Fri, 03 Jul 2015 20:05:25 -0700 (PDT)
Received: by 10.25.208.70 with HTTP; Fri, 3 Jul 2015 20:05:25 -0700 (PDT)
Received: by 10.25.208.70 with HTTP; Fri, 3 Jul 2015 20:05:25 -0700 (PDT)
In-Reply-To: <CADJ9OA_bRQv8rkkgwK1Q8pQ1=pB_Cd8iJ-Dk72z4uRwsJO-T+Q@mail.gmail.com>
References: <CADJ9OA_bRQv8rkkgwK1Q8pQ1=pB_Cd8iJ-Dk72z4uRwsJO-T+Q@mail.gmail.com>
Date: Sat, 4 Jul 2015 06:05:25 +0300
Message-ID: <CAP+sJUdCOvR6hJBFAAwq2T5_13e8fbbHnLUeM9N-hxNTisGVCQ@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
To: roll <roll@ietf.org>, Thomas Watteyne <watteyne@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary=089e0158c73eb4db14051a03f1d4
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/Tqf7s-ej-FRWv6ro0hmcWDMx2q8>
Subject: Re: [Roll] 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 03:05:34 -0000

Thank you very much Thomas for your comments, we will fix the document.
Cheers,
Ines
On 3 Jul 2015 16:54, "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]
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>