Re: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 22 January 2020 10:18 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB005120074 for <roll@ietfa.amsl.com>; Wed, 22 Jan 2020 02:18:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level:
X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 header.b=A72hkjZ5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QHadGBvr
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 Yx3N2cIP5Azn for <roll@ietfa.amsl.com>; Wed, 22 Jan 2020 02:18:23 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8C7120043 for <roll@ietf.org>; Wed, 22 Jan 2020 02:18:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31319; q=dns/txt; s=iport; t=1579688303; x=1580897903; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XVbkBhpO0WR+cKI3EZZbJr3t4Aj0tpgYR22c9+H13UE=; b=A72hkjZ5ZKLyuamG0sjlqpGIrDm46Gi4xKNPe2C8q0DV7xw6t8U/1ycV L6WiiPB//FUfq3gqYrLLpKLoyh1vulMWad/B3tHd1ewEGsOwycEkuiquJ myXOqrf2CrfQ0+rlOpwbZNQMzpD+1EixQzC+71poQz82NsK5LgYwGeZ9C k=;
IronPort-PHdr: =?us-ascii?q?9a23=3AcRmdNhH68FqhwHTzCqikjJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqCQD1IChe/4gNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJS9QBWxYIAQLKodYA4sGToIRgQGPHxKHXIFCgRADVAkBAQE?= =?us-ascii?q?MAQEjCgIBAYRAAoIYJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDDAYVBhM?= =?us-ascii?q?BATAIDwIBCBEEAQEhAQYHMhQJCAIEEwgagwWBfU0DLgECDKMFAoE5iGGBdDO?= =?us-ascii?q?CfwEBBYFDQYMAGIIMAwaBOIUbgSyBWoN1GoFBP4EQAUeBTkk1PmsZAYFfAgI?= =?us-ascii?q?BAYEnOgwYBwmDDIIsjVyIVYlzjkJwCoI5hz+HaIcngkeICotihEREjGGKG5I?= =?us-ascii?q?mAgQCBAUCDgEBBYFpIoFYcBWDJ1AYDYJthRSDc4UUhT90AoEnjEgBAQ?=
X-IronPort-AV: E=Sophos;i="5.70,349,1574121600"; d="scan'208,217";a="709870793"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 10:18:22 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MAIMrU004578 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Wed, 22 Jan 2020 10:18:22 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 04:18:21 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 04:18:20 -0600
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 22 Jan 2020 05:18:20 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jjM/aV+Q4fCBx3ROTciDuZQFhmxD+tUluWIJQiocO3vHLMmUYzYJJTeygGfWyeIhJdGisCc97gHxX/lLZkM2j7jXXoVRpH+gBa9a/lmEqO41YgJXvEOBZi/naB58+6QcCZewm9/qEbM65Ddu7m6HEZ4HPRrq8Q+q1n6B/LVor2AkTmLKV7XBFs2i8SQ7O3VF7x9NnONZO0KtQWRM7qpzpGhbyf25RAirk5t4KWmF5/vhoyPUDzumUySoAZ3zPjwf8R7ktMmeyEvFRg7BpbVSdQT4MO27eVyLFT+wm86S9p0rZ9NiqzxGKod5RwDzbNNIfOuMBoWM/aREDRVPxMFKcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kc1eWPUPAKE9L6QBn/urS+CCnNt+sJh9ryGUkJThDZ0=; b=ViMekMo+VkXtcPAxeoucdk0izsaUCLaukD15nBHkoYNcCS4guWO9lCernZJXSh/aznV4suUMDt9gtDyNTS7fXwBkxvghAlqgKmuauDCsVrO3mzndWcqqH4X4lFiQtyO3K8Iq87K7nF/oJ/KVrtimMlOW0D/tnZJdtHn404+cezjlDYJMT/fLmRxjxtri23x/z/H9iOwlrszITfevgdfpsQZ6JwrikS1/GE4rl9GBWqfPrmn4Ccx09W429mpWX3zMDUTvz3E8LKsn9JVQOiEuAmmBp4UWN+HsEGSQVaxTJwtCJ54YnqGaiX22FtoOSqjX5Y0OrETzTUTsj1bVEYfgwQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kc1eWPUPAKE9L6QBn/urS+CCnNt+sJh9ryGUkJThDZ0=; b=QHadGBvrIoZC6ch31vsydDnLlAMaC+qTw1NB8pJi9fSWHOi5yiatKgDpp1khgVt1FWi78nSy8uolq5EwLUCwX6mIQDYmWAstrlTbCXeYoO3dG9X2A/4RbV6WadBYMeVEkvMzKdUqDTOUyVkVXVY94+HGc1bqM1ZGhn5U6uAs8Tc=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4030.namprd11.prod.outlook.com (10.255.181.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Wed, 22 Jan 2020 10:18:18 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 10:18:18 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02
Thread-Index: AQHVzSKEkzxa5vgOHE60eQMA7CRaaKf09ejrgAFmAxA=
Date: Wed, 22 Jan 2020 10:17:52 +0000
Deferred-Delivery: Wed, 22 Jan 2020 10:16:57 +0000
Message-ID: <MN2PR11MB356510BE84CF94333B09F35ED80C0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CAP+sJUdjeeKkP0sHZ9ueHXRf7ePRV16Us5rTwh_S6htn_Kfjhw@mail.gmail.com> <BM1PR01MB2612725A4CC01B3633EB4AB3A90D0@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <BM1PR01MB2612725A4CC01B3633EB4AB3A90D0@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:850c:4da1:8ec9:acf4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b5c0cebf-ae64-474b-0728-08d79f2466cc
x-ms-traffictypediagnostic: MN2PR11MB4030:
x-microsoft-antispam-prvs: <MN2PR11MB403098D6C7448DF2F49200A9D80C0@MN2PR11MB4030.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 029097202E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(366004)(346002)(376002)(189003)(199004)(478600001)(71200400001)(9686003)(966005)(33656002)(8936002)(6916009)(52536014)(81166006)(81156014)(8676002)(5660300002)(2906002)(66574012)(6666004)(76116006)(186003)(66946007)(66446008)(66556008)(64756008)(66476007)(316002)(7696005)(55016002)(6506007)(53546011)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4030; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: h0+beYRT00MTg7BpVpSgiaGelz+F22nKpnxl6Jn1eMjgt3uJ8A7dESESyjkG+oXVPIOwAPGN77m2rp6Ych/8MIeQGOptQ0cL5xoSIbq18qmZ4lv93x1fWo+rOTfYo0pvPNm445P0N3tDOSJGtor6pJhn2BaNbWqf6N8fNIZ2ifMtv1UQy+8+McOC2vudI6GXA5hGKDQS7+4+IinhGWWPivs3pXG8eliwrgLAbzq4T8NS5ZxC0cnFoCUywcE1TRoqU/y8MSgLC4jdXVSFmdPGuQBouB0w1ZcmvBrT8OzakImoMUkR90qyReuZpGAMLM7EurRkt8oxxokC/LTgPaGHhu662Lu8xi7PHNMvXKMPIbLcU/MkRvluAqxVzJ9Sm567tCk3jTGKnY6+hv7IWkdLrR0g9o9u1RuCcdDDwaIVZVvpO6N9TMkoZZXDWsij5S4hKQTjP0mdwatvXhZPTRY7aMN/rLIW/Ygs4nUinKzvQSVa97h8GkQuwBE7QNL9ap49QGhhkG7fuSjYotxoo1isRg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356510BE84CF94333B09F35ED80C0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b5c0cebf-ae64-474b-0728-08d79f2466cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 10:18:18.6292 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Agvs56P/PS80I1EgnbE8FfP/DpcgEbqCV2FR+Kbr0/e9KH4Oq5e6QmQMQ5R/etzYFLJDS7luM9MSl28uro4x0w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4030
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Q7aGCBOaA6AlDA8EHJrg2cHbclE>
Subject: Re: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 22 Jan 2020 10:18:26 -0000

Hello Rahul

Many thanks for your review!

Li created a new repo within the ROLL github, you'll find it under https://github.com/roll-wg
Please see below:


Overall the document is very much to the point and I do not have any major comments.
Following are my comments for the draft(-02):

1. Section 5
"It results whether a parent supports RFC 8138 is not known by the child with the current level of specifications, and a child cannot favor a parent based on a particular support."
I think the purpose of this sentence is to let know that one cannot use T flag as a way to know that the parent supports 8138 or not. But I am not sure of this. Do you think this can be rephrased?

<Pascal>
You're correct. What about replacing with:
"
A parent propagates the "T" flag as set whether it supports
RFC 8138 or not. The setting of the "T" flag can thus not be
used as an indication of the support by the sender, and a child
cannot favor a parent based on it.

"
</Pascal>

2. A 6LR may be 8138 + this draft compliant and may want to initiate "a local instance" in which case the 'T' flag needs to be set/unset. I believe the 6LR could use the knowledge of Global Instance to handle this. But again, may be there is no relation here, and it is completely the choice of the Instance root (in this case the given 6LR) to decide this. I just wanted to say it loud, to check if there is anything missing!

<Pascal>
Great question, and yes. Each root is responsible to set the "T" flag based on its own knowledge and needs, true for local and global RPL Instances.

If the OF support mandates RFC 8138 then that will work. If the 6LR/root knows that all participants support RFC 8138 that will work as well. Once we have the capability draft and the 6LR/root found that all the members of the DODAG have the capability, that will work.
What if the 6LR knows none of that? This question affects in particular the DAO projection work. A projected path may cross over multiple DODAGS so it cannot inherit from one.

Also I gave a new look at the transition scenarios. We say that a node that does not support RFC 8138 can act as a leaf if the 6LR un-compresses the packets before delivery. Same question, how does it know? As it goes, useofrplinfo says that external targets are not expected to support RFC 8138 since it is a RPL thing. So acting as a RUL, we know things work.

Till the capability work comes in we need a separate source of knowledge (config, management) for a 6LR to know if 1) it can form a local instance with the "T" flag set and 2) to deliver packets to a RAL in compressed form.

