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(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------