[trill] Shepherd review of draft-ietf-trill-aa-multi-attach-02.txt

Donald Eastlake <d3e3e3@gmail.com> Mon, 26 January 2015 22:37 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CAAAA1B2AE3 for <trill@ietfa.amsl.com>; Mon, 26 Jan 2015 14:37:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jFkE15flRBsQ for <trill@ietfa.amsl.com>; Mon, 26 Jan 2015 14:37:25 -0800 (PST)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D941B2AE4 for <trill@ietf.org>; Mon, 26 Jan 2015 14:37:21 -0800 (PST)
Received: by mail-oi0-f51.google.com with SMTP id x69so9620218oia.10 for <trill@ietf.org>; Mon, 26 Jan 2015 14:37:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=TAMrUvkGr1QhBtIjCA3LLBI1qUpiiBg2QRC1Aj+GRAw=; b=AlUAHo6P9r+0IOGuDT+NF60NEBDLkXtM8VvWlyZCuUwGIvEtOGWltUI3CqFuVO4rIb xbyNFQBbif8+xQSCoNOy2hkzPsOn7bdIKZ6dyGHonEfvcdEXSsRDXsVa0V6d+/N/hE8c C/BYK/B+gXcLAYDvefPKNEVVJ6faYYwd3xS3ZeYHReBHob8zwS0IwdCFDdAlPqR/9e/N /9fuxNsZUuZqEQ0FijxH/oj+PiM6B3t63JuTrcQIfp4wJVB1210GOwFVntPuQryohlaZ qtSyNn0vEwpWqvJNJw2gCTee5C8M0kbhvnOSfUTQZ8X4ZhnEGuUe3JCpSnEcsLCSuHSo dqAA==
X-Received: by with SMTP id z62mr13588489oiz.0.1422311840698; Mon, 26 Jan 2015 14:37:20 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 26 Jan 2015 14:37:00 -0800 (PST)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 26 Jan 2015 17:37:00 -0500
Message-ID: <CAF4+nEF0uRp+YBxqvk9VRXyq7+NJK=TQpbC62JwrQ5rbyg=ksg@mail.gmail.com>
To: "trill@ietf.org" <trill@ietf.org>
Content-Type: multipart/alternative; boundary=001a113ce0a006586c050d95c88a
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/6CHAfQGNj0ZTSxgqUsg4d6NNzlg>
Subject: [trill] Shepherd review of draft-ietf-trill-aa-multi-attach-02.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 26 Jan 2015 22:37:28 -0000


Use of the aa-multi-attach mechanism assumes that all the edge RBridges in
the campus support that mechanism if they are providing end station service
in the same Data Labels as any aa-multi-attach edge group. If this is not
true, the current draft says to not "establishing data connectivity" to
non-supporting RBridge by setting link costs to 2**24-1, which would cause
those link to not be used for least cost paths.

This does not seem like the best approach to me. It could lead to data
partitioning of the campus resulting is denial of service even to RBridges
not involved in aa-multi-attach at all. Furthermore, it might be desirable
to have active-active edge groups some of which use aa-multi-attach and
some of which used some other active-active method. But such data
partitioning would make this difficult since service with a different
active-active method would be interrupted by the partitioning due to some
RBridge that didn't support aa-multi-attach.

This sort of problem should be rare in practice because it is most common
for all the RBridges in a TRILL campus to be compatible. In cases where
this problem occurs, I think it would be better to fall back to
active-standby for any aa-multi-attach AAE group involved.


1) Due to use of E-L1FS FS-LSPs, draft-ietf-trill-rfc7180bis probably needs
to be normatively reference rather than an informational reference.

2) This draft specifies a Multi-MAC-Attach Capability Flags APPsub-TLV. The
draft needs capability flags but experience suggests that as a protocol
like TRILL develops you frequently end up needing more capability flags,
for a variety of purposes, than you initially though. On the other hand, it
makes development and testing easier if capability flag structures are
fixed length.

I recommend that the current Multi-MAC-Attach Capability Flags APPsub-TLV
be replaced by an Extended RBridge Capability Flags APPsub-TLV. It should
include a topology field so that we don't need a new one when
multi-topology TRILL is specified. I suggest 8 bytes of flags with two bits
being assigned as in aa-multi-attach and IANA Considerations for the
assignment of additional bits in the future.

3) To avoid confusion, the names of the aa-multi-attach specific TRILL
APPsub-TLVs created by this document should be prefixed with "AA-" (and
those created in draft-ietf-trill-pseudonode-nickname prefixed with "PN-"
as one of them already is).

4) The document should make it clear that all remote RBridges interested in
a Data Label that an aa-multi-attach AAE group is interested in MUST
participate in ESADI for that Data Label unless they support Option A.


draft-ietf-trill-pseudonode-nickname now uses "pseudo-nickname" rather than
"pseudonode nickname" and that terminology change should be reflected in
this draft.

The draft should state that both aa-multi-attach and pseudo-nickname (as
currently specified) could be deployed simultaneously in the same campus.

Since a new version of the link aggregation standard has been published, we
should refer to that 2014 version and mention Distributed Resilient Network
Interconnect (DRNI) as an alternative to MC-LAG.

I think a few more acronyms and terms should be added to Section 2.1 and a
variety of other minor editorial changes made. I'll send the details
separately to the authors.

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