Re: [Roll] Adopting turnon 8138

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 05 November 2019 09:43 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 CA8B1120863 for <roll@ietfa.amsl.com>; Tue, 5 Nov 2019 01:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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=Wjnwr8i9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fef41/Oi
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 nsQBetMQyavE for <roll@ietfa.amsl.com>; Tue, 5 Nov 2019 01:43:44 -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 8C17E120137 for <roll@ietf.org>; Tue, 5 Nov 2019 01:43:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7892; q=dns/txt; s=iport; t=1572947024; x=1574156624; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=70c3DHLBXOZ3PocADDN2S9SLiswFFhtJ1OrgAV+n5/Q=; b=Wjnwr8i9HdNlvrZWOp/s8GUb4Mes4DKTCcCPoirRxJmWbTszblOjK/YV WONCseEFV6OoQ67PCzn3DUGKCupF/Xr5C4MFRShfdII/yPtHFghyk9wMJ 7pKNhJzO5HH7cBtXlgfVXbMT3f95ToBevidL6yMFjaLruj4yEi73d/oqK Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3ArHhYuBah0xX0QAuhx9bGwcD/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBDwDHQ8Fd/5ldJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgX2BS1AFbFggBAsqhCmDRgOKe06CEH+IV44ogUKBEANUCQEBAQw?= =?us-ascii?q?BARgLCgIBAYRAAheDdyQ4EwIDCwEBBAEBAQIBBQRthTcMhVEBAQEBAwEBEBE?= =?us-ascii?q?RDAEBLAwLBAIBBgIRAwEBAQECAiYCAgIfBgsVCAgCBBMIEweDAYJGAy4BAgy?= =?us-ascii?q?TdpBiAoE4iGB1gTKCfgEBBYE4AoNXDQuCFwMGgQ4ojBMYgUA/gRFGgU5JNT6?= =?us-ascii?q?CG0cBAQIBgSYcHoMOMoIsjQgSgmaFX5dYQQqCJIcSihaEK5lnlnGCEY8ZAgQ?= =?us-ascii?q?CBAUCDgEBBYFpIoFYcBU7gmxQERSDBgwXg1CFFIU/dIEojUUBAQ?=
X-IronPort-AV: E=Sophos;i="5.68,270,1569283200"; d="scan'208";a="373085820"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Nov 2019 09:43:43 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xA59hhhK019937 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Tue, 5 Nov 2019 09:43:43 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Nov 2019 03:43:43 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Nov 2019 03:43:42 -0600
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 5 Nov 2019 03:43:42 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WU1MW3BR7n4rzzl3Gp2d3fNk//lNVZrReN98AII4Dh34s7SEIoLUBgqE6BMJRu1cuKEPdr2ZDBrdnSjEx3TMSwrOAkEU7Ea2+Mc4OXZTlUDhXhRrUV0DbwrKeCByCQq5dE38/jbKHDWlmKsyQmXtCJIUWJYuAm3Jon0qOE1mVYywhoppcyf1PGQBMUGbQ5zq86OQGe34TFibRloSA0vV3XETkzQe6/LEqen3h6lJsKNbhKMByhq5Kkc9OdI8KiPHQDEkaZ8Q8LMYGFws02W6kdyYoODUwsVJouzJEPfj98L1Qnte/tIJOx6pbDxsfuJT1RwjSPDuS6b2zX9lgrsfqw==
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=70c3DHLBXOZ3PocADDN2S9SLiswFFhtJ1OrgAV+n5/Q=; b=K8Wp+bwHHf5l2R3CYB10RF5gzJkN0h9tkQJNVKRq0AR8QGO9sCo/qL+/5HsoCexvJbGDJJymq+0Crw++DOYJMvNO+8JbU/dQeB/+u6rJFHER/weeRDLwr4g3/++ot0MheqEeRhb3FZjI4HnG9HLUj9OyA060B8gPeIn3PhUheDXShiPRzHzUm/6xPwNn6LcEXNgbgJQkPhxFe1PU+a33NfAqkc2s0Ev3u/QnkyAbCh8ESF1rnTnfB2HDhDe9PMytpcRggOZzkcbBB/ZlT1r41gpBB7F1S1HAkSPBwQZUdoqmWK7+fhbt8+xxpEtRYl5rj/X3pJuTRiIuDNOvz0xcHA==
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=70c3DHLBXOZ3PocADDN2S9SLiswFFhtJ1OrgAV+n5/Q=; b=fef41/Oi2Q77Ku+Hf+J/hyC0qshL7Oknb5+F2K/TTMo3Qre5jVF2ibm0y4/hcTVYpgbaSb19coq+9qo8Rba2ueWkQ0jJ9Tz8PFXUCOTHlfFY3m0VG3gepRwUZqWCJXbGUrdo5LqIDVwHXEHDjJSBBZhzgQSfpUjIl2ECzSdzEVM=
Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB3543.namprd11.prod.outlook.com (20.178.239.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Tue, 5 Nov 2019 09:43:41 +0000
Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::3ceb:e750:e2e5:8d69]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::3ceb:e750:e2e5:8d69%6]) with mapi id 15.20.2408.024; Tue, 5 Nov 2019 09:43:41 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] Adopting turnon 8138
Thread-Index: AQHVkz51IaUeQ4e3TG2QSA0m4ffOf6d8L3Y6gAAPoQCAAAe0UA==
Date: Tue, 5 Nov 2019 09:43:40 +0000
Deferred-Delivery: Tue, 5 Nov 2019 09:43:17 +0000
Message-ID: <BYAPR11MB3558A890EF352541445585D8D87E0@BYAPR11MB3558.namprd11.prod.outlook.com>
References: <MN2PR11MB3565D8323B4C7860396B2F8DD8610@MN2PR11MB3565.namprd11.prod.outlook.com> <CADnDZ8-p+HiLw9eoq8zKnRh9PqiT4HGYXdg_Cqid=eGQmd=V5g@mail.gmail.com> <CAP+sJUebKNAAEixtJQ-BFTDt3Aq9X2=MvgYJw_NrCrbtd1P3=g@mail.gmail.com> <76EB15DE-5CCD-4088-AE87-FF68436BC267@cisco.com> <268BA36A-AC92-4988-B971-A850CEB7EB39@tzi.org>
In-Reply-To: <268BA36A-AC92-4988-B971-A850CEB7EB39@tzi.org>
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: [2001:420:44f3:1300:fc9e:730:2c16:4060]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 18593051-7dca-4f47-1e81-08d761d4a447
x-ms-traffictypediagnostic: BYAPR11MB3543:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR11MB3543E75319756E0C216D8C06D87E0@BYAPR11MB3543.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0212BDE3BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(366004)(346002)(39860400002)(136003)(13464003)(199004)(189003)(33656002)(7736002)(6436002)(81156014)(8676002)(5660300002)(305945005)(76176011)(478600001)(7696005)(76116006)(86362001)(71190400001)(966005)(11346002)(6506007)(53546011)(71200400001)(66574012)(2906002)(486006)(186003)(256004)(14444005)(102836004)(14454004)(25786009)(561944003)(9686003)(6306002)(81166006)(52536014)(229853002)(46003)(99286004)(66946007)(446003)(66556008)(66476007)(66446008)(8936002)(476003)(64756008)(6116002)(316002)(74316002)(6916009)(55016002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3543; H:BYAPR11MB3558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: EevqxGK9x5kVUcoiNuL8Y5SUHriOwPv0spIcjfH1/vGEvdguaGhqYT+0cA+zAtv4Sr7MJI/kZBARcadjvecH8knY3egKrWL4keclc1QWFraI+nMkS61+w9kYnwofAI3DscJq9XPOLuyqm14qNZ9MOaE+kzW0J/FAUYaD2eaMPk5mEfyuzdlnLmhsBGkCL5gYnpKCdxAwmHlSHDVQPSkUibRBo8ziyOhwJvxVtYFL+KZ+z+sMjzxw5aknWBrHWe+0nQmLHJd66dHG8Gs+7HzqTq6Mivd6AbsqFcF27+PWhseTm94+hbADKlgL/OfeqSetciCTaGJewGL4teiktMRRSwm7RrfinmxwHhGat1oic/8RGfDZ0g40RibKQiXbI5r22hBIfs9mYdeXg8mFRyeFg/LujU1Xa0lwpPUSu/ZJGyNeDiOjphCPi40ZXCF+cLJu0z4Q2nWpZ9vtn5L42K9bCczCx3ndowHPn2eTmDZBBtc=
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: 18593051-7dca-4f47-1e81-08d761d4a447
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 09:43:41.1410 (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: XWAn7mQKPmsSPd6/ibNkKfXcA6qBPXzMIptGtiirur065MfvG3mFfIU1DZ4liBvDrtiH31F5gnF1Ru3DFoGexw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3543
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/97baNd-txQS8ztyRetF7IbzVnTQ>
Subject: Re: [Roll] Adopting turnon 8138
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, 05 Nov 2019 09:43:47 -0000

Yes, I thought about 6CIO. I'm a big fan and used it quite a bit already for other purposes within ND operations.

But here it did not seem as appropriate. Let me elaborate on that.

- RFC 8138 is a RPL specific thing not a generic compression. It seems awkward to import RPL-only concepts in ND. Like any ND device would now have to see a but that's used exclusively by RPL.

- The compression has to be done for a packet down a RPL path that is contained inside a RPL DODAG. A subnet is not necessarily congruent to a DODAG. Thus 6CIOs do not follow a particular RPL DODAG and making ND aware of RPL DODAGs seems awkward again.

- The bit expresses a constraint on a RPL node. If the node does not support RFC 8138 then is should be a leaf. This is pure RPL semantics, and the text in the turnon draft has to be in a RPL spec not ND.

- The behavior is similar to another bit that is already in the configuration option, see https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-32#section-10 . Both affect packet operation, both lead to a certain position in the DODAG (router vs. leaf) depending on the support of the node. The turnon rfc8138 is homogeneous with that.

- This homogeneity is highly desirable. We are now working on a capabilities exchange protocol where the root can poll the devices to know whether they can do this and that, so it can decide to turn on a feature in the configuration option. We want to apply this method to both turning on RFC 8138 and the new RPI value, and more stuff in the future.

The reason for the above is this: For RPL we could not afford to go and manually configure every node for any configurable parameter because we wanted to scale to large number of devices which implies ~zero-touch. IOW we had to design for an autonomic network. So we made it so that RPL distributes its own configuration and the DODAG builds itself as it learns that configuration in a fashion that depends in the configuration. What we did not do with RFC 6550 is the maintenance of the configuration. That was OK for the first generation but now we're adding stuff and we need to manage it dynamically. The flag to turnon RFC 8138 is just an epiphenomenon in that larger story.

I cannot pronounce it, but Grüße 😊

Pascal

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Carsten Bormann
> Sent: mardi 5 novembre 2019 09:27
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] Adopting turnon 8138
> 
> We generally signal compression capabilities using 6CIO (see RFC 7400).
> 
> I think this discussion is a symptom of ROLL trying to usurp some of the
> neighbor discovery functions, so in the end we never know where to put what.
> Of course piggybacking routing setup into neighbor setup is a good
> optimization, but doing neighbor setup implicitly based on having seen routing
> setup is creating this problem.  Maybe we can clean this up at some point.
> 
> Grüße, Carsten
> 
> 
> > On Nov 5, 2019, at 08:31, Pascal Thubert (pthubert) <pthubert@cisco.com>
> wrote:
> >
> > DODAG configuration as it’s name indicates is configuration. The goal is to
> tell dynamically how the protocol is operated as opposed to configuring all
> nodes separately.
> >
> > RPL operates in control plane and data plane. It does proactive route setup
> and reactive invalidation. These are all trade offs that are chosen to optimize
> energy and bandwidth efficiency vs. some theoretical perfection.
> >
> > The current proposal does not generate any additional transmission.
> Defining a new protocol to set one bit might appear more perfect but would
> require bandwidth and code footprint that we do not have.
> >
> > You are very free to propose an alternate solution with enough details so we
> can understand it, even push a draft, and then the WG will make the best of
> all it sees.
> >
> > Pascal
> >
> > ---------- Forwarded message ---------
> >> From: Abdussalam Baryun <abdussalambaryun@gmail.com>
> >> Date: Fri, Nov 1, 2019 at 11:55 AM
> >> Subject: Re: [Roll] Adopting turnon 8138
> >> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> >>
> >>
> >> I don't think it is the right approach, why using the DODAG configuration
> for compression? this compression turn on/off is not for the DODAG
> construction but for packets. I think we should separate configurations of the
> RPL routing standards and of the packet compression standards. We may add
> another configuration option per DODAG or another way.
> >>
> >> What do you think?
> >>
> >> AB
> >>
> >> On Tue, Oct 29, 2019 at 4:34 PM Pascal Thubert (pthubert)
> <pthubert@cisco.com> wrote:
> >> Dear all
> >>
> >>
> >>
> >> https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-03 is a simple
> draft that completes RFC 8138 with bits in the config option to enable turning
> it on in an brown field.
> >>
> >> There’s no black magic and it would be good to progress it in the
> background rather than forget it.. Could we consider adoption?
> >>
> >>
> >>
> >> All the best
> >>
> >>
> >>
> >> Pascal
> >>
> >> _______________________________________________
> >> 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 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