[Rift] Device restart problem

<xu.benchong@zte.com.cn> Thu, 24 October 2019 08:52 UTC

Return-Path: <xu.benchong@zte.com.cn>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8EB2112006B for <rift@ietfa.amsl.com>; Thu, 24 Oct 2019 01:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id N_hsalwRuB3H for <rift@ietfa.amsl.com>; Thu, 24 Oct 2019 01:52:52 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn []) (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 8EB95120059 for <rift@ietf.org>; Thu, 24 Oct 2019 01:52:52 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown []) by Forcepoint Email with ESMTPS id A14C348082C748669D71; Thu, 24 Oct 2019 16:52:49 +0800 (CST)
Received: from njxapp04.zte.com.cn ([]) by mse-fl2.zte.com.cn with SMTP id x9O8qPbj090285; Thu, 24 Oct 2019 16:52:25 +0800 (GMT-8) (envelope-from xu.benchong@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Thu, 24 Oct 2019 16:52:24 +0800 (CST)
Date: Thu, 24 Oct 2019 16:52:24 +0800 (CST)
X-Zmail-TransId: 2afb5db16648b4091389
X-Mailer: Zmail v1.0
Message-ID: <201910241652249011192@zte.com.cn>
Mime-Version: 1.0
From: <xu.benchong@zte.com.cn>
To: <tonysietf@gmail.com>
Cc: <rift@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x9O8qPbj090285
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/SGrGxlztME2jnMr3zGoIAP5CaLk>
Subject: [Rift] =?utf-8?q?Device_restart_problem?=
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2019 08:52:55 -0000

Hi, Tony

There is a device restart problem

In draft-ietf-rift-rift-08 Figure 2, N-TIE of Leaf111 flooded to ToF21 via Spine111. Seq NR may be larger.

Leaf111 restarts and regenerates N-TIE. The random seq NR may be small, so that when Spine111 receives it, it will compare the seq NR and discard the new message.

According to the behavior of Appendix c.3.4 b.3, it is hoped that Spine111 sends DBTIE to Leaf111 to update seq NR.

However, according to the flooding range of N-TIE, this message cannot be sent out.

In this way, there will be a large number of invalid N-TIEs in the network for a long time (the default expire time of the protocol is 1 week)

Is this understanding correct? How does rift solve this problem?

Thank you!