Gen-ART review of draft-ietf-trill-esadi-07.txt

"Black, David" <david.black@emc.com> Mon, 14 April 2014 13:20 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B81D1A0484; Mon, 14 Apr 2014 06:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.873
X-Spam-Level:
X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 VLY__cycL83n; Mon, 14 Apr 2014 06:20:08 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id CD73C1A0494; Mon, 14 Apr 2014 06:20:04 -0700 (PDT)
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3EDJsfJ025680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2014 09:19:56 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s3EDJsfJ025680
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1397481596; bh=TzurfSxhx1crxzjb21l9IQpecwM=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=YGhiPNkFhliIcOzmMgEwi89Jgdc7ceAIEjmbbQvbEtL4u2Q00PCU6kKUzo9u+WYC7 gFPZARJ2kKSqvyQ4OHTmdOoFNzIo7bRsuORFcMm0rOgv6ZK/R8xZRc+gC9PbGWoVuP DPMWgj+7Fgde9fiUYrBpayvwKI6zXrLx1Oerg9Pw=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s3EDJsfJ025680
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Mon, 14 Apr 2014 09:19:36 -0400
Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3EDJZxt020247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 09:19:35 -0400
Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Mon, 14 Apr 2014 09:19:34 -0400
From: "Black, David" <david.black@emc.com>
To: "zhai.hongjun@zte.com.cn" <zhai.hongjun@zte.com.cn>, "hu.fangwei@zte.com.cn" <hu.fangwei@zte.com.cn>, "Radia@alum.mit.edu" <Radia@alum.mit.edu>, "Donald Eastlake (d3e3e3@gmail.com)" <d3e3e3@gmail.com>, "ostokes@extremenetworks.com" <ostokes@extremenetworks.com>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>
Date: Mon, 14 Apr 2014 09:19:34 -0400
Subject: Gen-ART review of draft-ietf-trill-esadi-07.txt
Thread-Topic: Gen-ART review of draft-ietf-trill-esadi-07.txt
Thread-Index: Ac9X5C1IRV0XGBZDQo+hNsgFemwTCQ==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C1D1C22@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public, Resumes
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Dw1aiDKbQ7WtEFmtzJID4oc2s-A
Cc: "ietf@ietf.org" <ietf@ietf.org>, "trill@ietf.org" <trill@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Apr 2014 13:20:13 -0000

The -07 version of this draft addresses all of the concerns raised by the Gen-ART
review of the -06 version.  I would have preferred to see stronger Security
Considerations text on usage (and non-usage of the Authentication TLV.  That said,
the text in the -07 version is an improvement, and I will leave any further
follow-up to the IESG.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Saturday, March 29, 2014 10:24 PM
> To: zhai.hongjun@zte.com.cn; hu.fangwei@zte.com.cn; Radia@alum.mit.edu; Donald
> Eastlake (d3e3e3@gmail.com); ostokes@extremenetworks.com; General Area Review
> Team (gen-art@ietf.org)
> Cc: trill@ietf.org; ietf@ietf.org; Black, David
> Subject: Gen-ART review of draft-ietf-trill-esadi-06.txt
> 
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-trill-esadi-06.txt
> Reviewer: David L. Black
> Review Date: March 29, 2014
> IETF LC End Date: April 1, 2014
> 
> Summary: This draft is on the right track, but has open issues
> described in the review.
> 
> This draft revises the ESADI specification for TRILL from its
> original form in RFC 6325.
> 
> Major issues:
> 
> The draft changes ESADI in a non-backwards-compatible fashion from
> its original specification in RFC 6325, but does not explain why this
> is ok.  That explanation needs to be provided, and if implementations
> of ESADI as originally specified in RF 6325 exist, that explanation
> needs to encompass coexistence and interoperability (or lack thereof)
> with such implementations.  That explanation probably belongs in
> Section 1.1, and could be expanded upon in Appendix A.
> 
> Overall, this draft is not self-contained - to a significant extent,
> it is written as if it were effectively a long collection of errata
> to the ESADI specification in RFC 6325.  That makes it difficult to
> understand - it would be better if this draft completely obsoleted
> and replaced the ESADI specification in RFC 6325, describing its
> changes, instead of providing specific text changes to portions
> of the RFC 6325 text.
> 
> Minor issues:
> 
> I don't understand the discussion in section 2 of it being "an
> implementation decision how independent the multiple ESADI instances
> at an RBridge are" in light of the clear statement that "the ESADI
> update process operates separately for each ESADI instance."  The
> example given involves database structure considerations that are
> specific to the node implementation and do not affect the independent
> updates for each ESADI instance.  There may not be an actual
> technical problem here, but at least the first chunk of text quoted
> in this paragraph of the review needs to be rewritten.
> 
> Also in Section 2:
> 
>    ESADI does no routing so there is no reason for pseudo-nodes in ESADI
>    and none are created.
> 
> Need to explain what a pseudo-node is before this sentence.
> 
> p.9, Figure 2 - explain how the receiver determines whether the inner
> Ethernet header contains a VLAN tag or FGL.  This also applies to Figure
> 3 on p.10.
> 
> p.10, Section 2.1:
> 
>    All transit RBridges forward ESADI packets as if they were ordinary
>    TRILL Data packets.
> 
> Need to explain what a "transit" RBridge is.  Between this and the
> above pseudo-node comment, I suggest adding an overview of the
> TRILL protocol to the start of Section 2.
> 
> p.11, Section 2.1:
> 
>    No "routing" computation or routing decisions ever have to be performed
>    by ESADI.
> 
> What is a ' "routing" computation' ??  This should be rephrased to
> contrast to what the non-ESADI TRILL usage of IS-IS does.
> 
> p.12, Section 2.2:
> 
>    If a VLAN or FGL ID
>    field within an ESADI-LSP PDU does include a value, that field's
>    contents is ignored.
> 
> This looks like it's an important requirement, so:
> 	 "is ignored" -> "MUST be ignored"
> 
> p.13, Section 3
> 
>   "SNPA/MAC address"
>    is not considered in this tie breaking and there is no "Port ID".
> 
> This is contrasting ESDI tie-breaking to a tie-breaking
> procedure that I'd guess is specified in another document; that needs to
> be explained, along with a reference to that document, preferably with
> the section number where the other tie-breaking procedure is specified.
> 
> Section 6 - explain where the 1470 byte number in the third paragraph
> comes from.
> 
> Section 8 - more should be said on whether/when the Authentication TLV
> should be used when ESADI conveys information from an authenticated
> registration.  In particular, if this recommendation for usage of the
> Authentication TLV with information from an authenticated
> registration usage is not a "SHOULD" or "MUST", an explanation is in
> order.
> 
> Nits/editorial comments:
> 
> There are lots of acronyms that are not expanded on first use, defined
> in the terminology section, or otherwise explained, e.g., DRB, Sz, CSNP,
> PSNP.  It may be ok to point to terminology/acronym definitions in RFC
> 6325.
> 
> Last sentence on p.8:
> 
> OLD
>    The outer VLAN tag will not be present if it was stripped by
>    an Ethernet port out of which the packet was sent.
> NEW
>    The outer VLAN tag will not be present for a packet on an
>    an Ethernet link that does not use VLAN tags.
> 
> idnits 2.13.01 got confused by the Section 4.6.2.2 reference to
> RFC 6325 in Section 4.1, and thought 4.6.2.2 was an IPv4 address -
> this is not a problem.
> 
> idnits also warned about possible pre-RFC5378 (2008) content.  This
> is probably not a problem, but please check with your AD.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------