I suggest to mod the section on leaf as follows:
"
    A node that does not support <xref target='RFC8138'/> can interoperate with a
    node that supports this specification in a network with RFC 8138 compression
    turned off. But it cannot forward compressed packets and therefore it cannot
    act as a router in a network with RFC 8138 compression turned on. It may
    remain connected to that network as a leaf and generate uncompressed packets.
    The leaf can receive packets if they are delivered by the parent 6LR in the
    uncompressed form. This requires a knowledge by the 6LR that the leaf does
    not support RFC 8138.
    A RPL-Unaware-Leaf (RUL) <xref target='I-D.ietf-roll-useofrplinfo'/>
      is an external target and by default is not expected to support RFC 8138. "

</Pascal>

3. Section 5
"But the node is also free to refrain from joining an Instance when a parameter is not suitable."
Refrain from joining an instance is not the same as "join as a leaf". A node that joins as a leaf, still is joining the instance. A node may join as a leaf when a parameter is not suitable. (It is possible that I have completely misunderstood the statement here).

<Pascal>
Yes that sentence is not that useful. It says that the node may decide not to join at all. Which is true but not a scientific breakthrough.
I'd rather indicate the following
"
   [ietf-roll-useofrplinfo] indicates that the node may also
   join as a RUL, in which case it refrains from participating to RPL and depends on the
   6LR to ensure connectivity regardless on the way the RPL network is operated.

