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@xxxxxxxxxx; hu.fangwei@xxxxxxxxxx; Radia@xxxxxxxxxxxx; Donald > Eastlake (d3e3e3@xxxxxxxxx); ostokes@xxxxxxxxxxxxxxxxxxx; General Area Review > Team (gen-art@xxxxxxxx) > Cc: trill@xxxxxxxx; ietf@xxxxxxxx; 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@xxxxxxx Mobile: +1 (978) 394-7754 > ----------------------------------------------------