Re: [trill] draft-ietf-trill-rfc7180bis-01

Donald Eastlake <d3e3e3@gmail.com> Tue, 24 February 2015 14:52 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 4BE231A8713 for <trill@ietfa.amsl.com>; Tue, 24 Feb 2015 06:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 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] 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 FyJU-lR2A0WZ for <trill@ietfa.amsl.com>; Tue, 24 Feb 2015 06:51:59 -0800 (PST)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 D89541A1BB3 for <trill@ietf.org>; Tue, 24 Feb 2015 06:51:58 -0800 (PST)
Received: by mail-oi0-f45.google.com with SMTP id i138so19620861oig.4 for <trill@ietf.org>; Tue, 24 Feb 2015 06:51:58 -0800 (PST)
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=9/zl2YfSNLZ2Tq3pqvwKJ5KXzfI4AOTchCfDn3mrmrY=; b=bj9A0fmpLtpUPXiSsflZyH9UHQLs/cVUD/Qf9gDqWLKJ8t+oM4NOrzKwJcGds/ut6f vK+yRfJL0+WS7vDfep360yMJ4Kv9C7AUFIU3ITVMxi8qLmt1d0Z7v/mLYGY4mZB+B+1j +beRuzzB/7jzuqQiaWOaUewIGKDkvoqPGNqPi6GXPxDvM3sN0Oy2gRzkISzZBuv5Fb+o AlZdWeelvLwY4TdQV0/gXtCTffuLkp2qFtE/krowbxlWUS0XWE/z5AWn9SB/n6XkKZIc rb1wR+k/hYYP/fwCpmkwdRx7rU8yXc5vBBgd3SZCTYHdoA4QRSMXdtgkGKQj6fK7a/W6 tnow==
X-Received: by 10.202.186.85 with SMTP id k82mr10656923oif.69.1424789518144; Tue, 24 Feb 2015 06:51:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.155.134 with HTTP; Tue, 24 Feb 2015 06:51:37 -0800 (PST)
In-Reply-To: <201502240347.t1O3lF30023522@skyhighway.com>
References: <20150214192017.15181.75809.idtracker@ietfa.amsl.com> <CAF4+nEEbJQQ3e_LDR_BhRMWrXf-tZzB8OFS7UDy3EEFJJL=sWA@mail.gmail.com> <201502240347.t1O3lF30023522@skyhighway.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 24 Feb 2015 09:51:37 -0500
Message-ID: <CAF4+nEEObmYCMGeHhmdhAACqoTbUekARDSSL-sLjVF-xyXukMw@mail.gmail.com>
To: gayle noble <windy_1@skyhighway.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/tWyqXF-aB3ckNc-lHqWKKI4ietg>
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] draft-ietf-trill-rfc7180bis-01
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: Tue, 24 Feb 2015 14:52:01 -0000

Hi Gayle,

Thanks for these comments. I pretty much agree with them all. Unless
there are some objections, I think these and the changes in the
message at http://www.ietf.org/mail-archive/web/trill/current/msg06666.html
can be incorporated into the draft.

