Re: [trill] Parent node shift draft - relationship to resilient trees draft.

Donald Eastlake <> Wed, 28 December 2016 02:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B454F12949D for <>; Tue, 27 Dec 2016 18:07:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZUcGCYdqtl-w for <>; Tue, 27 Dec 2016 18:07:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67A96128E18 for <>; Tue, 27 Dec 2016 18:07:49 -0800 (PST)
Received: by with SMTP id x2so180901925itf.1 for <>; Tue, 27 Dec 2016 18:07:49 -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; bh=OheMbuLMn29s2PwRZdZsU1raHfIUFspkzpf/FJpQ+BM=; b=NYkcdE/zZLhcjVSueAbN1ozn6t3veCXAy0rosO5gV9B/beHLSue5nA6ehFLjjSXnHq dfqU7UdCLaHC5NWWG9QH+ocjOp/S6UTvgN/iwPPBMv8mEMlgwN3tHg5WZAx/MqXcU2hx XhHGkMjYRinu3WQsIpZX1JJawUv31bKQXhRPsZvFyzCKaA8bk+pgrvkICzjQH5mJCVK4 nsRC7k+4Pnp8YJRFMPWNr6sJJWi5yfW22Pf2Foqk7ZUh6lNo8YSNeYMEIVeHWl7JlEWP BDOgAfskSIlXVajb3pzLcs/wTiz2JoZzES5O6UiMSvpWc4MNG917hvQBeJLKAoTQaKS9 wd0w==
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; bh=OheMbuLMn29s2PwRZdZsU1raHfIUFspkzpf/FJpQ+BM=; b=Ts0xSKWm04OXwob3PWRt6waR48lwkq/JzBgLk1q1qyUfhB1GCQjAUsU/IowK4t/gAx +HB1phZ+emv7SVT/IsI/nhPDqTKO2wbq6lT/Led+SlFkFTOZbBWQq6tnoldcFI38cRcb 14D2KwNvm37RaAdwJz7DQZ8PRZJ10sHrAEgky5jzxT1J+WiStIau3X8zgXdFPEbILgO9 osV4A6SeS8RFBknOgl/AywfIl2Jr8Lb8crPyu/dAXB4PwxNnkyM4LvxIgft7Kn18j8W1 t91sQfPWPPfO6juVjoi3mz91IpDBFcpXUJL+1Vo6lJgj5YOET5ynUQkt0azoXnOhN4Ac siJQ==
X-Gm-Message-State: AIkVDXLqfoB8Up/S7FzL0KWTtqBIkw+obaxQOx0SnnwGoR92gf0H98HpxloY4ICiKQL66Pxz8Ek09uh9xvFJYw==
X-Received: by with SMTP id e145mr26597758ita.14.1482890868590; Tue, 27 Dec 2016 18:07:48 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 27 Dec 2016 18:07:33 -0800 (PST)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Tue, 27 Dec 2016 21:07:33 -0500
Message-ID: <>
To: R Parameswaran <>, "" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Subject: Re: [trill] Parent node shift draft - relationship to resilient trees draft.
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Dec 2016 02:07:50 -0000

Hi Ramkumar,

On Mon, Nov 28, 2016 at 2:50 AM, R Parameswaran
<> wrote:
> With regard to draft-rp-trill-parent-selection-01, this email tries to
> answer the question posed at the mike at IETF 97 Trill meeting - how does
> this draft relate to draft-ietf-trill-resilient-trees?
> This is examined below from two different considerations - overlap and
> extensibility.
> In summary, there is not much direct functional overlap between the two drafts
> that I can see, and draft-rp-trill-parent-selection-01.txt could possibly be
> extended to handle backup DT calculation for node failure scenarios. Details
> of these are broken out below:
> A. Considerations for Overlap:
> At a high level, draft-ietf-trill-resilient-trees relates to link
> protection, and
> defines the notion of a primary distribution tree (DT) and a backup
> distribution tree,
> where these trees are intentionally kept link disjoint to the extent possible,
> and the backup tree is pre-programmed in the hardware, and activated upon
> failure of the primary distribution tree.

I believe that is correct.

