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 132BC1203D1 for ; Wed, 26 Jun 2019 18:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 6A2boPk6Uf_a for ; Wed, 26 Jun 2019 18:03:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 531251200B5 for ; Wed, 26 Jun 2019 18:03:05 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D67D39C61B79B214CA5E for ; Thu, 27 Jun 2019 02:03:03 +0100 (IST) Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 02:03:03 +0100 Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 27 Jun 2019 02:03:03 +0100 Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 27 Jun 2019 02:03:02 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.118]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 06:32:53 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks CC: =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: Retrying DCO/DAO, retry parameters Thread-Index: AdUshAoU1ZNXDKIJRSu3/AosXtsQyA== Date: Thu, 27 Jun 2019 01:02:53 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF0BFA2@BLREML503-MBX.china.huawei.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DF0BFA2BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Roll] Retrying DCO/DAO, retry parameters 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, 27 Jun 2019 01:03:07 -0000 --_000_982B626E107E334DBE601D979F31785C5DF0BFA2BLREML503MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, During IESG evaluation of (draft-ietf-roll-efficient-npdao-12) we received = a comment from Mirja regarding specifying the DCO retry operation in detail= if DCO-ACK is not received. Quoting her verbatim, "Please specify a maximu= m number of retries and also a minimum retry interval (of e.g. 3 sec best w= ith exponential back-off)!" Currently the draft says that this is "implementation and deployment depend= ent". RFC 6550 also has DAO retries if DAO-ACK is not received but it also does n= ot specify this operation in detail. Do you think we can put this explicitly and does anyone have an opinion on= the right way of putting this considering different physical layers with v= ery different characteristics operating in dense/sparse (wireless) deployme= nts? Thanks, Rahul --_000_982B626E107E334DBE601D979F31785C5DF0BFA2BLREML503MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello All,

 

During IESG evaluation of (draft-ietf-roll-effici= ent-npdao-12) we received a comment from Mirja regarding specifying the DCO= retry operation in detail if DCO-ACK is not received. Quoting her verbatim= , “Please specify a maximum number of retries and also a minimum retry interval (of e.g. 3 sec best with expo= nential back-off)!”

 

Currently the draft says that this is “impleme= ntation and deployment dependent”.

RFC 6550 also has DAO retries if DAO-ACK is not rece= ived but it also does not specify this operation in detail.

 

Do you think we can put this explicitly  and do= es anyone have an opinion on the right way of putting this considering diff= erent physical layers with very different characteristics operating in dens= e/sparse (wireless) deployments?

 

Thanks,

Rahul

--_000_982B626E107E334DBE601D979F31785C5DF0BFA2BLREML503MBXchi_--