Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 16 September 2015 19:58 UTC

Return-Path: <spencerdawkins.ietf@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 8F1011A03A2; Wed, 16 Sep 2015 12:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 RngeCAPRbe1F; Wed, 16 Sep 2015 12:58:14 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 47C881A039C; Wed, 16 Sep 2015 12:58:04 -0700 (PDT)
Received: by vkhf67 with SMTP id f67so108802213vkh.1; Wed, 16 Sep 2015 12:58:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jj3ysA125oibMFpXYwiuA5yPgG9AWgWpfh+vy3R3zxA=; b=PpdFtvCOXQwcD8dukmwWJC6QC8iDVbax4viTvELDHdPrfUOKaY1qEUfT/jNSqbEBXK KlHIo7gOyofrzbsnecpaZSglqi5XuiGkcsc8wB/ce+1hB2hM/7dLnjU/fyKvnRr7Iv6s JK0/iDLaiJFrMTJ4Px1X8od/r71qvTiMud/yR5xiRU4F2twAn0Drc+pk/btzYKJniicG Dgm4zlMd6et3t8GiSlD3kCtvLk4LGhI9AWgwa2gzNds0H0FpILaHPlhRGu/42mG/XIES G8A2zt4kw4N7bkUQlR8pwEII3CVCDt5ixTLET1v/OOpvP22NA+Py4gjCGybCEzAAn6Ng wKxg==
MIME-Version: 1.0
X-Received: by 10.31.190.148 with SMTP id o142mr28562024vkf.67.1442433483368; Wed, 16 Sep 2015 12:58:03 -0700 (PDT)
Received: by 10.31.54.75 with HTTP; Wed, 16 Sep 2015 12:58:03 -0700 (PDT)
In-Reply-To: <4552F0907735844E9204A62BBDD325E7871CEEA3@nkgeml512-mbx.china.huawei.com>
References: <20150915212653.18348.80706.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E7871CEEA3@nkgeml512-mbx.china.huawei.com>
Date: Wed, 16 Sep 2015 14:58:03 -0500
Message-ID: <CAKKJt-fbN75CXLfQSLHUZQ2hiLO19w_v09FNVj3bt=+LUsiu8g@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: Mingui Zhang <zhangmingui@huawei.com>
Content-Type: multipart/alternative; boundary=001a11439d786371f6051fe2b714
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/SleEXYwD1jQF3m0fsLxCS8PGN-E>
Cc: "draft-ietf-trill-pseudonode-nickname.shepherd@ietf.org" <draft-ietf-trill-pseudonode-nickname.shepherd@ietf.org>, "trill-chairs@ietf.org" <trill-chairs@ietf.org>, "draft-ietf-trill-pseudonode-nickname@ietf.org" <draft-ietf-trill-pseudonode-nickname@ietf.org>, The IESG <iesg@ietf.org>, "trill@ietf.org" <trill@ietf.org>, "d3e3e3@gmail.com" <d3e3e3@gmail.com>, "draft-ietf-trill-pseudonode-nickname.ad@ietf.org" <draft-ietf-trill-pseudonode-nickname.ad@ietf.org>
Subject: Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)
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: <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: Wed, 16 Sep 2015 19:58:16 -0000

Hi, Mingui,

These responses all worked for me. Thank you for looking at my comments.

Spencer

On Wed, Sep 16, 2015 at 2:10 AM, Mingui Zhang <zhangmingui@huawei.com>
wrote:

> Hi Spencer,
>
> Thanks for the comments. Please see in-lines below.
>
> > -----Original Message-----
> > From: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com]
> > Sent: Wednesday, September 16, 2015 5:27 AM
> > To: The IESG
> > Cc: draft-ietf-trill-pseudonode-nickname.shepherd@ietf.org;
> > trill-chairs@ietf.org; draft-ietf-trill-pseudonode-nickname@ietf.org;
> > draft-ietf-trill-pseudonode-nickname.ad@ietf.org; d3e3e3@gmail.com;
> > trill@ietf.org
> > Subject: Spencer Dawkins' No Objection on
> > draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)
> >
> > Spencer Dawkins has entered the following ballot position for
> > draft-ietf-trill-pseudonode-nickname-06: No Objection
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-trill-pseudonode-nickname/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > This was an easy document for me to read through (I have some exposure to
> > TRILL but am not skilled in the art). Thank you for that.
> >
> > I did have some questions, but nothing at Discuss level.
> >
> > In this text:
> >
> > Introduction
> >
> >    Other methods are possible; for example the
> >    specification in this document and the specification in [MultiAttach]
> >    could be simultaneously deployed for different AAE groups in the same
> >    campus. It is RECOMMENDED that only one method be adopted in a TRILL
> >                  ^^^^^^^^^^^
> >    campus. For example, if the method is [MultiAttach] is used, TRILL
> >    switches need to support the capability indicated by the Capability
> >    Flags APPsub-TLV as specified in Section 4.2 of [MultiAttach]. If the
> >    method defined in this document is adopted, TRILL switches need to
> >    support the Affinity sub-TLV defined in [RFC7176] and [CMT]. For a
> >    TRILL campus that deploys both AAE methods, TRILL switches are
> >    required to support both methods.
> >
> > I'm not thinking that RECOMMENDED is an RFC 2119 RECOMMENDED, but
> > more broadly, I THINK this paragraph is saying, "using multiple methods
> on a
> > TRILL campus will work, but if you use multiple methods, all of the TRILL
> > switches on the campus MUST support both methods". Did I get that right?
>
> Yes, that's right.
>
> >
> > If so ... you might give some justification for adopting only one method
> (my
> > guesses were capital expense? operating expense? complexity in
> > troubleshooting?),
>
> All these concerns make sense, especially the increased complexity. The
> text will be updated to reflect this point.
>
> > and perhaps even some explanation why you might adopt
> > more than one method (I was guessing that you'd use more than one because
> > some of your equipment doesn't support the method you want to use, but if
> > TRILL switches have to support both methods, that isn't the reason, is
> > it?)
>
> When a method is adopted, it doesn't mean all RBridges in the campus have
> to support all features that are specified for the Active-Active Edge
> RBridges. There are lots of non AAE RBridges. They need only support part
> of the TLVs. For the non edge RBridges, they need support less.
> We admit the scenario that more than one methods are adopted because AAEs
> from different vendors could implement different methods.
>
> >
> > In this text:
> >
> > 3. Virtual RBridge and its Pseudo-nickname
> >
> >    Since RBv is not a physical node and no TRILL frames are forwarded
> >    between its ports via an LAALP, pseudo-node LSP(s) MUST NOT be
> >    created for an RBv. RBv cannot act as a root when constructing
> >    distribution trees for multi-destination traffic and its pseudo-
> >    nickname is ignored when determining the distribution tree root for
> >    TRILL campus [CMT]. So the tree root priority of RBv's nickname MUST
> >    be set to 0, and this nickname SHOULD NOT be listed in the "s"
> >                                   ^^^^^^^^^^
> >    nicknames (see Section 2.5 of [RFC6325]) by the RBridge holding the
> >    highest priority tree root nickname.
> >
> > what happens if this SHOULD NOT is ignored? Do things still work?
> >
>
> Since RBv is not a real pseudonode, it cannot let through transit traffic.
> It would cause packet loss in some kind of topologies if RBv is listed as
> the root. I think it's safer to use MUST instead of SHOULD. Thanks for the
> catch.
>
> Thanks,
> Mingui
>