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 : > > > >
- [trill] RtgDir review of draft-ietf-trill-directo… Joel M. Halpern
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Susan Hares
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Alia Atlas
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Donald Eastlake
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Joel M. Halpern
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Donald Eastlake
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Joel M. Halpern
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Donald Eastlake
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Donald Eastlake
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Joel M. Halpern
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Joel M. Halpern
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Donald Eastlake
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Joel M. Halpern
- Re: [trill] RtgDir review of draft-ietf-trill-dir… Donald Eastlake
- Re: [trill] [RTG-DIR] RtgDir review of draft-ietf… Joel M. Halpern