[RTG-DIR] RtgDir Early review: draft-ietf-roll-rnfd-02

Victoria Pritchard <pritchardv0@gmail.com> Mon, 27 November 2023 21:44 UTC

Return-Path: <pritchardv0@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 68597C15106C; Mon, 27 Nov 2023 13:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Status: No, score=-1.854 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NebxhirWYDT8; Mon, 27 Nov 2023 13:44:18 -0800 (PST)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81578C151061; Mon, 27 Nov 2023 13:44:15 -0800 (PST)
Received: by mail-ot1-x32b.google.com with SMTP id 46e09a7af769-6d7e51638e7so2945027a34.1; Mon, 27 Nov 2023 13:44:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701121454; x=1701726254; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=QrBlswmY3AQGjUVTcln0WNrBqs12jZQERhX9p5UP5TM=; b=jsLH76tf6coPc5GjvXswwIYZpsHcBbBizY5NWH7sG1lwxvvcgDnXbJVWYjk/Eb4LJq AkAntkJHZ4wsgLflSdn6Ne31b991SM5ZB0korLul9gaG6g8PTSekXXMEgdgMi8RA3I7A fZg8SPUnlqKrD1gProI8sXuZPF9+dSPh0EWDMwKk0J4bAP0xGHjxvaPUzAnXfMVIO0gm YUTO24XPst08dIDf71W3iUFprxZjwkATHZHx7/ASjCrxigHREydQ6FpcqSG2QBNjODRP kFgT/dk/2YtfRgIulOTWBT/L+JaRpGdxxTz3qz0BF43JdXhoed1bSRSxgdK/qW2PdmbD VnMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701121454; x=1701726254; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QrBlswmY3AQGjUVTcln0WNrBqs12jZQERhX9p5UP5TM=; b=GpkNNgataD3b350sPbezeIdg/OgT1nzdjv+LpgvGk6MyfBFSipf7/BJzHznotF+klx nCJaVCmmQWRbMrPRtt4Blt+RNReVOG/OscGg7EbboaXo1CKpQBnA6LnR6YSJZNFI/nQ5 U+biusjRheeANbUtlf2sLyU1uFlyIjxEYxDvnr7+HhcRADx2UGUf8hLdCs5SPOLfVvwB pUt5zDg6ol4TnPM06Cy8DAU1XMfn/kaAKBV7dnGwEKXMjLm6V3dxS1KLeHrnkSkZjtem EJxZgbxcgdIseqyj7cuE2Qv3c2nqhblRZpxJplgNk1b6fSXb9tOixqnJ0WT0vAFItsUW YUxg==
X-Gm-Message-State: AOJu0YwIzx9P1Hbj5MYQiuxHW/uoIx/IHWcBpta9iCsmSYIXjVWpcFZ7 blGoc03D0PHQvSa/NoTIV/5LaGi4qYlK/KG947XVVmEb2Ck=
X-Google-Smtp-Source: AGHT+IELyWA0VCbBY5u1Z89zRk2kkMa/c07bXi+1xt3Gvr8l2Q9OJeB90QF0T1SxhZ3fwpyN7DuElk/6U9YrGbp9PbI=
X-Received: by 2002:a05:6830:456:b0:6d3:19bf:2d16 with SMTP id d22-20020a056830045600b006d319bf2d16mr14874069otc.12.1701121454154; Mon, 27 Nov 2023 13:44:14 -0800 (PST)
MIME-Version: 1.0
From: Victoria Pritchard <pritchardv0@gmail.com>
Date: Mon, 27 Nov 2023 21:44:03 +0000
Message-ID: <CA+fLEh+B9Njz=BDqQw0X8ePVLu0m4u_pe43DZURmFhW=i7+zOg@mail.gmail.com>
To: roll-chairs@ietf.org, draft-ietf-roll-rnfd.all@ietf.org
Cc: rtg-dir@ietf.org, roll@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fea857060b293389"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/XXA90ID24LnIm8Rc2pKZFCmQQAA>
Subject: [RTG-DIR] RtgDir Early review: draft-ietf-roll-rnfd-02
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Nov 2023 21:44:22 -0000


I have been selected to do a routing directorate “early” review of this

The routing directorate will, on request from the working group chair,
perform an “early” review of a draft before it is submitted for publication
to the IESG. The early review can be performed at any time during the
draft’s lifetime as a working group document. The purpose of the early
review depends on the stage that the document has reached.

