Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 17 March 2020 14:38 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 456403A085A
for <roll@ietfa.amsl.com>; Tue, 17 Mar 2020 07:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=VNgwYuBV;
dkim=pass (1024-bit key)
header.d=cisco.onmicrosoft.com header.b=koTQ5NJ5
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 IXmPZrBVF_IA for <roll@ietfa.amsl.com>;
Tue, 17 Mar 2020 07:38:53 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74])
(using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 9465E3A0858
for <roll@ietf.org>; Tue, 17 Mar 2020 07:38:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=cisco.com; i=@cisco.com; l=19890; q=dns/txt;
s=iport; t=1584455933; x=1585665533;
h=from:to:subject:date:message-id:references:in-reply-to:
content-transfer-encoding:mime-version;
bh=XWS++t/n+ioqQiMvAyVgh/ge9V1hXFotrozYvP5TXgw=;
b=VNgwYuBVhxr7egIHa7zXfu/CZFh+Mr3Uo94RPB+T+C1ciGRKLOfJp8+L
S2mCO1+SlleU8PORGyXD7C2KnPznq4YnhTVZD4OREh4rda9BOeuj4E84V
fP3AVFByBsqtE8w/G80hvjuylSamB+52571XJT4RScn3Xp+AyvwKo2ku/ A=;
IronPort-PHdr: =?us-ascii?q?9a23=3A9ZLxjB1ICBnKdlJWsmDT+zVfbzU7u7jyIg8e44?=
=?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?=
=?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7BwBG4HBe/51dJa1mHAEBAQEBBwE?=
=?us-ascii?q?BEQEEBAEBgXuBVFAFbFggBAsqhBaDRQOKc06CEYEBlxeBQoEQA1QJAQEBDAE?=
=?us-ascii?q?BIwoCBAEBhEMCF4F9JDgTAgMBAQsBAQUBAQECAQUEbYVWDIVjAQEBAQIBEhE?=
=?us-ascii?q?EDQwBATUDCwQCAQgRBAEBAwImAgICMBUICAIEARIIGoMFgkoDDiABDqF9AoE?=
=?us-ascii?q?5iGJ1fzOCfwEBBYEzAoQCGIIMAwaBDiqFIIcOGoFBP4ERR4IYNT6CZAICGoE?=
=?us-ascii?q?vCxEVgnoygiyNdoJ7n1IKgjyNJIQ4hTeCSjGHd4RQjASPBYFOmhACBAIEBQI?=
=?us-ascii?q?OAQEFgWkigVhwFYMnUBgNjh0MF4NQhRSFQXSBKYsugkEBAQ?=
X-IronPort-AV: E=Sophos;i="5.70,564,1574121600"; d="scan'208";a="727041424"
Received: from rcdn-core-6.cisco.com ([173.37.93.157])
by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA;
17 Mar 2020 14:38:51 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12])
by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 02HEcoa9030651
(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL);
Tue, 17 Mar 2020 14:38:51 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com
(173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3;
Tue, 17 Mar 2020 09:38:50 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com
(64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3;
Tue, 17 Mar 2020 10:38:47 -0400
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; Tue, 17 Mar 2020 10:38:47 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
=?utf-8?q?b=3DTxlvq5KBDH/ZAA4ImPwKAzY3KA/Q3t2ZW5Kc5Sm6gLOO12VzxTFNMc+Eva6K1?=
=?utf-8?q?Rh+YWp+J7hoa9OpduQWwL/k2uhJdVu0oF4aMZcnpFaZNUKVJhRHMEIziuPNS8Xu9v?=
=?utf-8?q?ZAJH6/a065YIMolVCA7oIidqZ3Onk8+v9r8g8v7bpSED3YwvehhV24dKNQdIHtrnS?=
=?utf-8?q?aTmNp7qE4eZoYL11lTXvTYVTRyz7zz3XalU3NFli5ziqOl/nF47KU6/aYJp5YrqvY?=
=?utf-8?q?/8DT8g8yrVRyuXtkck9ZE0kAtRqEZWavAmJy8iBbl2oUJrAw5HmYORd+HRGgGA+Ko?=
=?utf-8?q?MdSjFMJ9PbKjSz39R93hA=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?=
=?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?=
=?utf-8?q?bh=3DXWS++t/n+ioqQiMvAyVgh/ge9V1hXFotrozYvP5TXgw=3D=3B_b=3DZ9rhIQ?=
=?utf-8?q?gHvzYXVZ4krrZx31Ztkgkl4XHwZVl+TLT4HvCpg8JNy1gi3KgAmcqjAsC68ZJLHnz?=
=?utf-8?q?obXmVG1OrDrnseTe4wew2LP5qRKnxQWb4cXLf4z4PCwVHWsK3JziPqBld0nfb+c+y?=
=?utf-8?q?oNCvgcBphldomNIMSFU88NWeDDDxoXrVD+wE4azaCpH6oJmaBgM6/bEdG4CQ85YoI?=
=?utf-8?q?sWKq47XAGeZ7Z3EJO1h0x1NuyZ4apiFtCige3aRhKgS90r+r9GSTOVNq68Hp3WXYC?=
=?utf-8?q?B97dib4ZWSUdNHw5DRmH6q/YO5X3+CmncKFkGaFvHBzImM9+ZQAc7c09lxeF1katQ?=
=?utf-8?q?QvzaJK9NZYQ=3D=3D?=
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; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AM?=
=?utf-8?q?essage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADC?=
=?utf-8?q?heck=3B_bh=3DXWS++t/n+ioqQiMvAyVgh/ge9V1hXFotrozYvP5TXgw=3D=3B_b?=
=?utf-8?q?=3DkoTQ5NJ5JyULVooaqdjeSOBkgVBKJxuqPEgsdqaoyR7f+APDQykElcE4PmQ8vx?=
=?utf-8?q?mjVgHg6yxXQEJdMP2sP/Hvb7VhPGLMwrPLXAhGFBH7cOeIrpIANg1SyGsKAmTgBEm?=
=?utf-8?q?Vwtee21t6j0A6KLXQUbr6ppqN/+EEWghI2FwPS7VfTC4=3D?=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31)
by MN2PR11MB4174.namprd11.prod.outlook.com (2603:10b6:208:154::11)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.14; Tue, 17 Mar
2020 14:38:46 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com
([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com
([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2814.021; Tue, 17 Mar 2020
14:38:46 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To:
Michael Richardson <mcr+ietf@sandelman.ca>, "roll@ietf.org" <roll@ietf.org>
Thread-Topic: New Version Notification for
draft-ietf-roll-unaware-leaves-11.txt
Thread-Index: AQHV+wgp0rlICDWRl02cnIGxwamUR6hKIoVQgAFtDYCAAQy0EIAAQEPQ
Date: Tue, 17 Mar 2020 14:38:16 +0000
Deferred-Delivery: Tue, 17 Mar 2020 14:37:34 +0000
Message-ID: =?utf-8?q?=3CMN2PR11MB35650108ADD7C22D67C6173BD8F60=40MN2PR11MB3?=
=?utf-8?q?565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158410288420.3321.7400803802055697408@ietfa.amsl.com>,
<23773.1584304056@localhost> <3A00F2FF-C119-496C-BC53-87DBD6C375B4@cisco.com>
<9766.1584384223@localhost> =?utf-8?q?=3CMN2PR11MB35659BFC7F16BEBF34FEBEC0D?=
=?utf-8?q?8F60=40MN2PR11MB3565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CMN2PR11MB35659BFC7F16BEBF34FEBEC0D8F60=40MN2PR11MB?=
=?utf-8?q?3565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
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:957:248:1e11:16b5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6fa6a2dd-c031-48e3-b6c7-08d7ca80e62d
x-ms-traffictypediagnostic: MN2PR11MB4174:
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR11MB4174C069C7A76CE094B6DA04D8F?=
=?utf-8?q?60=40MN2PR11MB4174=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?=
=?utf-8?b?MDA5KSgzNDYwMDIpKDM3NjAwMikoMTM2MDAzKSgzOTYwMDMpKDM2NjAwNCkoMzk4?=
=?utf-8?q?60400002=29=28199004=29=2830864003=29=286666004=29=288676002=29?=
=?utf-8?b?KDk2ODYwMDMpKDE4NjAwMykoNjUwNjAwNykoNzY5NjAwNSkoNTM1NDYwMTEpKDI5?=
=?utf-8?q?06002=29=28316002=29=2852536014=29=28110136005=29=2886362001=29?=
=?utf-8?q?=288936002=29=282940100002=29=285660300002=29=2815650500001=29=28?=
=?utf-8?q?81156014=29=2881166006=29=2866946007=29=28966005=29=2855016002=29?=
=?utf-8?q?=2866574012=29=2876116006=29=2866446008=29=2866556008=29=28647560?=
=?utf-8?q?08=29=2866476007=29=2871200400001=29=28478600001=29=2833656002=29?=
=?utf-8?q?=2821314003=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4174;
H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en;
PTR:InfoNoRecords; 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: =?utf-8?q?Ug0l+j2U4RHIbEB2wEVUAUKHTqjQDVt?=
=?utf-8?q?hZCb0bId8kA7N6VKO41vIHygCfEakI5QOOpzRujd+h8q0wh07dWzH6bvSr47qkGvg?=
=?utf-8?q?TCcVKV/h4qvP+IyUSKtYSIkAoxvXJVe8i90ogAnf1Iljl8uuEfkm5BqmeCPQRwh1l?=
=?utf-8?q?JN9A52GKGO8OTO+D/rpvVcXdIbGxw0+Tfywemmp1YmD1V9oM0ptuFvVP2Uvt2J/9p?=
=?utf-8?q?heHrOzW0NmmtJU2JcMSAoxGdTrkFVH7mrgCZuIaY/qH02gZL0SPWTN/M43V4XOBEt?=
=?utf-8?q?+jORfP98/1GNTwz3osUULv1VA4g8cGIcVyGlCtrjRaO8TEmJyhkFLk8FgwMFsbCQ4?=
=?utf-8?q?cFw3kuhQB5Ok5gdKTftpR3ZNamm2umsOXT4uGcglSBx/gv2mwwfFyEm3o93+TLD9o?=
=?utf-8?q?yvm77StVxmyvZXWhKRuiH6jXAzEs8ig+a0ZNUs2IeUaU78wo13LIC5laX3SQRZMZq?=
=?utf-8?q?VvRkdoYnE7CEqKuwyJ5Qc8zWGnui5r4wxdSFxdHdhfnt7XiSXScFodes/sZuTcx5/?=
=?utf-8?q?dV1YUjlYJRVmhCk7LdJgrEc8p?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?HTsf22OWXq9s3x0FIYS/7LqYAlQ5GO?=
=?utf-8?q?1oblMQXsvAjWhM2xZONWcg7qfxNb5wiBOxo++UYomJVr9iXEKt78w1hrgtESP1zlT?=
=?utf-8?q?oCbKqFqNm3HGVB8lvlTJloFiXuIs2KoPpxH3Ej0b4blsarZeaKQPACyYSrL14jdck?=
=?utf-8?q?RYNlZpiGlT4eRg3X7oaGuPxxZtQrkRj/IWAS0QQZhvsHxQY5nC8tjw=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id:
6fa6a2dd-c031-48e3-b6c7-08d7ca80e62d
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 14:38:46.1345 (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: =?utf-8?q?JZVhhD/gxNuxILH1neLpi?=
=?utf-8?q?N9IwuthbLN2rFsE509erWgSeGFb4kELX0+seq31kipEKsvOD6CacCw8R536tQmdaw?=
=?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4174
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At:
<https://mailarchive.ietf.org/arch/msg/roll/Y_Gu-fvHbGqUbPeApQ_4BpqwN-c>
Subject: Re: [Roll] New Version Notification for
draft-ietf-roll-unaware-leaves-11.txt
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: Tue, 17 Mar 2020 14:38:57 -0000
Hello again Michael I applied a number of your recommendations and published 13. I hope that the remainder of the discussion can be addressed during WGLC, if any. Please see https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-13 Take care Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: mardi 17 mars 2020 12:27 > To: 'Michael Richardson' <mcr+ietf@sandelman.ca>ca>; roll@ietf.org > Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-11.txt > > Hello Michael, > > Now going through your questions below: > > > -----Original Message----- > > From: Michael Richardson <mcr+ietf@sandelman.ca> > > Sent: lundi 16 mars 2020 19:44 > > > > 1) I notice the Abstract is a single complex sentence. > > I think we should split it up somehow. > > I will think on this after reading it all through. > > Yes, I use your proposed change, keps the split, and moved one sentence > down. > > > > > > 2) I have a bunch of typos/missing words that I'll commit directly to github. > > > > Thanks! > > > 3) Should we say: > > > > A RUL is a plain <xref target="RFC8504" /> Host that needs a > > RPL-Aware Router to obtain routing services over the RPL network. > > > > that is, insert RFC8504 here? > > Or should we actually say RFC8504/RFC8505, because we depend upon > EARO? > > I'd like to get Carsten to review this actually, as we are really > > updating what it means to be a "Host" on a constrained network. > > For 8505, the next sentence does it. I like your suggestion to add the reference > and changed "plain host" to "IPv6 host". > > > > > > How can we split this up into three sentences: > > This specification leverages the Address Registration mechanism > > defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to > > interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) to > > request that the 6LR injects the relevant routing information for the > > Registered Address in the RPL domain on its behalf. > > > > I think that this paragraph (3.2.1) should get turned into part of the abstract: > > > > This document specifies how the "R" flag is used in the context of > > RPL. A 6LN is a RUL that requires reachability services for an IPv6 > > address iff it sets the "R" flag in the EARO used to register the > > address to a RPL router. Conversely, this document specifies the > > behavior of a RPL Router acting as 6LR depending on the setting of > > the "R" flag in the EARO. The RPL Router generates a DAO message for > > the Registered Address upon an NS(EARO) iff the "R" flag is set. > > I really like to keep the abstract short. > > > > > > I wonder if the word "Conversely," is needed. > > Maybe: > > A 6LN is a RUL that requires reachability services for an IPv6 > > address. It sets the "R" flag in the EARO in order to register the > > address to a RPL router. This is described in RFC8505. > > > > This document specifies the behavior of a RPL Router that processes > > EARO messages that have the the "R" flag set in the EARO. > > > > Not sure if this is abstract content, but I like the above. > > You really like the word "Conversely" :-) > > > > I do but we can remove/change if not appropriate > > > I am concerned that there is so much repeating of 8505, that this will > > confuse some reviewers. I guess we do Update 8505, but maybe we > > should hit them a bit harder on the head that they need to understand it first. > > This is really the RPL counterpart of RFC 8505, and we need to show the > matching operation each time it occurs. > > > section 4: I keep wondering if we haven't created a new Storing-Mode > > MOP here, > > that should get a new MOP value (or mopex) value. > > But, I see that 6.3.1. contains the compromise text we worked > > out at IETF106. > > Rahul discussed a real new MOP in a parallel thread. Interesting stuff... > > > > > > let me think: a storing root that does not set the P bit (because it does not > > support this functionality) will cause 6LR that support this to not > > support RUL processing, and not support RULs. > > Should such 6LRs also essentially not do RAs in that context? > > Does this also enable RFC8505/EARO processing? > > > > I find section 4 really dense, and I wonder if it wouldn't be better > > to move sections 4 and 5 later in the document, so that we are referring > back. > > I'm not sure here. > > That would be really difficult. Section 4 is a collection of pointers to the next > sections as an introduction of what comes next. > > > > > section 6.1: > > In order to obtain routing services from a 6LR, a RUL MUST implement > > [RFC8505] and set the "R" flag in the EARO option. The RUL MUST NOT > > request routing services from a 6LR unless the 6LR originates RA > > messages with a CIO that has the L, P and E flags are all set as > > discussed in Section 3.3.1. > > > > -> I think that rather than have MUST NOT, which I think does not lead > > -> to > > good interop failure results, I suggest we write: > > > > A RUL that receives a CIO from a potential (6LR) router that has the L, P and > E > > flags set, SHOULD set the "R" flag in the EARO in order to request routing > > services from that 6LR. > > Well, that's only if the 6LR wants to use that guy. And you're reversing the > meaning. I tried to say that a router can be used for this spec iff its sets all the > bits. I read your text as saying that if a router sets the bits then the RUL > SHOULD use it.... > > > > A RUL that has multiple potential routers SHOULD prefer the router that > > can provide the desired routing services. > > If there are no available routers, the connection of the RUL fails. > > Kept it, though a bit on the obvious side > > > > > > (XXX- Can the RUL use the EARO process in the absence of L/P/E to signal > > the error? I think that deployment of 8505 without this document is a > > very small window, so this won't work in general) > > > > Yes. A RUL can register to many routers, to get a DODAG back. It may in > parallel register to routers that to not have the bits set, so it can talk to them. > But it will not get routing services and the "R" flag will not be set in the NS and > NA 's EARO > > > > > ... > > The RUL MUST register to all the 6LRs from which it requests routing > > services. > > > > section 6.2: > > A 6LR that is upgraded to act as a border router for external routes > > advertises them using Non-Storing Mode DAO messages that are unicast > > directly to the Root, even if the DODAG is operated in Storing Mode. > > > > yes, but it should only request them from routers which support R, right? > > The external route is a general term, and the route can be learnt in many ways. > E.g. redistribute an IGP. > You're correct that it means the 'R' is in the case of a RUL learned via 6LoWPAN > ND. > > > > > The RPL data packets always carry a Hop-by-Hop Header to transport a > > RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates > > its packets with an RPI, the 6LR needs to tunnel them to the Root to > > add the RPI. As a rule of a thumb and except {FOR} the very special case > > above, the packets from and to a RUL are always encapsulated using an > > IP-in-IP tunnel between the Root and the 6LR that serves the RUL. > > > > I think that this should reference [UseOfRPLinfo] section 7.1.4, > > section 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 8.2.3, 8.2.4, 8.3.3 and 8.3.4. > > > > Good > > > section 9.1: > > In a same fashion, if an additional routing protocol is deployed on a > > same network, that additional routing protocol may need to handle the > > keep alive procedure for the addresses that it serves. > > > > I believe that this might scare our routing colleagues into thinking > > that we intend to deploy things in parallel on LLNs. Do we need to say this at > all? > > (I understand that you are just expressing an outward requirement on > > anyone that wants to do this. Maybe we can put this in a section of it's own > so > > that someone can point to it in the future? Quite reasonable, someone > could > > attach a non-constrained wired network on the edge of an LLN, and run > > OSPFv3 or something there. But there would be no overlap with the > > LLN) > > Yes, that would be a complicated network... I believe the text is needed, but if > you like we could move to appendix or something. > > > > > section 9.1.1, I think that the column that says "6LN" should say "RUL" > instead. > > Yes, 6LN is not wrong, but I think it's not helpful. > > Yes, I like your proposal > > > Do we need to say something about LLNs which do not have a 6LBR? > > Or is this degenerate case self-evident? > > > > section 9.2.1: "By the 6LN" -> "By the RPL unaware 6LN"? > > Anything as long as 9.2.1 and 9.2.2 are homogeneous... > > > > > > * The 6LN can register to more than one 6LR at the same time. In > > that case, it MUST use the same value of TID for all of the > > parallel Address Registrations. > > > > I'd like to motivate this statement, I think it should reference > > RFC8505 section 5.2. Just so that no part of this process is "new" > > Cool > > > > > > > Even without support for RPL, a RUL may be aware of opaque values to be > > > provided to the routing protocol. If the RUL has a knowledge of > > > the RPL > > > > I just looked to see if we return RPLInstanceID in CoJP, and we don't > > :-( Someone could write a document in RPL to add that. > > Do you think we should do it here? It's doable... > > > > > > > A RUL that places an > > > RPI in a data packet MUST indicate the RPLInstanceID that corresponds > > > to the RPL Instance the packet should be injected into. All the > > > flags and the Rank field are set to zero as specified by section 11.2 > > > of [RFC6550]. > > > > It has never been clear to me how much security isolation > > RPLInstanceID should have. Is it as strong as 802.1Q VLAN tags? Or > > is much softer, just a bit more interesting than IPv6 Flow? If it's > > intended to be as strong as VLAN tags, then there is an admission control > control that the 6LR must do. > > Could be made as strong. I mean a vlan is only as strong as the switches make > it. You'd need different keys per instance since we use the same radio > interfaces. > > > > > > > Extended Duplicate Address > > > messages with the 6LBR is avoided if the RPL Root has indicated that > > > it proxies for it. > > > > I'm misplaced how the RPL root has indicated this. Is it in the DAO-ACK? > > See section 4, we could have a reference " > > RPL defines a configuration option that is registered to IANA in > section 20.14. of [RFC6550]. This specification defines a new flag > "Root Proxies EDAR/EDAC" (P) that is encoded in one of the reserved > control bits in the option. The new flag is set to indicate that the > Root performs the proxy operation and that all nodes in the network > must refrain from renewing the 6LBR state directly. The bit position > of the "P" flag is indicated in Section 12.2. > " > > Maybe we can say > > " > message, but the exchange of keep-alive Extended Duplicate Address > messages with the 6LBR is avoided if the RPL Root has indicated that > it proxies for it using the "P" flag in the RPL configuration option > (see Section 4). > " > > > > > 9.2.2: > > > * RPL Non-Storing Mode is used, and the 6LR indicates one of its > > > global or unique-local IPv6 unicast addresses as the Parent > > > Address in the associated RPL Transit Information Option (TIO). > > > > I think that this is an instruction that RPL Non-Storing mode is TO BE used, > > (not a conditional sentence). I suggest we number these points so that > > implementers can argue about them better, and make them all more > > declarative. > > There is a commented out sentence in the XML, which I think we can remove. > > Cool. We should do the same in 9.2.1 and 9.2.3 then, no? > > > > > I understand the use of "iff" throughout, but I'm not sure others will > > notice it as other than a typo of "if". I turned the next paragraph > > into a numbered point, but maybe the trailing ';' now does not work. > > I'm not sure that the reverse direction provides anything useful. Opinions? > > I though it did, but OK without it. > > > > > Should the rest of the If/In case be changed to a section on 6LR processing > > of DAO-ACK, and a section on processing of DCO? Right now processing is > > described by each role. I'm for that, but I think we should split it > > up as well by message. > > > If needed... > > > > Is section 12 RFC6550 multicast actually implemented by anyone? > > We have use for it. > > > Given MPL, I didn't think you needed both, but maybe I don't > > understand multicast. > > MPL is out of scope here. IMHO it's a more of a broadcast than a multicast. In > ny fashion I do not see it as a replacement to RPL but as another protocol that > can co-exist with RPL though both can live separately. > > > Section 12 RFC6550 would have been something I would have removed for > > 6550bis, so I wonder if we should be doing anything with it. > > I have to disagree with that. Just like I disagree with other people about > removing storing mode. > > > > section 12.3, I think that instead of reducing the size of the Flags > > field, I suggest that we say that we are allocating 4 bits of the Flag > > field as the ROVRsize. (I found it really confusing to figure out btw) > > Happy to reword but we are not allocating 4 flags, we are reusing the footprint. > > > > > ---- > > I wish I had time to implement this in unstrung and the Linux kernel. > > :-( I need to clone myself. > > That would be an interesting world : ) > > I published -12 with your changes and already picked some of the proposals > above in the github. > Please have a look and let me know when you do think we want more. > > Many thanks again Michael! > > Pascal
- Re: [Roll] New Version Notification for draft-iet… Pascal Thubert (pthubert)
- Re: [Roll] New Version Notification for draft-iet… Michael Richardson
- Re: [Roll] New Version Notification for draft-iet… Pascal Thubert (pthubert)
- Re: [Roll] New Version Notification for draft-iet… Pascal Thubert (pthubert)
- Re: [Roll] New Version Notification for draft-iet… Pascal Thubert (pthubert)