[Rift] [RIFT] spine-tof links break => spine-leaf adjacencies go down?

Bruno Rijsman <brunorijsman@gmail.com> Thu, 23 April 2020 18:13 UTC

Return-Path: <brunorijsman@gmail.com>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD18C3A0E0F for <rift@ietfa.amsl.com>; Thu, 23 Apr 2020 11:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwcp6WfrtyfU for <rift@ietfa.amsl.com>; Thu, 23 Apr 2020 11:13:56 -0700 (PDT)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FB43A0E13 for <rift@ietf.org>; Thu, 23 Apr 2020 11:13:54 -0700 (PDT)
Received: by mail-ua1-x934.google.com with SMTP id c24so6755028uap.13 for <rift@ietf.org>; Thu, 23 Apr 2020 11:13:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9Xjq2iZU+IX+MZtfoDPDpx1yHq27oMx2RxgBWsVG6kM=; b=DQypptfJWFhAH+NKUgDCcSJ+8RXhG5Rt7BSuqgej9ll9pOXVpTE0SSbzfLVKsuto7S I2XCiN7giUEtHDQfObfp5Y2NLEo+c1sJ74zKfgwoHZdlx/uigYfy5+cBJUmawiLtw7e1 xTxH6auI7h6vaIGtBC7dn8dzrnQlE5izeaUL4v19iZyIjBPGW7Hmi1IWMzK4T13FDjiU amppc9kaTYcOILhgKCwCUtqUFzDSiMihRvLTsKG5z2NTyXgakeVX+2bPPyT4x9ex+07L GaRqDpJdo5B+Xbcd1GsjwDDONL8cAVFu2U8B2BdpzIPzbuS14/BZ3RL6z8gcu8M2mmne BKcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9Xjq2iZU+IX+MZtfoDPDpx1yHq27oMx2RxgBWsVG6kM=; b=DnXM9XvINR7yNuL1B2kkooZrOZKyABPGFEv9PL6F8vM0MOsOJCuKqyv++HANTAFXit Thp561bNtwqmjB5S5On/Hz4x0tnMhCvp7rG5Z8TYcs1Ux7St2EPWVy5479uCbAc5B1PF Ngh0v75zgQc/xDhlg6qLj6qsVQjO9AluiP1EEkNZnSkx4/acwLee0m3LL+T6FOSFJwL6 F20z2hI49t2BvPCiQvEm3GRiV+hDoWKPqZ3Jbsn/N6t6vSru1dh5dxduq25l2JvIhSli 9ImW2irIdNlbgrH6lmW/uJgHuMnI1zh4mUTb3QLfIeiHI3QRX97hxoXZm17tJLvzi3Ha /MEA==
X-Gm-Message-State: AGi0PuY+cTUm7iyk/+p3nQExa5vhEkkB7krwfFu9PFjEK/3YALaa3tbr 9KgipxrugPOsAFBf/B4vvVSpPMsqCzv7cg==
X-Google-Smtp-Source: APiQypIzEZZ6svBhUVH3ePU7MAqGdqSOkFDLsuPpoh2aKJgLrl4bj33mVvcKSQi6DD8yZhR61vUD0Q==
X-Received: by 2002:a67:f9d0:: with SMTP id c16mr4476310vsq.53.1587665632513; Thu, 23 Apr 2020 11:13:52 -0700 (PDT)
Received: from [192.168.30.24] ([181.174.102.214]) by smtp.gmail.com with ESMTPSA id f188sm971283vke.54.2020.04.23.11.13.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2020 11:13:51 -0700 (PDT)
From: Bruno Rijsman <brunorijsman@gmail.com>
Message-Id: <EC67D4C2-CEFF-46C9-866F-D0F32547CC64@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_15B48054-562E-4E52-98C0-70E9A7D849E2"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 23 Apr 2020 12:13:47 -0600
In-Reply-To: <d72ecfbd-3fe0-4eb7-94e9-dbecd0b8610f@Spark>
Cc: Tommaso Caiazzi <tommasocaiazzi@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Mariano Scazzariello <mscazzariello@os.uniroma3.it>, Leonardo Alberro Zimmermann <lalberro@fing.edu.uy>, Tony Przygienda <tonysietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Bruno Rijsman <brunorijsman@gmail.com>
To: "rift@ietf.org" <rift@ietf.org>
References: <5e909790.1c69fb81.e9d94.cb7e@mx.google.com> <d72ecfbd-3fe0-4eb7-94e9-dbecd0b8610f@Spark>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/CUaLpXOM9jRHuJ7FjGvb8d1u82U>
Subject: [Rift] [RIFT] spine-tof links break => spine-leaf adjacencies go down?
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, 23 Apr 2020 18:13:59 -0000

While testing negative disaggregation with Mariano, I discovered an "interesting" behavior in RIFT and I would like to check whether this behavior is expected or not. I am not saying the behavior is wrong, I was just surprised to see it and wanted to check whether this was intended when the protocol was designed.

Consider the following topology:

 TOF1     TOF2
   \       /
    \     /
     \   /
     SPINE
     /   \
    /     \
   /       \
 LEAF1  LEAF2

All adjacencies are 3way.

The TOFs have top-of-fabric level 24.

The leaves have level 0.

The spine uses ZTP to derive a level, so it ends up with level 23.

Now we break all links between the spine and its TOFs:

 TOF1     TOF2
   \       /
    X     X   <<< These adj go down (as expected)
     \   /
     SPINE
     /   \
    /     \   <<< Surprise: these adj also go down
   /       \
 LEAF1  LEAF2

At this point the spine node does not have any Valid Offered Levels (VOLs) because (see [1]):
(1) The levels from the TOFs are not valid because the adjacencies are down
(2) The levels from leaves are never accepted as valid offers

Hence, the derived level for the spine becomes "undefined".

Once the level of the spine becomes undefined, it stops accepting LIE messages from the leaves because a node whose level is undefined never accepts LIEs (see [2] below).

Since the spine stops accepting LIEs from the leaves, the old LIEs time out and the adjacencies go down.

My question is: it is normal and expected that breaking the links from the spine to the TOFs *also* causes the adjacencies between th spine and the leaves to go down?

[1] On page [86] of draft-11 it says:

 Valid Offered Level (VOL): A neighbor’s level received on a valid
 LIE (i.e. passing all checks for adjacency formation while
 disregarding all clauses involving level values) persisting for
 the duration of the holdtime interval on the LIE. Observe that
 offers from nodes offering level value of 0 do not constitute VOLs
 (since no valid DERIVED_LEVEL can be obtained from those and
 consequently ‘not_a_ztp_offer‘ MUST be ignored). Offers from LIEs
 with ‘not_a_ztp_offer‘ being true are not VOLs either. If a node
 maintains parallel adjacencies to the neighbor, VOL on each
 adjacency is considered as equivalent, i.e. the newest VOL from
 any such adjacency updates the VOL received from the same node.

[2] On page [45] of draft -11 it says:

 4. PROCESS_LIE:
 1. if lie has wrong major version OR our own system ID or
 invalid system ID then CLEANUP else
 2. if lie has non matching MTUs then CLEANUP, PUSH
 UpdateZTPOffer, PUSH MTUMismatch else
 3. if PoD rules do not allow adjacency forming then CLEANUP,
 PUSH PODMismatch, PUSH MTUMismatch else
 4. if lie has undefined level OR my level is undefined OR this
 node is leaf and remote level lower than HAT OR (lie’s level
 is not leaf AND its difference is more than one from my
 level) then CLEANUP, PUSH UpdateZTPOffer, PUSH
 UnacceptableHeader else