[trill] AD review of draft-ietf-trill-resilient-trees-08

Alia Atlas <akatlas@gmail.com> Mon, 18 December 2017 21:23 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 422F912D953; Mon, 18 Dec 2017 13:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iRYLq59nxwPo; Mon, 18 Dec 2017 13:23:42 -0800 (PST)
Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 1AA5C12D955; Mon, 18 Dec 2017 13:23:42 -0800 (PST)
Received: by mail-ot0-x22c.google.com with SMTP id b56so314622otd.10; Mon, 18 Dec 2017 13:23:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=O4RQq8Kau0B0X6K4Mkwx9wsh6ykAbRMAFZYv8QbQ1e4=; b=FWK0TH2LjXNpyu4N7vPud3NR5jtTZyC3BhFvIzOZ7jzjCn2yGftygq5EwcLqb+ed0T y5vZVlIzo1QLS1QD2VVFeINWUXBopmAyJokVRnEWnkxWVTeCYJClIh9IV+KQUknruJRB COdmARlPqk9Hq5nlWhZ/mNdog+MufIIulFWwrhaVIPmNDE+ZjkX8Kw8GPEVI3Fn1L01Z YBRdvCakw77G+zt+vRNbdMY94OsZ1rD0AM1UlvELJYFixRPPsO0jNUnQTZewIQGEc1mA loKi+aR5XZYO2R89lKVz+8jgiLb40fNbQZMD7tzpnPS7BFO3zWU6iuMDCiWaNKobQcx2 q5gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=O4RQq8Kau0B0X6K4Mkwx9wsh6ykAbRMAFZYv8QbQ1e4=; b=t/VpAp6v9FUC3jHveB4zcy64M1kQR86bC+87NEznSjrV/iggwfvnIWM9rINQR8NVRz fZtIggJ51gMuDRF49M9xhuCPiefOVHuA1HL+XEDzWLLhoK5EMMRFutw5OUxWH0QRExwN K/Wrla+g1lSn2HQmfwKAQDGhaehkfXh8gkfTG2eK0cEcJaEoZNt5ce1V2ReJ5mzmLkJr SyguZm69auO63ibWhdd/lN/+uH3jtoxGPF4dtedeNaHkX7SRJgcwOE3YfUwJRhOri2Df t0PQo7kTwbqkqRxCHDJI5GkGvKyDy79QpToBbvLQz84Xt7ysMJ208ZPaxdt5L9jo3kqR Fa5w==
X-Gm-Message-State: AKGB3mK2PVh/wUOvG5+pcQlvm9ZB6UvxO4gsNVt5ARlFJrZlUUp5E709 W3O944q9tPnHTWl0CtZqvF/Yz2FB7wb4Q/nkiHwuj4hZ
X-Google-Smtp-Source: ACJfBotFzzWzNVlqD33AviCwPOKGTjrE7EWXjP0wfvy8OZPKKHXXkhWsairMCqkinxy1spc1rKYpbe1fPoX4nQfFsqY=
X-Received: by with SMTP id h95mr823780otb.77.1513632220782; Mon, 18 Dec 2017 13:23:40 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 18 Dec 2017 13:23:40 -0800 (PST)
From: Alia Atlas <akatlas@gmail.com>
Date: Mon, 18 Dec 2017 16:23:40 -0500
Message-ID: <CAG4d1rcHAroLHgMXM_j+SrOK4zJ9yRMGzxjjKup2oR86Kk=bUw@mail.gmail.com>
To: draft-ietf-trill-resilient-trees@ietf.org, trill@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c03222ad727c40560a3f68e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/c3ROwZIcDpzF_FlY13jfxysHA2A>
Subject: [trill] AD review of draft-ietf-trill-resilient-trees-08
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Dec 2017 21:23:44 -0000

As is customary, I have done my AD review
of draft-ietf-trill-resilient-trees-08.
First, I would like to thank the authors Mingui, Tissa, Janardhanan, Ayan,
and Anoop
for their work on this document.

Unfortunately, I have several serious concerns about this document.

First, and most importantly, there is not a clear and mandatory algorithm
for computing the backup distribution trees that is given. Sec
provides a recommendation that is still not fully specified.
I do see the idea that the root of a backup distribution tree need not be
the same as the root of the primary distribution tree - but I see no
indication of what decides which the root is.  Perhaps it is the root of
the primary distribution tree?    What is computing the backup distribution
trees?  My assumption is that each RBridge does.  Can  a backup
distribution tree be associated with only one primary distribution tree?

Second, I don't believe that the suggested algorithm of raising the link
costs for links used in a primary distribution tree will work to find
maximally disparate paths.  Consider the simpler case with Suurballe's
algorithm  (https://en.wikipedia.org/wiki/Suurballe's_algorithm) that is
just looking for 2 disparate paths.   In that example, the shortest path is
A-B-D-F which gives no disjoint path between A and F - but different pairs
of paths are possible.

Obviously MRT (RFC7811) solves this issue - and it is possible to have
different roots for the RED and BLUE trees by simply creating a proxy node
that attaches to the potential roots.  There may be a bit of work to be
done - but it is similar to other proxy nodes used in RFC7811 and RFC7812.

You may have different solutions - and that is fine - but failing to fully
specify an algorithm and having what is specified not work is not ok.

Third, pulling back and clearly explaining the different pieces of this
technology is badly needed.  For instance:
    (a) The root for a multicast distribution tree computes a backup
distribution tree and identifies the root to use.
    (b) A PLR determines the backup distribution tree (how?)
    (c) Each RBridge computes its part of the backup distribution tree - by
pinning specific links into the backup distribution tree as advertised as
affinity links (??)
    (d) Is traffic looked for on the backup distribution tree?  How does a
merge point/receiver make that decision?

Some of these details are in the draft - but it is quite hard to pull out

Are there any implementations of this draft?