IETF Logo Mail Archive

[Roll] Retrying DCO/DAO, retry parameters

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Thu, 27 June 2019 01:03 UTC

Return-Path: <rahul.jadhav@huawei.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 132BC1203D1 for <roll@ietfa.amsl.com>; 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 <roll@ietfa.amsl.com>; 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 <roll@ietf.org>; 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 <roll@ietf.org>; 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 <rahul.jadhav@huawei.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
CC: Mirja Kühlewind <ietf@kuehlewind.net>
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: <https://mailarchive.ietf.org/arch/msg/roll/uRtXmuYmh_z-HlWxmZU31m6EoQA>
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 <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: Thu, 27 Jun 2019 01:03:07 -0000

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 maximum number of retries and also a minimum retry interval (of e.g. 3 sec best with exponential back-off)!"


Currently the draft says that this is "implementation and deployment dependent".
RFC 6550 also has DAO retries if DAO-ACK is not received but it also does not 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 very different characteristics operating in dense/sparse (wireless) deployments?

Thanks,
Rahul

v2.23.0 | Report a Bug | By Email