> draft-ietf-trill-resilient-trees considers the following algorithmic approaches
> to the building the backup distribution tree:
> 1. Pure operator config for links on the backup DT/manual generation of
>    affinity sub-TLV - this is very tedious and unlikely to scale or be
> implemented
>    in practice, and hence is disregarded in the analysis here.
> 2. Section Use of MRT algorithms (which will produce conjugate trees -
>    link disjoint trees with roots for primary and backup trees that
> are coincident on the same physical rBridge).
> 3. Section Once the primary DT is constructed, the links used in the
>    primary DT are additively cost re-weighted, and a second SPF is run to
>    derive the links comprising the backup DT. Affinity sub-TLV is used to
>    mark links on the back-up DT which are not also on the primary DT. This
>    approach can handle conjugate trees as well as non-conjugate trees (link
>    disjoint trees that are rooted at different physical nodes).
> 4. Section 3.2.2: A variation on the section approach, but without
>    affinity sub-TLV advertisement. Once the primary DT is constructed, costs
>    for links on the primary DT are multiplied by a fixed multiplier to prevent
>    them from being selected in a subsequent SPF run, unless there
>    is no other choice, and the subsequent SPF yields links on the backup DT.
> All of the approaches above yield maximally link disjoint trees, when applied
> as prescribed.
> Approach 4 above does not seem to use affinity sub-TLVs and instead seems to
> depend upon a network wide agreement on the alternative tree computation
> algorithm being used.
> Approaches 2 and 3 uses affinity sub-TLV on the backup DT, for links that are
> not already on the primary DT. The primary DT does not appear to use affinity
> sub-TLVs. Additionally, from an end-to-end perspective the backup DT comes
> into picture when the primary DT fails (this is effectively true even in the
> 1+1 protection mechanism and in the local protection case), and then again,
> only until the primary DT is recalculated. Once the primary DT is
> recalculated, the backup DT is recalculated as well, and can change
> corresponding to the new
> primary DT.
> draft-ietf-trill-resilient-trees cannot directly prevent/mitigate a
> parent node shift
> on the primary DT at a given parent node, and while usage of the affinity
> sub-TLV on the backup DT might confer a parent affinity on some nodes
> on the backup DT, these are not necessarily the nodes on which the
> network operator
> may want/prefer an explicit parent affinity. Further, the backup DT is
> only used on
> a transient basis, from a forwarding perspective.
> Given the above, I don't see much of a functional overlap between
> draft-ietf-trill-resilient-trees, and the draft-rp-trill-parent-selection-01
> draft.


> The two drafts can probably co-exist (personal opinion) as they have different
> goals, and solve different problems. Maybe its good to have some text in one
> of them, explaining the relationship to the other.

Since trill-resilient-trees is much further along in the process, it
might be better to add any such text to trill-parent-selection.

> B. Extensibility considerations:
> As called out in section 3, draft-ietf-trill-resilient-trees focuses on link
> protection.  However, the draft alludes to the possibility of using backup DTs
> for node protection, but considers it out of scope, while calling out some
> problems with doing so.
> On the other hand, draft-rp-trill-parent-selection-01 does not explicitly
> define the notion of a backup DT, and focuses on protecting parent child
> relationships  on the primary DT, but possibly can be extended to define the
> notion of a backup DT for node protection.
> In draft-rp-trill-parent-selection-01, if a sibling of the configured parent
> node (the node on which child affinity was explicitly configured) goes down,
> there is not much point in computing the backup DT corresponding to the downed
> node, because the forwarding state on the configured parent, and on other
> nodes in the network, will not change because of the already imposed affinity
> sub-TLV, binding the child nodes listed in the affinity sub-TLV to the parent
> originating the affinity sub-TLV, regardless of the presence or absence of the
> sibling node.
> But, implementations may need to take care to not disturb the hardware
> programming already in place, while the tree computation reconverges to
> (nearly) the same outcome as the prior computed tree, when the sibling
> node goes down.
> However, in the case where the parent node on which child affinity was
> configured goes down, it makes sense to configure a back-up DT with simply the
> Trill default parent selection rules, but with the tree calculation now
> excluding the configured parent node with the child affinity. The
> backup DT can be
> pre-programmed, and when the configured parent node is seen to go down,
> its affinity sub-TLVs can be discarded, and hardware programming can switch to
> forwarding with the backup DT state.
> There are other considerations that need to be thought through (e.g
> what if any other node (not parent, not sibling) goes down - do we
> need a backup tree?) , but
> draft-rp-trill-parent-selection-01 can possibly be extended in this
> direction if there
> is interest in pursuing this further. In any case, feedback is welcome.

Those are some interesting ideas. We could probably work on the
after/if the draft is adopted by the WG.

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

> thanks,
> Ramkumar