RE: Gen-ART review of draft-ietf-trill-esadi-06.txt

["Black, David" <[e-mail]>]

Hi Donald,

I think we're basically done here.

For [4], I would like to see stronger requirements in the security text, but
I can accept what's proposed below as an improvement.  Please ensure that a
good security reviewer (e.g., a sec-dir reviewer) takes a look at that new
text as well as the rest of the security considerations.

Everything else below is fine with me.

Thanks,
--David

> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: Wednesday, April 09, 2014 10:12 AM
> To: Black, David
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; General Area Review Team ([e-mail]);
> [e-mail]; [e-mail]
> Subject: Re: Gen-ART review of draft-ietf-trill-esadi-06.txt
>
> Hi David,
>
> On Tue, Apr 8, 2014 at 4:58 PM, Black, David <[e-mail]> wrote:
> > 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:
>
> OK. It is good sign when the amount of text being written with each
> exchange starts to shrink rather than grow :-)
>
> > [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
>
> OK. We could add a few more words to the proposed new version of the
> first paragraph in Section 1.1 as follows:
>
> NEWER
>    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 include a change
>    to the format of ESADI-LSPs that is not backwards compatible; this
>    change is justified by the substantially increased amount of
>    information that can be carried in light of the very limited, if
>    any, deployment of [RFC6325] ESADI. These changes are further
>    discussed in Appendix A.
>
> > [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.
>
> I'm OK with the wording you suggest.
>
> > [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.
>
> Well, a more general statement of the criteria for such cases could be
> added such as below:
>
>    However, there may be cases where it is not necessary to
>    authenticate ESADI PDUs despite using authenticated registration
>    for end stations because of a significant threat of forged packets
>    on end station links when that threat is not present for
>    inter-RBridge trunks.  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.
>
> > [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.
>
> I agree that "stripped" is not a very good word to use. I'm OK with
> your suggested wording.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
> > Thanks,
> > --David
> >
> >> -----Original Message-----
> >> From: Donald Eastlake [mailto:[e-mail]]
> >> Sent: Saturday, April 05, 2014 11:23 AM
> >> To: Black, David
> >> Cc: [e-mail]; [e-mail]; [e-mail];
> >> [e-mail]; General Area Review Team ([e-mail]);
> >> [e-mail]; [e-mail]
> >> 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 <[e-mail]> 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   [phone] (cell)
> >>  155 Beaver Street, Milford, MA 01757 USA
> >>  [e-mail]
> >>
> >> > 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
> >> > [phone]             FAX: [phone]
> >> > [e-mail]        Mobile: [phone]
> >> > ----------------------------------------------------
> >