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, 04 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>: > >> 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 > >
- [Roll] Thomas' remarks on draft-robles-roll-useof… Thomas Watteyne
- Re: [Roll] [6tisch] Thomas' remarks on draft-robl… Robert Cragie
- Re: [Roll] Thomas' remarks on draft-robles-roll-u… Ines Robles
- Re: [Roll] [6tisch] Thomas' remarks on draft-robl… Xavier Vilajosana
- Re: [Roll] [6tisch] Thomas' remarks on draft-robl… Ines Robles
- Re: [Roll] [6tisch] Thomas' remarks on draft-robl… Pascal Thubert (pthubert)
- Re: [Roll] Thomas' remarks on draft-robles-roll-u… Michael Richardson
- Re: [Roll] [6tisch] Thomas' remarks on draft-robl… Michael Richardson
- Re: [Roll] Thomas' remarks on draft-robles-roll-u… Thomas Watteyne
- Re: [Roll] [6tisch] Thomas' remarks on draft-robl… Ines Robles