[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.202.51.65 with SMTP id z62mr13588489oiz.0.1422311840698; Mon, 26 Jan 2015 14:37:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.104.104 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
MAJOR: 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. MEDIUM: 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. MINOR: 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. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com
- [trill] Shepherd review of draft-ietf-trill-aa-mu… Donald Eastlake