Re: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04

Donald Eastlake <d3e3e3@gmail.com> Tue, 11 August 2015 20:39 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 5B33A1B2A61 for <trill@ietfa.amsl.com>; Tue, 11 Aug 2015 13:39:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.74
X-Spam-Level:
X-Spam-Status: No, score=-1.74 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, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] 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 JNYRMgvSvb_U for <trill@ietfa.amsl.com>; Tue, 11 Aug 2015 13:39:00 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 537951B2A4A for <trill@ietf.org>; Tue, 11 Aug 2015 13:39:00 -0700 (PDT)
Received: by oihn130 with SMTP id n130so112308191oih.2 for <trill@ietf.org>; Tue, 11 Aug 2015 13:38:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mU/74fY5uAhzuUxV3FMzwfNthgSypbXdWqIfU1try5g=; b=0EtLCWs5Z2D85zCFg45nuziyMSyfK+iiSaKESHqxAUvsu6tO4xY5RmYCgUboEmZPpW TcJ9j9A+oioCyQYhgsJtiqGYgvsBHWdDkZpNqEG68V/No5lA96bQSUr4R+v6E+hCi7tI KplQkxliLNDxAsh1C434wjqA7BptSSTIYOHQNpRPuDcDpuvNI0kaHrNKbOneIxe7jCBg at9/5OXgrxyECDIUatxmRYZuB4TWfHZHYk1if09+WxA/5irSJpB3VZtub10+WIy+8bUS WmeoYJKqIGjvPnDPR+uk1FB9Xr3izX7jphrEBKuIBjzGjqQ8IKDIV5X1duH5Yfy6wIGk n0Wg==
X-Received: by 10.202.178.212 with SMTP id b203mr25910392oif.0.1439325539721; Tue, 11 Aug 2015 13:38:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.173.3 with HTTP; Tue, 11 Aug 2015 13:38:44 -0700 (PDT)
In-Reply-To: <CAF4+nEHxs5L3xjZJwC83MockLsj0tUu_bppWNZ6ej0RckjxOcg@mail.gmail.com>
References: <CAG4d1rc_zjEkSU+zyvEGR76hmnqbi363-p=frsK192qapCGrDA@mail.gmail.com> <4552F0907735844E9204A62BBDD325E787164186@nkgeml512-mbx.china.huawei.com> <CAF4+nEHxs5L3xjZJwC83MockLsj0tUu_bppWNZ6ej0RckjxOcg@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 11 Aug 2015 16:38:44 -0400
Message-ID: <CAF4+nEF-Bx8jT1S6FtXAUJpwc4=K1pyMiKnAg5am5hHV4WRB6w@mail.gmail.com>
To: "draft-ietf-trill-pseudonode-nickname@tools.ietf.org" <draft-ietf-trill-pseudonode-nickname@tools.ietf.org>
Content-Type: multipart/mixed; boundary="001a113b5ebc832cc5051d0f175d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/l28NLzSlndI-Afi4aV61DtS0gfM>
Cc: Tissa Senevirathne <tsenevir@gmail.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04
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: Tue, 11 Aug 2015 20:39:02 -0000

Hi,

I believe the mark ups in the attached resolve the AD comments on
draft-ietf-trill-pseudonode-nickname and also update some author info.
Could the authors please incorporate changes along these lines and
post a new draft or, alternatively, point out my errors and propose
different changes.

Thanks,
Donald (document Shepherd)
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Wed, Aug 5, 2015 at 11:07 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
> See below
>
> On Sun, Aug 2, 2015 at 11:45 PM, Mingui Zhang <zhangmingui@huawei.com> wrote:
>> Hi Alia,
>>
>> Please see comments inline with [mingui].
>>
>> From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Alia Atlas
>> Sent: Friday, July 31, 2015 6:30 AM
>> To: trill@ietf.org; draft-ietf-trill-pseudonode-nickname@tools.ietf.org; Don
>> Eastlake
>> Subject: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04
>>
>> ...
>>
>> Here are the details of my review:
>>
>> Minor concerns:
>>
>> 1) On p. 15 & 16: I'm a bit confused because on p. 15, it says "The basic
>> idea of DF is to elect one RBridge per VLAN from an RBv to egress
>> multi-destination TRILL Data traffic and replicate locally-received
>> multi-destination native frames to the CEs served by the RBv."  but
>> then on p. 16 in Step 4 part 1), it says: "RBv ports associated with
>> the same pseudo-nickname as that of the incoming port, no matter
>> whether RBi is the DF for the frame's VLAN on the outgoing ports
>> except that the frame MUST NOT be replicated back to the incoming
>> port".  This seems to be contradictory.
>>
>> [mingui] Let me explain the logic. If the RBridge in a RBv group receives a
>> BUM packet from a locally connected CE.  Other CEs will receive the packet
>> replicated by the DF only. Other RBridges will refrain from replicating.
>>    Having said that, it is also important that the DF never replicates the BUM
>> packet back to the incoming port (Say CE1 sends the BUM packet to the DF RB1
>> via port 1, then RB1 does not send the replicated BUM packet back to CE1 via
>> port 1.)
>>
>> Moreover, if one say CE1,
>>
>> CE2, and CE3 all in the same RBv, when CE1 sends a packet to RB2 and
>> RB1 is the DF for the particularly VLAN, then wouldn't RB2 forward the
>> packet to CE1 and CE2 while RB1 would also do so as the DF?
>>
>> [mingui] As explained above, RB2 will refrain from replicating since it is
>> not the DF.
>
> Probably the wording can be clarified.
>
>> Could you
>> please clarify what is causing the inconsistency and problem?  Maybe
>> the text in 6.1 on p. 18 helps describe that there are actually two
>> cases to the text on p. 16?
>>
>> [mingui] Yes, I agree.
>>
>> 2) On p.23 in Sec 9.1: There is no way of identifying what the type of
>> the LAALP ID is.  Assuming it is a number and meaning doesn't matter,
>> it would be really good to clarify that.
>>
>> [mingui] Agree.
>
> The general requirement is that the LAALP ID identify the
> active-active edge group of end stations and the LAALP for a
> particular group must be unique across the TRILL campus. As far as I
> know, currently the only type of value used for the LAALP ID is an
> 8-byte MC-LAG/DRNI ID. Perhaps the document should (1) indicate the
> general requirement, (2) state that if the length is 8 it MUST be an
> MC-LAG/DRNI ID, and (3) say that the type of LAALP ID value for any
> other length will be specified in a future document.
>
>> 3) In Sec 9.2: How can an LAALP ID be withdrawn from PN-RBv
>> APPsub-TLV?  Could you please describe that sequence?
>>
>> [mingui] I think, if RBx needs to just withdraw one LAALP ID, it will
>> refresh the previous announced LSP by omitting that LAALP ID from the LAALP
>> ID list in the PN-RBv APPsub-TLV.
>
> The APPsub-TLV (which is inside a TRILL GENINFO IS-IS TLV) is link
> state although it is not part of the base routing information LSP. It
> is distributed in E-L1FS FS-LSPs (support for which is required by
> draft-ietf-trill-rfc7180bis which is also in publication requested
> state). So the contents of the APPsub-TLV can be changed or it can be
> withdrawn by changing the FS-LSP fragment in which it occurs.
>
>> Thanks,
>> Mingui
>>
>> Thanks,
>> Alia
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com