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: 9a23:9ZLxjB1ICBnKdlJWsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C7BwBG4HBe/51dJa1mHAEBAQEBBwEBEQEEBAEBgXuBVFAFbFggBAsqhBaDRQOKc06CEYEBlxeBQoEQA1QJAQEBDAEBIwoCBAEBhEMCF4F9JDgTAgMBAQsBAQUBAQECAQUEbYVWDIVjAQEBAQIBEhEEDQwBATUDCwQCAQgRBAEBAwImAgICMBUICAIEARIIGoMFgkoDDiABDqF9AoE5iGJ1fzOCfwEBBYEzAoQCGIIMAwaBDiqFIIcOGoFBP4ERR4IYNT6CZAICGoEvCxEVgnoygiyNdoJ7n1IKgjyNJIQ4hTeCSjGHd4RQjASPBYFOmhACBAIEBQIOAQEFgWkigVhwFYMnUBgNjh0MF4NQhRSFQXSBKYsugkEBAQ
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; b=Txlvq5KBDH/ZAA4ImPwKAzY3KA/Q3t2ZW5Kc5Sm6gLOO12VzxTFNMc+Eva6K1Rh+YWp+J7hoa9OpduQWwL/k2uhJdVu0oF4aMZcnpFaZNUKVJhRHMEIziuPNS8Xu9vZAJH6/a065YIMolVCA7oIidqZ3Onk8+v9r8g8v7bpSED3YwvehhV24dKNQdIHtrnSaTmNp7qE4eZoYL11lTXvTYVTRyz7zz3XalU3NFli5ziqOl/nF47KU6/aYJp5YrqvY/8DT8g8yrVRyuXtkck9ZE0kAtRqEZWavAmJy8iBbl2oUJrAw5HmYORd+HRGgGA+KoMdSjFMJ9PbKjSz39R93hA==
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=XWS++t/n+ioqQiMvAyVgh/ge9V1hXFotrozYvP5TXgw=; b=Z9rhIQgHvzYXVZ4krrZx31Ztkgkl4XHwZVl+TLT4HvCpg8JNy1gi3KgAmcqjAsC68ZJLHnzobXmVG1OrDrnseTe4wew2LP5qRKnxQWb4cXLf4z4PCwVHWsK3JziPqBld0nfb+c+yoNCvgcBphldomNIMSFU88NWeDDDxoXrVD+wE4azaCpH6oJmaBgM6/bEdG4CQ85YoIsWKq47XAGeZ7Z3EJO1h0x1NuyZ4apiFtCige3aRhKgS90r+r9GSTOVNq68Hp3WXYCB97dib4ZWSUdNHw5DRmH6q/YO5X3+CmncKFkGaFvHBzImM9+ZQAc7c09lxeF1katQQvzaJK9NZYQ==
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=XWS++t/n+ioqQiMvAyVgh/ge9V1hXFotrozYvP5TXgw=; b=koTQ5NJ5JyULVooaqdjeSOBkgVBKJxuqPEgsdqaoyR7f+APDQykElcE4PmQ8vxmjVgHg6yxXQEJdMP2sP/Hvb7VhPGLMwrPLXAhGFBH7cOeIrpIANg1SyGsKAmTgBEmVwtee21t6j0A6KLXQUbr6ppqN/+EEWghI2FwPS7VfTC4=
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: <MN2PR11MB35650108ADD7C22D67C6173BD8F60@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <158410288420.3321.7400803802055697408@ietfa.amsl.com>, <23773.1584304056@localhost> <3A00F2FF-C119-496C-BC53-87DBD6C375B4@cisco.com> <9766.1584384223@localhost> <MN2PR11MB35659BFC7F16BEBF34FEBEC0D8F60@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35659BFC7F16BEBF34FEBEC0D8F60@MN2PR11MB3565.namprd11.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: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: <MN2PR11MB4174C069C7A76CE094B6DA04D8F60@MN2PR11MB4174.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(199004)(30864003)(6666004)(8676002)(9686003)(186003)(6506007)(7696005)(53546011)(2906002)(316002)(52536014)(110136005)(86362001)(8936002)(2940100002)(5660300002)(15650500001)(81156014)(81166006)(66946007)(966005)(55016002)(66574012)(76116006)(66446008)(66556008)(64756008)(66476007)(71200400001)(478600001)(33656002)(21314003); 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: Ug0l+j2U4RHIbEB2wEVUAUKHTqjQDVthZCb0bId8kA7N6VKO41vIHygCfEakI5QOOpzRujd+h8q0wh07dWzH6bvSr47qkGvgTCcVKV/h4qvP+IyUSKtYSIkAoxvXJVe8i90ogAnf1Iljl8uuEfkm5BqmeCPQRwh1lJN9A52GKGO8OTO+D/rpvVcXdIbGxw0+Tfywemmp1YmD1V9oM0ptuFvVP2Uvt2J/9pheHrOzW0NmmtJU2JcMSAoxGdTrkFVH7mrgCZuIaY/qH02gZL0SPWTN/M43V4XOBEt+jORfP98/1GNTwz3osUULv1VA4g8cGIcVyGlCtrjRaO8TEmJyhkFLk8FgwMFsbCQ4cFw3kuhQB5Ok5gdKTftpR3ZNamm2umsOXT4uGcglSBx/gv2mwwfFyEm3o93+TLD9oyvm77StVxmyvZXWhKRuiH6jXAzEs8ig+a0ZNUs2IeUaU78wo13LIC5laX3SQRZMZqVvRkdoYnE7CEqKuwyJ5Qc8zWGnui5r4wxdSFxdHdhfnt7XiSXScFodes/sZuTcx5/dV1YUjlYJRVmhCk7LdJgrEc8p
x-ms-exchange-antispam-messagedata: HTsf22OWXq9s3x0FIYS/7LqYAlQ5GO1oblMQXsvAjWhM2xZONWcg7qfxNb5wiBOxo++UYomJVr9iXEKt78w1hrgtESP1zlToCbKqFqNm3HGVB8lvlTJloFiXuIs2KoPpxH3Ej0b4blsarZeaKQPACyYSrL14jdckRYNlZpiGlT4eRg3X7oaGuPxxZtQrkRj/IWAS0QQZhvsHxQY5nC8tjw==
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: JZVhhD/gxNuxILH1neLpiN9IwuthbLN2rFsE509erWgSeGFb4kELX0+seq31kipEKsvOD6CacCw8R536tQmdaw==
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>; 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)