-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3(_at_)gmail(_dot_)com]
Sent: Saturday, April 05, 2014 11:23 AM
To: Black, David
Cc: zhai(_dot_)hongjun(_at_)zte(_dot_)com(_dot_)cn;
hu(_dot_)fangwei(_at_)zte(_dot_)com(_dot_)cn;
Radia(_at_)alum(_dot_)mit(_dot_)edu;
ostokes(_at_)extremenetworks(_dot_)com; General Area Review Team
(gen-art(_at_)ietf(_dot_)org);
trill(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: Gen-ART review of draft-ietf-trill-esadi-06.txt
Hi David,
Thanks for this very thorough review. See my responses below:
On Sat, Mar 29, 2014 at 10:23 PM, Black, David
<david(_dot_)black(_at_)emc(_dot_)com> wrote:
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 RFC 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.
This was a considered decision of the TRILL WG. At least since the -02
version in February 2013, the ESADI WG draft has had ESADI-LSP
provisions that were incompatible with RFC 6325 ESADI for the purpose
of accomodating orders of magnitude more LSP fragments. This text in
the draft, which originally used a somewhat ad hoc change from IS-IS
LSPs to accomodate additional fragments, was posted to the list
without objection before being incorporated. Since a standard IS-IS
way of doing this was later in process in the ISIS WG, the ESADI draft
was changed to follow this more standard way of providing for more LSP
fragments and a new WG Last Call done in the TRILL WG specifically on
this issue. See
http://www.ietf.org/mail-archive/web/trill/current/msg06037.html
http://www.ietf.org/mail-archive/web/trill/current/msg06009.html
In Appendix A (Changes to [RFC6325]), how about replacing items 2 and
3 in the list as follows (includes fixing a typo in item 3):
OLD
2. The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads
is changed from the base IS-IS format to the Extended Level 1
Circuit Scoped format in [FS-LSP].
NEW
2. The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads
is changed from the base IS-IS format to the Extended Level 1
Circuit Scoped format (E-L1CS) specified in [FS-LSP]. This
change is not backwards compatible with [RFC6325]. It is made in
light of (a) the very limited, if any, deployment of [RFC6325]
ESADI, and (b) the 256 times greater information carrying
capacity of the E-L1CS format compared with the base IS-IS
format. It is anticipated that this greater carrying capacity
will be needed, under some circumstances, to carry end station
addressing information or other information that is added to
ESADI in the future.
OLD
3. Unicasting of ESADI PDUs is supported including replacing Section
4.6.2.2 of [RFC6325] with the next text give in Section 4.1 of
this document.
NEW
3. Unicasting of ESADI PDUs is optionally supported including
replacing Section 4.6.2.2 of [RFC6325] with the new text give in
Section 4.1 of this document. This unicast support is backwards
compatible because it is only used when the recipient RBridge
signals its support.
See possible replacement below for the first paragraph of Section 1.1
that includes a condensed version of this additional material
concerning backwards non-compatibility.
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.
All of the changes to ESADI are described in Appendix A.
If the ESADI related material in RFC 6325 was entirely contained in
one contiguous area of RFC 6325, it would have been easy to write this
draft as simply obsoleting and replacing that area of RFC 6325. The
largest such monolithic block on ESADI in RFC 6325 is Section 4.2.5
(The TRILL ESADI Protocol), including its two subsections ("4.2.5.1
TRILL ESADI Participation" and "4.2.5.2 TRILL ESADI Information"). All
of that is obsoleted and replaced by this draft. However, there are
other non-contiguous parts of RFC 6325 necessarily affected. For
example, Section 4.6 of RFC 6325 describes how to handle every
possible type of frame that might be received; since an ESADI PDU is
one such type of frame, it is necessary to change Section 4.6.2.2
("TRILL ESADI Frames") of RFC 6325.
There is really no substitute for having a general familiarity with
RFC 6325 in understanding this document. Although I have seen IESG
members criticize statements such as "Familiarity with X is assumed."
when X is a normative reference, on the grounds that familiarity with
all normative references is automatically assumed, perhaps some such
statement is warranted in this case.
In addressing both of your issues here, the first paragraph of Section
1.1 could be changed as follows:
OLD
This document updates [RFC6325], the TRILL base specification,
replacing the description of the ESADI protocol in Section 4.2.5 of
[RFC6325], providing more detail, and prevailing over [RFC6325] where
they conflict. The changes are summarized in Appendix A. These
changes are not backwards compatible because, among other things,
they change the format of ESADI-LSPs.
NEW
This document updates [RFC6325], the TRILL base protocol
specification, obsoleting and replacing the description of the
ESADI protocol (Section 4.2.5 of [RFC6325] including all
subsections), providing more detail on ESADI, updating other ESADI
related sections of [RFC6325], and prevailing over [RFC6325] in any
case where they conflict. For this reason, familiarity with
[RFC6325] is particularly assumed. These changes are not backwards
compatible because they change the format of ESADI-LSPs to
substantially increase the amount of information that can be
carried. These changes are further discussed in Appendix A.
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.
Two things motivated the text you cite in Section 2: (1) ESADI uses
multiple instances of the flooding process for the purpose of limiting
the flooding to the TRILL switches that have expressed interest in a
particular Data Label. RFC 6822 specifies a different type of IS-IS
"instance" and there is some implication in 6822 of fault and
performance isolation between RFC 6822 instances. Although this
document says its instances are not the same as RFC 6822 instances,
someone might still have the impression that ESADI instances are
necessarily to be implemented inside a TRILL switch is a highly
isolated manner. This text is to emphasize that the extent to which
the execution of different ESADI instances are isolated within a TRILL
switch is an implementation decision. (2) Perhaps a symptom of item 1:
in early discussions of ESADI, there were multiple complaints that
maintaining 'so many different link state databases' in a TRILL switch
would be an undue burden. So the text here specifically mentions that
the databases for all ESADI instances at a TRILL switch can be merged
(with an appropriate marker in each record saying which instance it
belongs to).
While the IETF generally standardizes bits on the wire and not
internal implementation details, the above concerns lead to these few
sentences to dispel any false impression. I do not really see how
there can be much confusion since the draft also says, as your point
out, "But the ESADI update process operates separately for each ESADI
instance and independently from the TRILL IS-IS update process.". I
suggest the following change:
OLD
It is an implementation decision how independent the multiple ESADI
instances at an RBridge are.
NEW
This specification does not constrain how coupled or independent
the multiple ESADI instances are in their implementation internal
to an RBridge.
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.
I do not think this document is the right place for a detailed
explanation of pseudo-nodes. How about changing to the following:
ESADI does no routing calculations so there is no reason for
pseudo-nodes in ESADI and none are created (Pseudo-nodes [IS-IS]
are a construct for optimizing routing calculations.)
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.
I'm not sure this draft is the place for a detailed explanation but I
have no problem adding the already existing reference "[RFCfgl]" to
both figures right after where they say "VLAN or FGL Data Label (4 or
8 bytes)". That referenced document [RFCfgl], which is in the RFC
Editor's queue, explains this.
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.
How about just eliminating the word "transit", which I don't think is
necessary, and changing the sentence in question to
All RBridges forward ESADI packets as if they were ordinary TRILL
Data packets [RFC6325].
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.
How about the following change:
OLD
No "routing" computation or routing decisions ever have to be
performed by ESADI.
NEW
No "routing" calculation (least cost path or distribution tree
construction) ever has to be performed by ESADI.
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"
OK.
p.13, Section 3
"SNPA/MAC address"
is not considered in this tie breaking and there is no "Port ID".
This is contrasting ESADI 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.
The other document is [rfc6327bis] which is referenced. However, this
reference can be made clearer. How about
OLD
Generally speaking, the DRB election on the ESADI virtual link (see
Section 2.1) operates similarly to a TRILL IS-IS broadcast link
[rfc6327bis] with the following exceptions:
NEW
Generally speaking, the DRB election on the ESADI virtual link (see
Section 2.1) operates similarly to the DRB election on a TRILL
IS-IS broadcast link, as described in Section 4.2.1 ("DRB Election
Details") of [rfc6327bis], with the following exceptions:
Section 6 - explain where the 1470 byte number in the third
paragraph comes from.
How about adding the following at the end of the relevant paragraph,
just before the Section 6.1 header:
(As stated in Section 4.3.1 of [RFC6325], 1470 bytes was chosen to
make it extremely unlikely that a TRILL control packet, even with
reasonable additional headers, tags, and/or encapsulation, would
encounter MTU problems on an inter-RBridge link.)
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.
Consider the following: we have a network with secure trunk links
between trusted TRILL switches but in some cases those switches are
connected to end stations via 802.11 Wi-Fi links. It seems entirely
reasonable to use 802.11 authentication in allowing end stations to
connect due to the inherent accessiblity of radio links, but might not
be necessary to use authentication on ESADI PDUs between TRILL
switches.
In any case, if there is a concern about forged packets, the IS-IS
LSPs in the TRILL campus should be authenticated and, in that case,
the ESADI PDUs will be authenticated by default as provided in Section
6.3 of this draft.
How about adding a new paragraph to Section 8, between the current
first and second paragraphs, incorporating the above, such as:
However, there may be cases where it is not necessary to
authenticate ESADI PDUs despite using authenticated registration
for end stations. For example a TRILL campus with secure RBridges
and inter-RBridge links configured as trunks but some end stations
connected via 802.11 wireless access links might use 802.11
authentication for the connection of such end staions but not
necessarily authenticate ESDAI PDUs. Note that if the IS-IS LSPs in
a TRILL campus are authenticated, perhaps due to a concern about
forged packets, the ESADI PDUs will be authenticated by default as
provided in Section 6.3.
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.
I believe these are all defined/expanded in RFC 6325 but it would
still be a good idea to expand them on first use in this document.
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.
Well, whether or not any particular Ethernet frame carrying a TRILL
Data packet is VLAN tagged or not depends on whether the port sending
that frame is configured to send it tagged or untagged. There is no
requirement or enforcement mechanism that all the ports on that
Ethernet link be identically configured in this regard. So I do not
consider it to be a property of the link.
Also, Appendix A item 1: replces -> replaces
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3(_at_)gmail(_dot_)com
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
----------------------------------------------------