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

Donald Eastlake <> Tue, 16 January 2018 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88DCC12D72F; Tue, 16 Jan 2018 09:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OIiiYAutFfDx; Tue, 16 Jan 2018 09:49:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8DA912D947; Tue, 16 Jan 2018 09:49:19 -0800 (PST)
Received: by with SMTP id 37so14341454otv.6; Tue, 16 Jan 2018 09:49:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WRgqeDc1kT4goPBRGbMwVhzONqmGk/RYAOqZiR4n0dE=; b=Fv2KMRzHyvr85f49LnWfsx0SL1fVX+7LhcbZvqURghfjs0Q8OH/2ydzT+InK+h0cVp XPn8DTGhN2UKmkbgTRRCKw1rW3xMGNQrdUyT/A3wQwvpEzbx5qznHxD9Gg3mUN7pdJY/ hKIg09OLRVGWuCWlF6US/ddulDZlAkebZplAZv9jWUGKsUZHkevpb3RoMj8MtbCZr+Cw GOr9w3qL9Wff0O302ST887Op81rnyLG/xI5hGV/ZOeCp/Nh5+b5WmQ4+anXJnH+WPp43 kvZG/bSGrLIRusj+pqIpg5F7Xsv1YhuTTzNkZHCR4fCIvi/6Gg2nYIy53xLhkb2vUAzL pRNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WRgqeDc1kT4goPBRGbMwVhzONqmGk/RYAOqZiR4n0dE=; b=iJDwoV0Xi2cqLu7LNwhd1qyRTQmF49jOZcGl3CD0DOPmcIe5PLTf8Cd2Z070hKtOPR tuniae/LtgmsnYIRHSE2GoEkxW25ifj0vZa3LXVsIPR1FNW97dS/6MbcsRJ0lZz6LinP BfEgpn0+HXfQMOkeuSXSFOvcDLWU7QQJ/elAeQqvrdQ+y5Q61si9cdQUSTKLiLpybzCv BKpDAlZM9ontCoqItGGa6wbSpqCVCiCzTiCVfAnoPKuzJjBWZL9dECy4tRCkI2opJrsO BOVvPZIMLW0TBtxpsIWsYzreN/64sFqoQ0N/ExoDj4wx1WEbLx5CScTODH6ZvCGEGzVO kVTw==
X-Gm-Message-State: AKwxytdXl1EwZV4mSGvXery4At1ejCAGdTm44ZoUqZT+dFRAwI+Ym9wx Ypw39yYVS5iDGXVrKKWqRh5u4O0M1xpukTLbLNbaMg==
X-Google-Smtp-Source: ACJfBovoZqjqvJwrVZGRb/IviZH6gEoBb7UZIRdYQGMeOS7nQ+7aAipYSaTBaPIiGJsJR79U85Jcay44OVK17IriQJE=
X-Received: by with SMTP id 1mr21323867otw.334.1516124958716; Tue, 16 Jan 2018 09:49:18 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 16 Jan 2018 09:49:03 -0800 (PST)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Tue, 16 Jan 2018 12:49:03 -0500
Message-ID: <>
Cc:, Alia Atlas <>
Content-Type: multipart/alternative; boundary="94eb2c0d13649979d10562e8599f"
Archived-At: <>
Subject: Re: [trill] AD review of draft-ietf-trill-resilient-trees-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Jan 2018 17:49:21 -0000


I've reviewed this draft in light of Alia's comments and have comments as

   - It should be clearer that each primary distribution tree may have at
   most one back-up tree associated with it. This is controlled by the highest
   priority root bridge RBridge which specified the roots of the back-up trees.
   - Behavior of an RBridge RB2 for multi-destination frames ingressed at
   RB1 depends on the protection mode of operation of RB1, particularly the
   difference between 1:1 and 1+1. Thus, either every RBridge in the campus
   must be configured with information about the mode of protection being used
   by every other RBridge (or at least every ingress RBridge) or RBridges must
   signal what mode they are using. It seems much more in keeping with TRILLs
   philosophy to use signaling which could, for example, be accomplished by
   use a 2-bit field in the Extended Capabilities which would be zero if no
   protection is supported and various non-zero values for various protection
   - I think the method given in the draft for calculating a back-up tree
   is reasonable and will provide substantial protection although it does not
   guarantee that the primary and backup trees are maximally disjoint and
   should not claim that.
   - Due to the TRILL RPF check, local protection seems limited to RBridges
   where the primary and backup trees fork.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

On Mon, Dec 18, 2017 at 4:23 PM, Alia Atlas <> wrote:

> 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  ('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
> clearly.
> Are there any implementations of this draft?
> Regards,
> Alia
> _______________________________________________
> trill mailing list