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 ----------------------------------------------------