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

R Parameswaran <parameswaran.r7@gmail.com> Mon, 27 February 2017 02:22 UTC

Return-Path: <parameswaran.r7@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953B4129A84 for <trill@ietfa.amsl.com>; Sun, 26 Feb 2017 18:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 L1RnK6p-Xw_n for <trill@ietfa.amsl.com>; Sun, 26 Feb 2017 18:22:40 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 9EA3E129610 for <trill@ietf.org>; Sun, 26 Feb 2017 18:22:40 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id u188so77618290qkc.2 for <trill@ietf.org>; Sun, 26 Feb 2017 18:22:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lj7KT+8whSVzcNdC18BQlZMR529UZIy92PJ67N1/Wcg=; b=bUtYigEypxnLi5XKIQddggsRhWh9/li8SU1a5y9NuiFqog7TYZndiRqA2KMKKLzCZe +9ktNJHFJZM8tP8Pqo7wygP+81fE+TGY4FqowDEHgQTH7pTYNLoDJ9oUNov2gEKDQk08 7Gckpq975cFJjjHxHeB5ASVJwZHpcbYV5UzglzGXM0GzQdCh525AYFncbdTZD+8hCyNU kYBGg4F1nqP0v9v+pl3h84iXIfhseYGUP2e9henzGEytoRT6NTw5UhaSSxtcKt0TLuRm aAV2fu1dTt1Ihg3pvK160CHRj6RyvHduiVve84QnXrGHfovutGWWNPKLGWt0KGptswe0 U39Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lj7KT+8whSVzcNdC18BQlZMR529UZIy92PJ67N1/Wcg=; b=UMl/a7NkNKYUYVZh5alwfKq0Qe5vh9isjOmPfISWQ9Bbi5CvK8u41PsKnA6Mb0IcNb hFqT8nBVe0kh7Hjs5drmq4zq/XiciirH+hEI8AmzQ3Gb4Cx7AOYNuuQm2zQApaBJib8b VIDzwkIT7HuQ2LwwkvrJbjkobwNsDczOObjD3gQTjA1EG/7FmHFPSJAlgE05IM7zaBAZ wKRkS+/QW0CFFBdmLEfV+AXXUPNPs+NYfbwcPbgJPZjLJYvdARbBV7/QnSta3Rdebh71 q3T1grwLlXHDJ3LplInMo6gAt1HKXyYWlM6csIwQ6YYCgdV8s1PmesXRwLmE6xYEDcg9 abgw==
X-Gm-Message-State: AMke39mECKr1NmfrNu4ff9Ped7DFCK1SmStWtQ9AKZ3YpScUZRSBlLzFA/kQqmxJz7w1INNqE3u+kKd8rqyNiQ==
X-Received: by 10.200.55.181 with SMTP id d50mr14850159qtc.140.1488162159553; Sun, 26 Feb 2017 18:22:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.34.234 with HTTP; Sun, 26 Feb 2017 18:22:39 -0800 (PST)
In-Reply-To: <CAF4+nEG130EYTJeut98U7He4Z8pLVV7E_tjhk++sN=pvJn7PYw@mail.gmail.com>
References: <CAGeBGG75ZQ1-nAecFYjEcu_2UYwno5x0Avv4XYKAt=zN+Qh+1A@mail.gmail.com> <CAF4+nEG130EYTJeut98U7He4Z8pLVV7E_tjhk++sN=pvJn7PYw@mail.gmail.com>
From: R Parameswaran <parameswaran.r7@gmail.com>
Date: Sun, 26 Feb 2017 18:22:39 -0800
Message-ID: <CAGeBGG4Y1+6STsmS8N63=pgjSU_2zq_Ouk0a0MJ+wrMFaQk6Mw@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/2fHVnyzQ03rpqIx0rrCFjy2LQHc>
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Parent node shift draft - relationship to resilient trees draft.
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Feb 2017 02:22:41 -0000

Hi Donald,

Please see inline:

On Tue, Dec 27, 2016 at 6:07 PM, Donald Eastlake <d3e3e3@gmail.com>; wrote:
> Hi Ramkumar,
>
> On Mon, Nov 28, 2016 at 2:50 AM, R Parameswaran
> <parameswaran.r7@gmail.com>; 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 3.2.1.1a: 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 3.2.1.1b: 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 3.2.1.1b 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.
>
> OK.
>
>> 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.
>

[RP]: Thanks for the prior review and questions - I have picked this
up, I have added
text (largely derived from this email thread) under section 7 with an upload,
posted as draft-rp-trill-parent-selection-02.

regards,

Ramkumar


>> 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.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com
>
>> thanks,
>> Ramkumar