Return-Path: 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 914733A0781 for ; Thu, 4 Jun 2020 01:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 e3wmSL3QfCmp for ; Thu, 4 Jun 2020 01:44:07 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253105.outbound.protection.outlook.com [40.92.253.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE1A3A060A for ; Thu, 4 Jun 2020 01:44:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EHyqFFTT+cqpOCD5655DXLF++kzy6nttq8WLq7jELis4wN5dZsbXJl+v7odVy1paggwFdwBxfiz/TUAkejPcSUan8tPamVRK38LAvoTa2eUAooiU3+LGNKf6S6+vjVcehbsGaIr004C1c3EYdulb7OYqTA1yhAZvpJ40D1KxE6GtjiP5MIs3aDAOCiaDzwRlDhpqToSpww5KVHXTXcg7cSlN+rntQ9fm1CIkJyNRoWxcNc6ZLDBMPf7AdTVuepE6X8EFqM97Upos8HXBMGg7iY+gU8xaxa3VP0gXtlwaluG2chPSnCmUjQlCqNvGYM2+GfcWPWUgeTdTML/bGElaDw== 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=YFcL3+m1DB+kPMZIM6qK3zmJvJRhtl+mLn+nw5Zx1mM=; b=Zv9abeXjxPlCsPE/3o1wY+VqA3W3RCgDKB8k1cCMxyl6NdUsAhWXC8TZ4Z0d76wlUaakDroYA9W9gCisS6Ql+x6rIxrlYP8oQg64lsxELgVYsqlT2NXEARN9bKCMs6pg/EDfaYhwTvXbZTj8gommYmw3HrQ5mjqN1Y/PCoWu/E+lfkOLp8oBNbokDNZTYwErST8hH0SOtFu/UzHeCMw1XF9kc8nMdzwiTuAWirZRCq1cipw5tLewUa7jViIrLB3oPmUv9VlYopKCCwDXaDpPhUwWhIl4JsX0lF6Ta9E14lNMrBr6XcsY5asD41RE/OvLS9pJ/pzprFkcp9wKRuLEnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YFcL3+m1DB+kPMZIM6qK3zmJvJRhtl+mLn+nw5Zx1mM=; b=YfFS7cKa3vvSoQ/fYI/4br1jgtDSuDUfN2mMeP9rydFN1/LxNMg6R9qvoTuyLhU+QLxMilQoegSokgvPzvW/tBzzE3nN8XW2r5gZV4tqzf0exv6moQCpn/cJGvMnZvm8XNqqB2H0GZDOzehlqU9lhTTuQkHgfkkfeVkt0Vqd+4tuDRqq+osUF7XHwk24S2mSNISj0HpcAwBCzEGIZFXnd4HYe51KjWTSYtcBRbC0lnabNYbh/8lAun56AJzGh2djBck/e/Wof+p5A+N9pUlnWiq0sgaRQM4hvR/52Bg05+JgaBo/hmyo4vkJFh9yU6xr4i0ORme/obNwpy86Z5byMw== Received: from HK2APC01FT008.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::45) by HK2APC01HT040.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::451) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 08:44:04 +0000 Received: from MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM (2a01:111:e400:7ebc::49) by HK2APC01FT008.mail.protection.outlook.com (2a01:111:e400:7ebc::117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Thu, 4 Jun 2020 08:44:04 +0000 Received: from MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM ([fe80::e874:bbdb:9f9e:9564]) by MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM ([fe80::e874:bbdb:9f9e:9564%7]) with mapi id 15.20.3066.018; Thu, 4 Jun 2020 08:44:04 +0000 From: Rahul Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Eliding-Info: Abbreviated Option and RCSS of an Option Thread-Index: AQHWOkocKpj1H27IcEy2JaZ6sG/+EqjIIHHM Date: Thu, 4 Jun 2020 08:44:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:F8A9D2C0D9B16778E8D14DD74B6B8F89C4422C176B9175055399FE56C0137945; UpperCasedChecksum:3F2362EE5E83B335D930F651F45F8498D93D78E8AB6943F98110EEE77EF39226; SizeAsReceived:6851; Count:44 x-tmn: [zBoGFGDW3umbnd7mNdElEYQsHWNl42v4] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: aefa650b-946d-4bf6-901c-08d808636fb5 x-ms-traffictypediagnostic: HK2APC01HT040: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IEk42dzONHZKKBd7bRusLWxDqvTyNwDtvwU4P2MLwpY+EPAxgXL1GggqaPLhhSdJmuGGO413lR/hj8GFj7yes51kDxCMnfhduxwt0vSbQI4EBNamK7q3FmbazEtcETfzHHYhqUZA2JuT2Htb8xrLuAx/An4iPNBjmYtHcl36057sGvsnl0ylP9hRWBaotANXPVgI85xJnDVDNdaKuhE8qA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: KFE4pVI1kpab045piutinVoRvLFfHJpM/233yrjndFn5zbW0i5zdFLVI8xdWf7FNNkYDjzwy2YiNU/7iEqBkbfJPCY09XQhCqhyKuy5lfwtW2PnZxL+g00H2eXKxVxRv5xO64o7boKughstqwMbmTA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MAXPR01MB249313BD2C861A6EF00A9111A9890MAXPR01MB2493INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: aefa650b-946d-4bf6-901c-08d808636fb5 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 08:44:04.0530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT040 Archived-At: Subject: Re: [Roll] Eliding-Info: Abbreviated Option and RCSS of an Option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 08:44:10 -0000 --_000_MAXPR01MB249313BD2C861A6EF00A9111A9890MAXPR01MB2493INDP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Please find my response inline [RJ]. RCSS can identify whole options in DIO, but it may be not flexible. Imagine the case that some reduced function device which don=92t support MO= Pex/GCO, when root only update MOPex/GCO, even though RCSS increment, DIO c= an carry AOO and advertise the updated options, these RFDs could ignore the= RCSS increment. [RJ] I would argue on the contrary that for an RFD the complexity of AOO is= even less useful. Assuming that the protected options change rarely, how b= ig is the utility for an RFD to know that only one of the protected options= is changed and syncing it individually. Is it possible to add mode for RCSS? Simple mode means RCSS can only be a c= ommon counter for all the options. Complex mode means AOO can identify indi= vidual protected options? [RJ] I understand that the draft supports simple mode and complex mode (usi= ng AOO) is only an extension. But what I intend to say is that the complex = mode may be a deterrent to anyone reading the draft. More importantly, I co= uld not figure out much utility. The purpose of this draft is to reduce run= time network overhead. I would argue that complex mode will reduce the cont= rol overhead by a fraction of a percentage but requires more flash/ram. From: Roll on behalf of Rahul Jadhav Reply-To: Routing Over Low power and Lossy networks Date: Thursday, June 4, 2020 at 15:45 To: Routing Over Low power and Lossy networks Subject: [Roll] Eliding-Info: Abbreviated Option and RCSS of an Option Hello All, Pascal, Based on my understanding currently, the draft serves three purposes: 1. Helps elide common DIO options which rarely change 2. Helps elide common DAO options during route refresh cycles 3. Allow sync for individual protected options by assigning RCSS to an opti= on (this implies the use of new AOO) Points 1 and 2 are quite clear and easy to follow. The whole complexity of the proposal lies in point 3 and from what I unders= tand I believe the utility is not convincing enough for the amount of compl= exity it introduces. My understanding is that with AOO, it is possible that a Root assigns a dif= ferent RCSS to individual protected options such that the downstream nodes = can individually query and synchronize with any of that option on change. My rationale is that PIO/RIO/DODAG Configuration/MOPex/GCO options rarely c= hange. IMO, if either of it changes then it is no big deal to advertise all= the options. Rather than managing versions for each of these options, the = RCSS can only be a common counter for all the options. I understand that RCSS of an option is "an extension" and it is possible to= only use common RCSS. But I believe the whole RCSS of an option as an exte= nsion is adding to the complexity of the draft (introducing more scenarios = to handle), and also making it difficult for the reader. Best, Rahul --_000_MAXPR01MB249313BD2C861A6EF00A9111A9890MAXPR01MB2493INDP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Please find my response inline [RJ].

 

RCSS can identify whole options in DIO, but it may be = not flexible.

Imagine the case that some reduced function device which don=92t sup= port M= OPex/GCO, when root only update M= OPex/GCO, even though RCSS increment, DIO can carry AOO and a= dvertise the updated options, these RFDs could ignore the RCS= S increment.


[RJ] I would argue on the contrary that for an RFD the complexity of= AOO is even less useful. Assuming that the protected options change rarely= , how big is the utility for an RFD to know that only one of the protected options is changed and syncing it i= ndividually.

 

Is it possible to add mode for RCSS? Simple mode means= RCSS can only be a common counter for all the options.= Complex mode means AOO can identify individual protected options?


[RJ] I understand that the draft supports simple mode = and complex mode (using AOO) is only an extension. But what I intend to say= is that the complex mode may be a deterrent to anyone reading the draft. M= ore importantly, I could not figure out much utility. The purpose of this draft is to reduce runtime network o= verhead. I would argue that complex mode will reduce the control overhead b= y a fraction of a percentage but requires more flash/ram.

 

 


 

From: Roll <roll-bounces@ietf.org> on = behalf of Rahul Jadhav <nyrahul@outlook.com>
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.or= g>
Date: Thursday, June 4, 2020 at 15:45
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] Eliding-Info: Abbreviated Option and RCSS of an Opti= on

 