On Mon, Feb 23, 2015 at 10:47 PM, gayle noble <windy_1@skyhighway.com> wrote:
> I read this draft and have the following thoughts/comments on communicating
> the technology >*grin*<
>
> 1)    Page 8  first paragraph
> (what is written)
> The link-state database at an RBridge RB1 can also contain information on
> TRILL Switches that are unreachable by IS-IS link-state flooding due to link
> or RBridge failures.
>
> (my suggestion)
> The link-state database at an RBridge, example RB1, can also contain
> information on TRILL Switches that are unreachable by IS-IS link-state
> flooding due to link or RBridge failures.
>
> 2) Page 8      2.2 Distribution Trees last sentence of this section
> (what is written)
> When calculating RPFCs for multi-destination packets, an RBridge RB1 MAY, to
> avoid calculating unnecessary RPFC state, ignore any trees that cannot reach
> to RB1 even if other RBridges list those trees as trees that other TRILL
> Switches might use.
>
> (my suggestion - add "such as" before RB1 and make state plural)
> When calculating RPFCs for multi-destination packets, an RBridge, such as
> RB1, MAY, to avoid calculating unnecessary RPFC states, ignore any trees
> that cannot reach to RB1 even if other RBridges list those trees as trees
> that other TRILL Switches might use.
>
> 3)  Page 8  ("packets is"  I think it should be packets are)
> In all cases, the normal Hop Count decrement is performed, and the TRILL
> Data packets is [are] discarded if the result is less than one or if the
> egress nickname is illegal.
>
> 4) Page 9  2.4.1 Known Unicast Origination
> (what is written)
> When an overloaded RBridge RB2 ingresses or creates a known destination
> unicast data packet, it delivers it locally if the destination is local.
> (my suggestion)
> When RB2, an overloaded RBridge, ingresses or creates a known destination
> unicast data packet, it delivers it locally if the destination is local.
>
> 5) Page 13 [I'd add a "the"]
>  A TRILL Switch that is only capable of pruning based on derived MAC address
> SHOULD calculate and use such derived MAC addresses from [the] multicast
> listener IPv4/IPv6 address information it receives.
>
> 6) page 20 5.1.1 MTU PDU Addressing
> (since the sentence is referring to the previous sentence which I missed on
> first reading)
> (it reads)
> As TRILL IS-IS PDUs, when multicast on an Ethernet link, they MUST be   sent
> to the All-IS-IS-RBridges multicast address.
>
>  (I'd change it as follows to avoid confusion)
> As TRILL IS-IS PDUs, when multicast on an Ethernet link, these
> multi-destination MTU-probe and MTU-ack TRILL IS-IS PDUs MUST be
> sent to the All-IS-IS-RBridges multicast address.
>
> 7) page  25 third paragraph of 8.1 E-L1FS Support (New)
> (exclamation mark used instead of a 1)
>  E-L!FS [EL1FS] will commonly be used to flood TRILL GENINFO TLVs and
> enclosed TRILL APPsub-TLVs [RFC7357].
>
> 8) Page 29 second sentence from end of page
> (exclamation mark used instead of a 1])
> Thus the use of this optional APPsub-TLV is backwards compatible with legacy
> lack of E-L!FS  [E-L1FS] support.
>
> 9) Page 31   The .fi snuck in and should be removed :)
>    5. Add a line to Table 4: TRILL Hello Contents in Section 9.1 as
>       follows:
>
>          LAN  P2P  Number  Content Item
>          ---  ---  ------  -----------------------------
>
>           M    M     1      Scoped Flooding Support TLV
>           .fi
>
> 10) page 33 10.2.1 Extended Hop Count
> (a period is used after the word "below" instead of a comma)
> Optionally,  TRILL switches can use a field composed of bits 14 through 16
> in the Flag Word, as specified below. [,] to extend this field to 9 bits.
>
> 11) page 34  first paragraph last sentence
> ("is" should be "are" as it refers to bits 14,15,16  and the Critical
> Reserved bit)
> If the optional TRILL Header Flag Word is present, bits 14, 15, and 16 and
> the Critical Reserved bit of the Critical Summary Bits is [are] zero.
>
> 12) page 34 (replace "but"  with "and")
> For known unicast traffic (TRILL Header M bit zero), an ingress TRILL switch
> discards the frame if it determines that the least cost path to the egress
> is (1) more than 64 hops but [and] not all TRILL switches on that path
> support the extended Hop Count feature or (2) more than 512 hops.
>
> 13) page 34 (I think tree path should be plural also  "from the ingress it
> more" should be "from the ingress is more"  and I would replace "but" with
> "and")
> For multi-destination traffic, when a TRILL switch determines that one or
> more tree path [paths] from the ingress it [is] more than 64 hops but [and]
> not all TRILL switches in the campus support the extended Hop Count feature,
> the encapsulation uses a total Hop Count of 63 to obtain at least partial
> distribution of the traffic.
>
> 14)  page 34 10.2.1.3 Transit Behavior
> (I think "file" should be "field")
> A transit TRILL switch supporting extended Hop Count behaves like a base
> protocol [RFC6325] TRILL switch in decrementing the hop count except that it
> considers the hop count to be a 9 bit file [field] where the extended Hop
> Count field constitutes the high order three bits.
>
> 15) page 37 11.2.1 Reference Updated
> (Capability spelt wrong)
> All references to [RFC7180] in the TRILL Parameters Registry are replaced
> with references to this document except that the Reference for bit 0 in the
> PORT-TRILL-VER Sub-TLV Capabilty [Capability] Flags is changed to
> [rfc6439bis].
>
> 16) Page 45 second to the last paragraph last sentence
> ("they" used where "there" should be used)
>  But if the network manager wants to control this, they [there] should be a
> way for them to configure the priority to be DRB of the TRILL switch ports
> on the link.
>
> 17) page 45/46
> (comma should be after "ports")
> But TRILL works fine as currently specified on a broadcast link with
> multiple      TRILL switches on it - actually multiple TRILL switch ports[,
> ] since a TRILL switch can have multiple ports connected to the same link.
>
> 18) page 49
> (I'd add "of a" to make sentence smoother)
>    Here is an example  [of a ] TRILL LSP PDU sent over a PPP link by the
> same source TRILL switch as the example in B.1.
>
> 19) Page 53
> (Since it changes from impersonal "implementer"  to personal "you" - "you
> should be the object from the start  so remove "an" add "you, the" and a
> comma after implementer. Also the word "if" is missing in the next
> sentence.)
> If /an/ [you, the] implementer, don't care about that optimization and don't
> mind some time outs being longer than they otherwise would be, you can just
> not bother changing the counter, even if you are using data plane learning.
> On the other hand, if you don't care about some time outs being shortened
> when they otherwise wouldn't, you could increment the counter for multiple
> VLANs even [if] you don't lose AF status on a port for all those VLANs but,
> for example, only one of them.
>
> 20) Page 56 D.2 Changes to [RFC6325]
> (number four   has the word "obtained" twice - remove one please
>>*sparkles*<)
>    4. Adoption of the change of the CFI bit, which was required to be
>       zero in the inner frame, to the DEI bit which is obtained /obtained/
>       from inner frame ingress or creation.
>
> 21) Page 56
> (Support spelt wrong)
> 5. Require all RBridge to suport [support] E-L1FS FS-LSPs flooding.
>
> 22) Page 58
> (Email is spelt EMail on some and Email on others. Should be consistent -
> Either change Radia Perlman's or the rest .. please)
>
> EMail: d3e3e3@gmail.com
> EMail: zhangmingui@huawei.com
> Email: radia@alum.mit.edu
> EMail: ayabaner@cisco.com
> EMail: anoop@alumni.duke.edu
> EMail: sujay.gupta@ipinfusion.com

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