"
</Pascal>

4. Section 5.3
"instances operate as ships-in-the-night"
ships-in-the-night? I didn't find any explanation in the given ref. After searching online, I think I understand :-), better to put in simple terms.
<Pascal>
What about
"
The two RPL Instances operate independently as specified
   in <xref target='RFC6550'/>.
"
</Pascal>


Nits:
1. "network is rebooted with implicitely"
implicitely -> implicitly

ok

2. "in an homogeneous network" -> "in a homogeneous ..."

Ok

3. "but MAY still joins as a leaf" -> "but MAY still join as a leaf"
Ok


4. ". when it finally" -> ". When it finally" .... Better would be to rephrase
... "The root migrates to new OCP when it finally sets the "T" flag."

<Pascal>
I'd wish to indicate clearly that they go together. What about:
"
The root sets the "T" flag at the time it migrates to the new OCP.
"
</Pascal>

5. "distribute the uncompresses"
uncompresses -> uncompressed

ok

6. Instance 'I' is used capital in some cases, 'i' in other cases for exact similar context.

<Pascal>
Should use "RPL Instance" every time as RFC 6550 does.
</Pascal>


7. The term "turn on" is used in a few places... For e.g., in security considerations, "Turning the "T" flag on before...." ... Can we use ON in caps here to specify the meaning appropriately?
<Pascal>
Unsure. Do we need to define "turning on"?
</Pascal>


Thanks,
Rahul


________________________________
From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Ines Robles <mariainesrobles=40googlemail.com@dmarc.ietf.org<mailto:mariainesrobles=40googlemail.com@dmarc.ietf.org>>
Sent: Friday, January 17, 2020 10:39 AM
To: roll <roll@ietf.org<mailto:roll@ietf.org>>
Subject: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02

Dear all,

We kindly request reviews for the draft draft-ietf-roll-turnon-rfc8138-02<https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/> , we understand that it is ready for Last Call.

Thank you in advance,

Ines and Dominique