Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.txt

Alia Atlas <akatlas@gmail.com> Thu, 14 April 2016 01:35 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0370E12DE7C; Wed, 13 Apr 2016 18:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level:
X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 psgCFb6WODIr; Wed, 13 Apr 2016 18:35:19 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F96412DA3C; Wed, 13 Apr 2016 18:35:19 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id s79so80732416oie.1; Wed, 13 Apr 2016 18:35:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7N+KkVzkY9nxDKdBLICYpai7fEzodohK1LSFphsiEA4=; b=M+pIh5nuDDfR5fLhSPnrFJSJSn/UkUeSKKmVdCgJl1AsRE8dtN5nfV/lRuaw3pWv1r SuIvKZ/5eGC37LSxpZVmvS5FTivCvpXzBSXXXYmpdMblcM91VfdR/FdQw1DeNZdbcu/6 cjpvsBIW9BrltfGupgArtGnR7/+3mWnzaeTswZcJYoQXy+UsyYaFpyyJkQEoOpnq4Nq3 jb+pEYCG7rf82JWxJWCV7Z5B6NgQa73oZfEQQ8PnolpAWAoN8FKZ7/eHBrdXpC0BdX59 9cPlcYsy7xkcECMbKtvNAuiBfClBRH415tcMOerC4h8pOHRoe7248On4hhleSbx7G3JN FdQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7N+KkVzkY9nxDKdBLICYpai7fEzodohK1LSFphsiEA4=; b=K/XYngApJ7iAbyIusybjbGgWnKoRJQH+fWhc6HN44JHQkF+BQqFA8dau/GE7mYRzlm Zjsmwtq3IdD1ZMOhlzW93MKO1nnrHf1TfjS9d+v5zNZBvvgq3oMIOTZZ3QhO8wpP7F10 PeCQhvI8rWKCwP4e6PnRnGucBQwSEWj4tN+jBcG1gOUYsrdBxS7NgoG0l99WBO7uZIYC 7ltqu8ueN8YVsoOTVsXijQutvFjwEKdZQMjtEA1ecIble5fzfswFXQEEqt7f/H6vxK8w 2M0ZgQkZbvpJDws7Zt8MVS0fZr+GFK4bGH8KtczQPiue6+h2Pz9LS9RzOj+geRhUAJJr /5DA==
X-Gm-Message-State: AOPr4FWs3I3vKuamYLboN1xW1x0Ia0Te0UzkOl0m6YO/bzJYIS7/ORmsjxzJoqupmz6qZDarxnnnW2a1iLg4DQ==
MIME-Version: 1.0
X-Received: by 10.202.172.201 with SMTP id v192mr5638435oie.29.1460597718419; Wed, 13 Apr 2016 18:35:18 -0700 (PDT)
Received: by 10.60.115.168 with HTTP; Wed, 13 Apr 2016 18:35:18 -0700 (PDT)
In-Reply-To: <02c401d195d7$550d7e70$ff287b50$@ndzh.com>
References: <570EB05D.20802@joelhalpern.com> <02c401d195d7$550d7e70$ff287b50$@ndzh.com>
Date: Wed, 13 Apr 2016 21:35:18 -0400
Message-ID: <CAG4d1rcQMr6ZBpYC6iUjhRazWj+aoJzag0POCFPM0KKHKYMkJA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="001a113ced742a926b053067e8a9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/f0AZmtSwRQlnsmHGtX82kYwwpf4>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, trill@ietf.org, draft-ietf-trill-directory-assist-mechanisms.all@ietf.org
Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2016 01:35:22 -0000

Joel,

Thank you very much for your review!

Alia

On Wed, Apr 13, 2016 at 6:53 PM, Susan Hares <shares@ndzh.com> wrote:

> Joel:
>
> Thank you for the review of this document.  As co-chair, I will work with
> the authors to try to address this issue.
>
> Sue
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Wednesday, April 13, 2016 4:47 PM
> To: rtg-ads@ietf.org
> Cc: rtg-dir@ietf.org;
> draft-ietf-trill-directory-assist-mechanisms.all@ietf.org; trill@ietf.org
> Subject: RtgDir review of
> draft-ietf-trill-directory-assist-mechanisms-07.txt
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request. The purpose of the review is to provide assistance to
> the Routing ADs. For more information about the Routing Directorate, please
> see ​ http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-trill-directory-assist-mechanisms-07.txt
> Reviewer: Joel Halpern
> Review Date: 13-April-2016
> IETF LC End Date: N/A
> Intended Status: Proposed Standard
>
> Summary: I have significant concerns about this document and recommend
> that the Routing ADs discuss these issues further with the authors.
>      I do believe that the major issues are easily resolvable.  I have
> tried to provide my best guess as to text how to resolve each of them.
>      I would like to see the minor issues discussed and preferably
> addressed.
>
> Major Issues:
>      In the state machine transitions in section 2.3.3 for push servers,
> it appears that if the event indicating that the server is being shut down
> occurs while the server is already Going Stand-By or Uncompleting, the
> transitions indicate that this "going down" event will be lost.  A strict
> reading of this would seem to mean that the "go Down" event would need to
> recur after the timeout condition.  This would seem to be best addressed by
> a new state "Going-Down" whose timeout behavior is to move to down state.
>
> In section 2.3.2, The descriptions for event 3 and 5 are identical.  I
> believe from the state transitions that condition 3 is supposed to reflect
> the server NOT having complete data when the Activate condition is met.
>
> In section 3.2.1 there is provision for using a received frame as a
> Query.  There are type indications as to what the type of the frame is.
>   I believe that the intent is that the query always contains the full
> received Ethernet Frame, no matter what the type is.  But it does not say
> that.  So one could also conclude that for ARP, what I should send is the
> ARP message, and for ND, the ND message, etc.  I believe the text needs to
> be clarified.  If my guess is correct that the full Ethernet Frame is to be
> send in all cases, then explanatory text as to why the various type codes
> exist would seem helpful, since the received frame contains enough
> information to support decoding.
>
>
>
> Minor Issues:
>      In section 2.3.3 describing the state transitions for push servers,
> there is an event (event 1) described as "the server was Down but is now
> Up."  The state transition diagram describes this as being a valid event
> that does not change the servers state if the server is in any state other
> than "Down." In one sense, this is reasonable, saying that such an event is
> harmless.  I would however expect some sort of logging or administrative
> notification, as something in the system is quite confused.
>
>      Should section 2.4 include a note that indicates that reliance on
> information completeness does mean that there are windows when new entities
> join the space represented by particular TRILL data label during which
> packets for that destination may be dropped, due to clients not yet having
> received the updated information?  I believe this window is small, and it
> is quite reasonable to also note that in such text.
>
>      Text in section 3.2.2.1 on lifetimes and the information maintenance
> in section 3.3 imply that the clients and servers must maintain a
> connection.  Presumably, this is required already by the RBRidge Channel
> protocol, and I understand that we should not repeat the entire protocol
> here.  It would seem to make readers life MUCH simpler if the text noted
> that the RBRidge Channel protocol requires that there be a maintained
> connection between the client and the server, and that these mechanisms
> leverage the presence of that connection.
>
>      In section 3.2.2.2 on Pull directory forwarding, I expect to see text
> about and to whom the Pull server will flood the received request.
>   Instead, the text appears to say that it is teh response that will be
> flooded.  More importantly, the descriptive text talks about sending the
> response, which would normally be a description of sending the response to
> the requestor, not sending it to someone else.
>      In a related confusion, it seems very strange that a "flood"
> request will result in sending an underlying paket unicast to the
> destination.  This may be just terminology, but it seems likely to confuse
> implementors.  Maybe the flag should be called the Forward flag, with a
> note in the definition that it nromally causes the response to be sent to
> multiple parties, but in the case of a raw MAC frame, results in the packet
> being forwarded to the destination or flooded, as the server can manage?
>
>      In the description in section 3.3 of Cache management, in the text on
> method one in which the servers keep minimal state, it would seem that a
> large health warning is needed, as this method will cause all clients to
> discard all positive data whenever any positive data at the server changes
> (even if no client is using the modified data.)  This makes a flapping end
> station an attack on the cache of all clients!
>      It strikes me that the working group could help get robust deployment
> by making method 3 (tracking what you told clients) a SHOULD.
>   (I grant that it is not a MUST, as the other choices do work.)
>
> Editorial Issues / Nits :
>
>
>
>