Hello All, Pascal,

 

Based on my understanding currently, the draft serves three purposes:

1. Helps elide common DIO options which rarely change

2. Helps elide common DAO options during route refresh cycles

3. Allow sync for individual protected options by assigning RCSS to an opti= on (this implies the use of new AOO)

 

Points 1 and 2 are quite clear and easy to follow.

 

The whole complexity of the proposal lies in point 3 and from what I unders= tand I believe the utility is not convincing enough for the amount of compl= exity it introduces.

 

My understanding is that with AOO, it is possible that a Root assigns a dif= ferent RCSS to individual protected options such that the downstream nodes = can individually query and synchronize with any of that option on change.

 

My rationale is that PIO/RIO/DODAG Configuration/MOPex/GCO options rarely c= hange. IMO, if either of it changes then it is no big deal to advertise all= the options. Rather than managing versions for each of these options, the = RCSS can only be a common counter for all the options.

 

I understand that RCSS of an option is "an extension" and it is p= ossible to only use common RCSS. But I believe the whole RCSS of an option = as an extension is adding to the complexity of the draft (introducing more = scenarios to handle), and also making it difficult for the reader.

 

Best,

Rahul

 

--_000_MAXPR01MB249313BD2C861A6EF00A9111A9890MAXPR01MB2493INDP_--