Donald,
Thank you for the extensive comments on the review. I'll summarize here
rather than add more text inline. I'm fine with the proposed course of
action for anything not mentioned here:
[1] Absence of backwards compatibility:
- The Appendix A changes look good.
- The "limited deployment" (and presumably also "limited
implementation") rationale for no backwards compatibility
should be included in Section 1.1. This merits additional
text in Section 1.1
[2] Structure of draft wrt RFC 6325:
I think the rest of the proposed changes to Section 1.1 are reasonable:
- Appendix A does explain what's changed. I would have liked to see
more formality/precision in Section 1.1, but that's a matter of
editorial taste that I'll leave to the authors. The proposed
addition of a forward reference to Appendix A will definitely
help.
- The proposed addition of an explicit statement about expecting
familiarity with RFC 6325 in Section 1.1 will also help.
[3] Independence of ESADI instances: What bothered me was the absence of
a strong mention of implementation structure - I have some new text to
suggest to strengthen that point:
OLD
It is an implementation decision how independent the multiple ESADI
instances at an RBridge are.
NEW
Multiple ESADI instances may share implementation components within
an RBridge as long as that sharing preserves the independent operation
of each instance of the ESADI protocol.
Then the link state database example that follows makes more sense,
at least to me.
[4] Section 8 Authentication TLV usage discussion.
> 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 stations but not
> necessarily authenticate ESADI 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.
These seems a bit descriptive, with most of the text describing a
specific example. I'm looking for some more prescriptive guidance
about what SHOULD (or perhaps should?) be the case when the Authentication
TLV is not used with authenticated registration.
[5] VLAN tag presence (nit)
> > 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.
I don't think the word "stripped" is right, as it would not apply if
the tag wasn't present in the first place, although I also agree with
your comment that my suggested use of "link" isn't right, either.
Here's another suggestion:
The outer VLAN tag will not be present if it was not included
by the Ethernet port that sent the packet.
Thanks,
--David
> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx]
> Sent: Saturday, April 05, 2014 11:23 AM
> To: Black, David
> Cc: zhai.hongjun@xxxxxxxxxx; hu.fangwei@xxxxxxxxxx; Radia@xxxxxxxxxxxx;
> ostokes@xxxxxxxxxxxxxxxxxxx; General Area Review Team (gen-art@xxxxxxxx);
> trill@xxxxxxxx; ietf@xxxxxxxx
> 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.black@xxxxxxx> 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@xxxxxxxxx
>
> > 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
> > ----------------------------------------------------