Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT)

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Thu, 04 July 2019 01:05 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 D40AF120179; Wed, 3 Jul 2019 18:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JZna3TOVMguw; Wed, 3 Jul 2019 18:05:15 -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 4ECC91200D7; Wed, 3 Jul 2019 18:05:15 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1C4F6F11D50450B9148A; Thu, 4 Jul 2019 02:05:13 +0100 (IST)
Received: from lhreml712-chm.china.huawei.com (10.201.108.63) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Jul 2019 02:05:12 +0100
Received: from lhreml712-chm.china.huawei.com (10.201.108.63) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 4 Jul 2019 02:05:12 +0100
Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 4 Jul 2019 02:05:12 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.50]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Thu, 4 Jul 2019 06:35:01 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-roll-efficient-npdao@ietf.org" <draft-ietf-roll-efficient-npdao@ietf.org>, Peter Van der Stok <consultancy@vanderstok.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT)
Thread-Index: AQHVK7Xi/CWQui2aBEWZkjjOk8ibZKa06qOAgAJLZICAAmwboA==
Date: Thu, 04 Jul 2019 01:05:01 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DF2EA62@BLREML503-MBX.china.huawei.com>
References: <156150881090.31233.460341246895590440.idtracker@ietfa.amsl.com> <982B626E107E334DBE601D979F31785C5DF26D0C@BLREML503-MBX.china.huawei.com> <20190702164014.GT13810@kduck.mit.edu>
In-Reply-To: <20190702164014.GT13810@kduck.mit.edu>
Accept-Language: en-IN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.109.81]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/chRq4ecGB57BS83tGGvGN5wyuD4>
Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT)
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, 04 Jul 2019 01:05:20 -0000

Thank you Benjamin for the clarifications and rsp confirmations.
Also please find my reply [RJ] inline for the scenario you mentioned.

Thanks,
Rahul

> 
> I think this is a side note, but it seems like the timer mechanism for DelayDAO (and by extension, DelayDCO) are a bit fragile, as one party has to wait for the full timeout before sending the message (e.g., N22 in this example) that the other party is waiting the timeout to receive (e.g., N11).  So it seems like we are still susceptible to transport delay/jitter and race conditions at some point in the network, even if it's not the next-hop of the target node.  But if that's a property of DelayDAO from RFC 6550, it doesn't really make sense to try to address it in this document (and it's also possible I misunderstand the situation).
> 
> [RJ] DelayDAO and DelayDCO are mechanisms to reduce the control 
> overhead in the network. If an implementation chooses not to use it, 
> it will still work ok, albeit with more control overhead. Yes the 
> DelayDCO is modeled similar to DelayDAO and it is expected that a node 
> simply waits for the timer to expire before it could start sending the 
> corresponding message (DCO is this case, DAO in case of 6550). I am 
> not fully sure if I completely understand what you mean by 
> "susceptibility to transport delay/jitter" but i understand that there 
> could be race conditions. If the race conditions happen the worst case 
> problem would be slightly more control overhead. Race condition would not result in invalid states on any nodes.

I'm happy to trust that you've thought about the race conditions and they don't cause any real problems.  For completeness, though, I was just considering the case when the DAO from N22 to N11 arrives before/after the timout fires on N11, whether N11 would then try to send a DCO down and what would happen then.

[RJ] As you mentioned, there are two scenarios possible:
1. If the DAO from N22 to N11 arrives _before_ the DelayDCO timeout fires on N11
This is the regular positive case. The DelayDCO timer is defined so that N11 should be able to receive DAO from all possible paths before taking any action for route invalidation. If the DAO is received before DCO timer fires then the routes are updates from all possible paths (by receiving DAOs from all possible paths) and thus the DCO should not be sent down.
2. If the DAO from N22 to N11 arrives _after_ the timeout fires on N11
This is the case where an unnecessary DCO will be generated by N11 because N11 has not still received the DAOs from all possible paths. In this case DCO will initiate route invalidation along the path through N22 and the segment which has not received updated DAO will be marked for invalidation. But as soon as the new DAO reaches the paths would be updated again. So barring the unwanted control overhead of a DCO message, the routing state would be consistent once the new DAO is received from all paths.

The second scenario was not explicitly covered in the document even though the handling was present. I thought it would be better to put this explicit text after your comment.
I have added following in Section 4.6.3 :
	" It is still possible that a DCO is generated before all the updated	
 	   DAOs from all the paths are received.  In this case, the ancestor	
 	   node would start the invalidation procedure for paths from which the	
 	   updated DAO is not received.  The DCO generated in this case would	
 	   start invalidating the segments along these paths on which the	
 	   updated DAOs are not received.  But once the DAO reaches these	
 	   segments, the routing state would be updated along these segments and	
 	   should not lead to any inconsistent routing state."