[trill] AD review of draft-ietf-trill-rfc7180bis

Alia Atlas <akatlas@gmail.com> Fri, 25 September 2015 16:13 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7B0061AC3E5; Fri, 25 Sep 2015 09:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.1
X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UZVDME_g2uSh; Fri, 25 Sep 2015 09:12:58 -0700 (PDT)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::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 1DD671AC3D4; Fri, 25 Sep 2015 09:12:55 -0700 (PDT)
Received: by obbmp4 with SMTP id mp4so85702773obb.3; Fri, 25 Sep 2015 09:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qZIcOgk4JiY7ILkB6cmWlRtstyoCfYOb6el/G3LsqS8=; b=gR19ieLNeWdCkwaZg8dMbAWPxvCcpnCRjDiFJzcEC3M7joJPy2FQwpfRP4mb5M4hFU rz3YfNG+qgYRAG4GYHFn6k70u0QUkDWOhtH+of9CCkpUipaoL4fBsnjAdvlmsI/bOAfn PSi9B93+QfLStJkxecIFvj9OE5No4tRm1CS9scPGNsxFcCUqnj0Eud/nCutAIMBEWcUb NdLA516NHnWBZpCT1RaijSRvTpson1oKfzHqVhXO39Vxo/uwrGMeG5bhDK8Kam5strFl yFUOH6sBiip2nlFxUxWHsFLORWOA/BV6BxpnqPkh2xf/z3w3oBMaUw9uknvuyKrZMHb/ 5CDw==
MIME-Version: 1.0
X-Received: by with SMTP id ws8mr3347363obb.54.1443197574499; Fri, 25 Sep 2015 09:12:54 -0700 (PDT)
Received: by with HTTP; Fri, 25 Sep 2015 09:12:54 -0700 (PDT)
Date: Fri, 25 Sep 2015 12:12:54 -0400
Message-ID: <CAG4d1rcpABEVfkFw0=-=b-=OiY4+jUVJD71OuO8qjRQXD5SQmw@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: draft-ietf-trill-rfc7180bis@ietf.org, trill@ietf.org
Content-Type: multipart/alternative; boundary=089e0153860cc4d0f40520949e05
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/SdwL2cXJNZ_MDyLfWC2GCDljV00>
Subject: [trill] AD review of draft-ietf-trill-rfc7180bis
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: Fri, 25 Sep 2015 16:13:00 -0000

As is customary, I have done my AD review of
draft-ietf-trill-rfc7180bis-05.  First, I'd like to thank the authors
Donald, Mingui, Radia, Ayan, Anoop, and Sujay for their work on this.

Due to some oddity in the datatracker, I didn't learn that the WG had
requested publication until I got a private email.  I apologize for the
delay in review.

Below are my comments.  The only one that is really blocking for starting
IETF Last Call is about Appendix C.   If we can get the comments resolved
and a new draft issued before next Thursday, then this draft should be able
to make the Oct 22 telechat.

1)In Sec 8.2: " Control packets can be ordered into priority classes as
shown below.
   Although few implementations will actually treat all of these classes
   differently, lower numbered classes SHOULD NOT be treated as lower
   priority than higher numbered class."

  Can you clarify what the point of listing these different priority
classes, if the lower number classes aren't lower priority & treated that

2) Sec 8.4:  I would really like to see an explanation for why the Nickname
Flags APPSub-TLV is needed.  I see the description and efforts to clarify
edge cases, which is great, but nothing that says "This is the problem a
Nickname Falgs APP sub-TLV is solving and the types of problems additional
flags might solve in the future."

3) In Sec "   3. If the Hop Count is zero, it is set to the
maximum value of 63 and
      the extended Hop Count is decremented."  What happens to the Critical
Bit Summary when the extended Hop Count goes to 0?  I don't see any mention
of it after the ingress RBridge setting it.

4) In Sec 10.2.2: "The meaning of the possible non-zero values of this
2-bit field (1, 2 or 3) is implementation dependent."  Is this assuming
that the zero value has a specific meaning of being unset or something
else?  Please clarify.

5) In Sec 10.3: "Finally,   there is the Non-Critical Ingress-to-Egress
field, the top two bits
   of which are specified herein as the Extended Color field."  The figure
shows bits 27 and 28 of the word, which are the low bits of the field - not
the top 2 bits.

5) Appendix C makes me uncomfortable in a Proposed Standard RFC.  Either
you are loosening the restrictions in a normative way or not...  This reads
like an "implementation hints to not quite conform".  Can you and the WG
figure out a better plan?

Thanks again,