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 > ----------------------------------------------------
- Gen-ART review of draft-ietf-trill-esadi-07.txt Black, David