Re: [6tisch] [Roll] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 23 February 2018 12:19 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188E512D93E; Fri, 23 Feb 2018 04:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 gmSom5jCPcfJ; Fri, 23 Feb 2018 04:19:34 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC9D1242F5; Fri, 23 Feb 2018 04:19:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3248; q=dns/txt; s=iport; t=1519388374; x=1520597974; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EN4+SFjkQ7208968krR0/honNxwib+dPKyRA4vUisvg=; b=CgBIn0pRkb+q8W4ZTImgGSe9CFVu38S4PUjXw61BkPDqVoyogrLPUDRq 8SZBP/zx91KM6QRBwcWUgggshtHzbAYCXIfMxp4x/5fwJu7XuU/ShhWZP ALA6YOCKBxcaIJb4AyVkDdrUvDR5HQjkyTXE/HG6lM6ssrw3ReCntjfhr 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AZAQCkBpBa/4ENJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYMeMYFWKAqOA418ggKBFpZRghYKggGDMgKCNVQYAQIBAQEBAQECayiFIwEBAQMBJxM9AgULAgEINhAyJQIEDgUIihMIrgI6iHmCHgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2FGIIngVeBZoMtix0FpEIJApYFgiiSJoscjGICERkBgTsBHzmBUXAVgn2CVBwZgW14izeBGQEBAQ
X-IronPort-AV: E=Sophos;i="5.47,383,1515456000"; d="scan'208";a="74334120"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2018 12:19:27 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w1NCJRLW030106 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Feb 2018 12:19:27 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 23 Feb 2018 06:19:26 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Fri, 23 Feb 2018 06:19:27 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>
CC: "6tisch@ietf.org" <6tisch@ietf.org>
Thread-Topic: [6tisch] [Roll] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt
Thread-Index: AQHTqvUqiyrunT5oXUuWaZlTwS084qOulacfgAFHRoCAAd4mgA==
Date: Fri, 23 Feb 2018 12:19:16 +0000
Deferred-Delivery: Fri, 23 Feb 2018 10:02:48 +0000
Message-ID: <aeca79527d934ed181b3498c83a03843@XCH-RCD-001.cisco.com>
References: <151920480372.9603.17635052466831884104.idtracker@ietfa.amsl.com> <0507EB1B-3B42-4108-A511-EEE413CF0FE4@cisco.com> <10405.1519253755@obiwan.sandelman.ca>
In-Reply-To: <10405.1519253755@obiwan.sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/FtgNjQBZAyQza2N4W66oPXnUcJ4>
Subject: Re: [6tisch] [Roll] Fwd: New Version Notification for draft-thubert-roll-unaware-leaves-02.txt
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Feb 2018 12:19:37 -0000

Hello Michael

> 
> 1) can you add a reference for "Routing Stretch"?
[PT>] done, pointing on RFC 6687

> 2) Alternatively, the 6LN may rely on its 6LR to perform routing and
>    forwarding on its behalf.  In the context of RPL, such a 6LN is
> 
>    -> if you want to give an example of such a node, I think that the window
>       smash sensor (alarm system), or the kinetically powered light switch,
>       are two good examples.
>    {I wish I had links to real products that actually ran RPL.}

[PT>] done

> section 3:
> s/      Upon the renewal of a registration, this specification changes the
>         behavior or the 6LR.
>  /      Upon the renewal of a 6lowPAN ND registration, this specification
> changes the
>         behavior of the 6LR. /
> 
> The rest of that paragraph is ver hard to parse.
> 
[PT>] reworded as follows:
"
   Upon the renewal of a 6lowPAN ND registration, this specification
   changes the behavior of the 6LR as follows.
   If the 'R' flag is set, the 6LR injects a DAO targeting the Registered
   Address, and refrains from sending a DAR message. 
   the DAR/DAC exchange that refreshes the state in the 6LBR happens instead 
   between the RPL Root and the 6LBR. In that flow, the RPL Root acts as a
   proxy on behalf of the 6LR upon the reception of the DAO propagation
   initiated at the 6LR.
"

> section 4:
> should:
>    This document specifies a new flag in the EARO option, the 'R' flag,
>    used by the registering node to indicate that the 6LN that performs
>    the registration is a router and that it handles its reachability.
> 
> say:
>    This document specifies a new flag in the EARO option, the 'R' flag,
>    used by a 6LN, when registering, to indicate that this 6LN
>    is a router and that it will handles its own reachability.
> 
[PT>] Moved to the RFC 6775 update draft and updated as follows
"
   This document makes use of the 'R' flag in the EARO option, used by
   a 6LN, when registering, to indicate that this 6LN is a leaf, not aware of
   the RPL operation in the network, and thus does not participate to it.
   The behavior defined in this specification whereby the 6LR that processes the
   registration advertises the Registered Address in DAO messages and bypasses
   the DAR/DAC process for the renewal of a registration, is  only triggered by
   an NS(EARO) that has the 'R' flag set. A RPL leaf SHOULD set the 'R' flag.
   
   If the 'R' flag is not set, then the Registering Node is expected to be a RPL
   router that handles the reachability of the Registered Address by itself.
   This document also specifies a keep-alive EDAR message that the RPL Root may
   use to maintain an existing state in the 6LBR upon receiving DAO messages. 
   The EDAR message may only act as a refresher and can only update the Lifetime
   and the TID of the state in the 6LBR.  A RPL router SHOULD NOT set the 'R' flag.
"
>    (...By sending a DAO)
> 
> The rest of the document has some difficult sentences too.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>