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

Donald Eastlake <d3e3e3@gmail.com> Sat, 05 April 2014 15:23 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC5E1A01A5; Sat, 5 Apr 2014 08:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.95
X-Spam-Level:
X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2-GRALffltp; Sat, 5 Apr 2014 08:23:10 -0700 (PDT)
Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1121A018C; Sat, 5 Apr 2014 08:23:10 -0700 (PDT)
Received: by mail-oa0-f43.google.com with SMTP id eb12so4895464oac.30 for <multiple recipients>; Sat, 05 Apr 2014 08:23:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dGXDd8s7r2BciJ/PKBcXMBZKHvmrP6VKqil5pkwRzpU=; b=KNlB8+RyS7nB3djXTTq8duOFR+3EqLebQBpuPzTB+R/MUlRX8OckelW91z8/pVDRJW CCdylmxPEN2kAbbgzwKmfwS29Dr9RYfik38fk9dTj+M4k7TzK/aMhHdty2AXKPrKkEhG 6zOxXwDNsTYZxTZE8hPqbVKrneIxdAvsI+GxjKrNP3JWPavzPHQN+KSUJKJzLogrZuC/ Y71cZ9fbsQRzLfcu6gyqIgWwvt0QXK5KjsxG/F+1d5xYfcYfvCYiNdxr35azSud+L+cs azQlE2gcStWr3OCWNxXsEumz1UEwZ2twFxeF4LyOIDKoZnjkdYwYW/tTAncrjF4jFM79 tEUw==
X-Received: by 10.182.44.232 with SMTP id h8mr64072obm.73.1396711385266; Sat, 05 Apr 2014 08:23:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.25.41 with HTTP; Sat, 5 Apr 2014 08:22:45 -0700 (PDT)
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C0ADDF7@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712076C0ADDF7@MX15A.corp.emc.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sat, 05 Apr 2014 11:22:45 -0400
Message-ID: <CAF4+nEEL1LUxBEaGyUxEHNWb=fMgu2zVAuHqiSf64d0ZW=w3ng@mail.gmail.com>
Subject: Re: Gen-ART review of draft-ietf-trill-esadi-06.txt
To: "Black, David" <david.black@emc.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/n32gipcI6iYya9913JCYU-gvaEc
Cc: "zhai.hongjun@zte.com.cn" <zhai.hongjun@zte.com.cn>, "ietf@ietf.org" <ietf@ietf.org>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>, "ostokes@extremenetworks.com" <ostokes@extremenetworks.com>, "Radia@alum.mit.edu" <Radia@alum.mit.edu>, "hu.fangwei@zte.com.cn" <hu.fangwei@zte.com.cn>, "trill@ietf.org" <trill@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Apr 2014 15:23:14 -0000

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