ietf
[Top] [All Lists]

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

2014-04-09 09:50:35
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:d3e3e3(_at_)gmail(_dot_)com]
Sent: Wednesday, April 09, 2014 10:12 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,

On Tue, Apr 8, 2014 at 4:58 PM, Black, David 
<david(_dot_)black(_at_)emc(_dot_)com> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3(_at_)gmail(_dot_)com

Thanks,
--David

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



<Prev in Thread] Current Thread [Next in Thread>