Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06

Donald Eastlake <> Wed, 21 October 2015 14:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0AF141A19F2 for <>; Wed, 21 Oct 2015 07:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pR3qV5RsXMTY for <>; Wed, 21 Oct 2015 07:54:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 342CC1A024E for <>; Wed, 21 Oct 2015 07:54:46 -0700 (PDT)
Received: by oiev17 with SMTP id v17so30362777oie.2 for <>; Wed, 21 Oct 2015 07:54:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Xd6MA2z+CNZXeH9pAJME/8MEEtI9MhwMdb7TBWhzjwE=; b=FReNaWzMEq6IlP3NBz9SsajYeQcFticUr/CZs9i4Cs5DlZXQMwelhArQcP1kgciz5r +ktfe2GmEYmmEBSSXzeywXj7D+hhOn6D1EKQgW+8j508IAqMsLBCePwOThji03BYQkrr //FXiombK7YIfrrg3ElD6YQtcqMf56VYiszWUN5UGNBsvf6+LXYv1YzhLfQ7bqVoE/X+ nzlC8Tu5UWxSc+85ghniYiS4uOmxzeavmi/TqIbZ0ZFFnw3qUSZwX1J1jiaJJQWqS5dA 4KuWYe3p9bx6sVxfXFqdRjf6MPu67L6rn63dkTha3YO6obEvFPS+RagDRPAEXB980J6l crcQ==
X-Received: by with SMTP id l133mr6316391oia.0.1445439285657; Wed, 21 Oct 2015 07:54:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 21 Oct 2015 07:54:30 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Wed, 21 Oct 2015 10:54:30 -0400
Message-ID: <>
To: Meral Shirazipour <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Oct 2015 14:54:53 -0000

Hi Meral,

On Mon, Oct 19, 2015 at 8:02 PM, Meral Shirazipour
<> wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> Please resolve these comments along with any other Last Call comments you
> may receive.
> Document: draft-ietf-trill-rfc7180bis-06
> Reviewer: Meral Shirazipour (was originally assigned to another gen-art)
> Review Date: 2015-10-19
> IETF LC End Date:  2015-10-19
> IESG Telechat date: 2015-10-22
> Summary:
> This draft is ready to be published as Standards Track RFC but I have some
> comments .

Thanks. See below.

> Major issues:
> Minor issues:
> -[Page 5], Section 1.1: this section updates section 1.2 of RFC6325. The
> update is about conflict resolution between sections of the RFC.
> Shouldn't this bis highlight those conflicts if any?

I do not believe there are any real conflicts. RFC 6325 has some
general/introductory sections and some detailed technical sections.
The general sections, particularly Section 2, are written with a
pedagogical goal of giving the reader the best general understanding
and such general sections are not necessarily precise and do not, in
general, include every corner case. During the development of RFC
6325, some reader focused on such general descriptions and claimed
that the "conflicted" with the precise, detailed technical sections.
Thus Section 1.2 was added to RFC6325 to resolve this and make it
clear that the later detailed sections should be followed in case of
any such apparent "conflict".

I don't really remember exactly what motivated making the material
about precedence of sections in RFC 6325 more complete in RFC 7180 but
it was probably based on some comment.

The only change from Section 1.1 of RFC 7180 to this Section 1.1
draft-ietf-trill-rfc7180bis is updating of some other RFC numbers in
this section.

> -[Page 14], Section 3.4. Should this section have a MUST sentence just
> before the last sentence?
> "All RBridges in a campus MUST determine distribution trees in the same way
> "

I don't think so. The mandatory implementation of the distribution
tree computation provisions is elsewhere. The sentence you refer to is
just discussion of the consequences of failure to follow that.

> -[Page 10], Section , gives an example, then the first bullet after
> the figure explains the problem with that scenario and says "MUST NOT be
> locally distributed in native form ".
> Is it possible to clarify what should be done instead?

This section is about tunneling the frame to a neighbor that is
offering the OOMF service. It could be re-worded a little to use
"instead" rather than "before". The change would be

      The multi-destination frame MUST NOT be locally distributed in
      native form at RB2 before tunneling to a neighbor because this
      would cause the frame to be delivered twice.

      The multi-destination frame MUST NOT be locally distributed in
      native form at RB2 because this
      would cause the frame to be delivered twice. Instead it is
tunneling to a neighbor as provided in this section.

> -[Page 11], last line, "forwards the packet on that tree."
> Just checking if that is supposed to say "packet" or if it should say
> "frame" or "TRILL Data packet"?

It would be more consistent to say TRILL Data packet.

> Naming ("frame" or "TRILL Data packet") are used throughout,  but it would
> help to mention the convention at the beginning of the draft.

I believe the intent to is use "frame" for native frames to/from end
stations and "TRILL Data packet" or "packet" for TRILL encapsulated
packets between TRILL switches. This convention could be mentioned in
Section 1.3.

> Nits/editorial comments:
> -[Page 6], Section 1.3,  "RBridge - An alternative name for a TRILL Switch."
> To remain true to RFC7325, better to add Routing Bridge: "RBridge - Routing
> Bridge, an alternative name for a TRILL Switch."


> -[Page 15], Section 3.6 , "can implemented"--typo-->"can implement"


> -[Page 16], Section 3.6.1 , "program their hardware tables",
> is it assumed that TRILL fast path will only/always be HW based?

There are software implementations of TRILL. Probably better to say
"program their forwarding tables."

> -[Page 17], "RB1 is show with three ports"--typo-->"RB1 is shown with three
> ports"


> -[Page 34], "then behavior is as specified"---> "the behavior" or "then the
> behavior"


> -[Page 35], Section 10.2.2, "those capabilites"--typo-->"those capabilities"


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

> Best Regards,
> Meral
> ---
> Meral Shirazipour
> Ericsson
> Research