For more information about the Routing Directorate, please see

Document: draft-ietf-roll-rnfd-02
Reviewer: Victoria Pritchard
Review Date: 27/11/2023
Intended Status: Standards Track

I have some minor concerns about this document that I think should be
resolved before it is submitted to the IESG.

In general, I found this to be well written, though some things explained
later in the draft would have helped understanding if explained earlier,
and a few points don't have the reason explained, which I think would also
help. Some clarification in these areas would be nice to include.

Comments/questions below.

Kind regards,

3 - "each node running RNFD" - Would all nodes need to participate? I
suppose the benefit would be limited if not? Also, if not all nodes
participate, some will continue to advertise a finite rank, would this
cause others to think the root is there? Maybe that's no worse than without
RNFD... those nodes using RNFD will look at the CFRCs and the LORS value,
assuming enough nodes are participating.

3.2 - negativeCFRC - says that this shows "sentinels that have considered
or still consider the root node as dead" - given the description in 5.2
that a node can go from LOCALLY DOWN to UP by re-adding itself to the
positive CFRC, i.e. they dont still consider it down, this might be phrased
better as "sentinels that consider, or have previously considered, the root
node as dead".

Similarly, positiveCFRC counts the number of times sentinels have
considered the root node as alive. A count in the positive CFRC doesnt mean
its still considered alive, as there could be a matching bit in the
negativeCFRC. As the last paragraph says, it's the difference between
positive and negative which shows how many sentinels consider the root as

4.2 What's the significance of having bit lengths be prime numbers?
Why if all positive bits are 1, should all negative bits also be 1? Is this
to indicate "globally down" as referred to in 5.3? i.e. using all the bits
not only the "prime number" of bits.
self() - selects the bit uniformly at random - will multiple sentinel nodes
select the same bit? Especially when nearing saturation?
Why 63% for saturation? Is it related to the probability of 2 sentinels
choosing the same bit?

5.1 Based on later discussion about the CFRC length, I assume the node
cannot send any CFRCs until it has received a message containing them, so
that it knows the length of the fields?

5.1 when changing role to acceptor, the rules state but dont explain why
the node MUST NOT modify its values, in particular negativeCFRC. I think
it's because the correct setting is already applied? (e.g. if already
globally down or locally down, the negativeCFRC has already been updated)

5.2 - paragraph that mentions "previous conditions 2-4": Why wouldn't it be
able to set LORS back to UP if the saturation was already over 63%
(condition 2)? Makes sense that saturation would mean the CFRC can't be
added to, but if the root is deemed to be up, why can't the node hold that
state locally? Does it have any impact if this remains at LOCALLY DOWN?

5.2 final paragraph
To re-add itself, it sets a new (uniformly selected) bit in the positive

If saturated is TRUE, does this mean the number of bits is almost used up?
Is 63% then a 'sensible' value, based on the fact that a number of
sentinels could be updating the CFRC at any one time and the saturation
value could end up well above 63% when all the updates are distributed?

If many sentinels have reported that the root is down, and then want to
report it back up, is there a risk that the saturation point will be
reached and they wont be able to add themselves to the positive CFRC again?
(Answered later - CFRC length can be extended - could consider reordering
these sections).

5.4 The DODAG root chooses bit length for the CFRCs? Does it start with
CFRCs set to zero? Does the root have to advertise the number of bits
before any nodes can become a sentinel? How does it increase the number of
bits (what are the CFRC values set to when it increases?), and how do the
sentinels react?

If a node didnt add itself to the positive CFRC because the saturation was
true, should it then add itself if it sees the number of bits increase (and
the saturation has gone back below the threshold)?

5.4, 5.5, 5.6, seem in the wrong order... questions I had while reading the
early sections were answered later. e.g. 5.4 - how do the nodes react when
the root changes the number of bits?

5.6 - how does the root extend the number of bits, does it merge from any
heard bits already or start fresh from CFRCs with all bits set to zero? If
a node receives a CFRC with more bits, how does it know which is its bit to
set? Can it assume its previous counter is not present when it adds itself
again as detailed in 5.6?

6. If the positive CFRC becomes saturated with little or no increase in
negative CFRC, wouldn't that mean the network is behaving well, and all the
sentinels say the root is alive? Would issuing a new DODAG version disrupt
things unnecesaarily? Or would it mean only the closest/fastest nodes would
have become sentinels, and is it then better to use the probablilty
mechanism to get a different spread of sentinels?