Re: [RTG-DIR] RtgDir review: draft-ietf-trill-directory-assisted-encap-02

Jon Hudson <jon.hudson@gmail.com> Sun, 24 April 2016 08:32 UTC

Return-Path: <jon.hudson@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F96B12D0E5; Sun, 24 Apr 2016 01:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 TWn_ipIhQX1D; Sun, 24 Apr 2016 01:32:09 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 763FE12B01D; Sun, 24 Apr 2016 01:32:09 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id c189so10859568pfb.3; Sun, 24 Apr 2016 01:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OYufAB9YK6m3gko7iLHVk+szXGuEpqR9wg2Iw5LGVr0=; b=G9c4O/gjbav54VsIlqUa4kvXPwJOZ9bXCRBNJrRjudjDDuEyvpkBf6E1PaPq/bUIj4 d9jEYUdtja72upZit+1jcHAzT+TSbmNocbFoYW+JjRaHmIZRgBixsi1tVzzvj21JKmOM OsWPAtTyXHKbBPnMiiNj5PrJ/X3q829ie51VrPDANn1Z2iVYSzHWc7ZSTqoAPx/NNimA uVXwRDZUIh0MlNA7WSPCu4uSnmLzDDub8UtZwErJXQGYDA/62rt6WDxv0bAm4/PakNt+ rRgZqGg3yT6zUm/bO2IXg685g+LkEuaOGT8C2IZeqIuyrnKTIQZhnun8aK2QFzAXe2ws mUZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OYufAB9YK6m3gko7iLHVk+szXGuEpqR9wg2Iw5LGVr0=; b=mzGo81TJ7IEm0FboguNX8xysfNcyNmqmzSMwudw5frpSz60dtwn2WKxW8sFrpL79Xt 59bQnjLpMCedUA6Dn0NOI1rasenJFmcwLDm/riF6NotxRt2nAsklMkGUwMXoOKfwwNW5 e7gN3wxz6XqzYF7mgCFIxxI4ngV8P4i5C1is9lGTkNynPamW/cKsB58xTvzp0yNXxrrV XM3aT3qrOwk+cHPVUj5zxAaS+fDRQB1I2WRmKcuBhjJbcDmpSCrK+gYTfGvQGF3ryFg1 ZA/CQarkKp2VqoV7v5ze/sMTSsah0uBzijm/7m6iMno2qzmkb/rrliHQgyVMw/YWB8/T 74Tg==
X-Gm-Message-State: AOPr4FU2RYbq/KUY+plkF0Js72v76fAMkKO0UjD/xHpPILtfCrW5W9Q2D+mtTAyTQO7M7Q==
X-Received: by 10.98.1.69 with SMTP id 66mr41437126pfb.10.1461486729033; Sun, 24 Apr 2016 01:32:09 -0700 (PDT)
Received: from [10.0.1.18] (c-98-234-217-127.hsd1.ca.comcast.net. [98.234.217.127]) by smtp.gmail.com with ESMTPSA id h85sm19694778pfj.52.2016.04.24.01.32.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Apr 2016 01:32:08 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Jon Hudson <jon.hudson@gmail.com>
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <719932B6-AA05-47A4-99BA-EBB842D3AFF0@niven-jenkins.co.uk>
Date: Sun, 24 Apr 2016 01:32:07 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A53AF515-E922-453D-B446-FB36010CDA99@gmail.com>
References: <719932B6-AA05-47A4-99BA-EBB842D3AFF0@niven-jenkins.co.uk>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/_gimgBtrkoJMMkD4h6hNICdQeJw>
Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-trill-directory-assisted-encap-02.all@ietf.org, trill@ietf.org
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-directory-assisted-encap-02
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Apr 2016 08:32:11 -0000

WoW! Thank you so much.
Jon

> On Apr 24, 2016, at 1:28 AM, Ben Niven-Jenkins <ben@niven-jenkins.co.uk> wrote:
> 
> 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. 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-assisted-encap-02.txt 
> Reviewer: Ben Niven-Jenkins
> Review Date: 21 April 2016 
> 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.
> 
> Comments: 
> Overall this is not the easiest document to read although some of that might be due to my lack of background in TRILL and its terminology.
> 
> 
> Major Issues: 
> 1) The document has an Intended Status of Proposed Standard, however it does not contain any RFC2119 keywords and does not seem to make any normative statements about required behaviour which I would have expected in a Proposed Standard.
> 
> 2) Section 4: If I understand correctly the TRILL-EN spoofs the Ingress RBridge edge node's nickname in the source address field of the TRILL header. Is this likely to introduce problems? E.g. if RBridges will accept & forward frames that have their own source address in, does it perpetuate routing loops or present security considerations that the document should discuss?
> 
> Section 8 on Security Considerations also looks very light on text. If you are allowing TRILL-ENs to spoof RBridge source addresses (which I think you are, see comment above) I think you should have a discussion about that somewhere in the document.
> 
> 
> Minor Issues: 
> 1) Section 3. I am not sure what Figure 2 is trying to convey and it is not referred to by the main text. Is it required?
> 
> 2) Section 3 says:
> 
>   Editor's note: [Directory] has defined Push and Pull methods for edge
>   RBridges to get directory mapping information. The Pull Model is
>   relative simple for TRILL-EN to implement (see Section 9). Pushing
>   Directory information requires some reliable flooding mechanism, like
>   the one used by IS-IS, between the edge RBridge and the TRILL
>   encapsulating node.
> 
> which gives me the impression the authors prefer pull and discourage push as it would require something extra like IS-IS.
> 
> However, Section 4 says
> 
>   The TRILL-EN learns this nickname by listening
>   to the TRILL IS-IS Hellos from the Ingress RBridge.
> 
> which makes me think if the TRILL-EN is running IS-IS for hellos, is pushing the directory such an obstacle?
> 
> Is whether the directory is pulled or pushed something this document needs to discuss at all? If it does need to discuss push vs pull, should the document be stronger and make a clearer recommendation on which method should be used (or implemented by default) to aid with interoperability?
> 
> 3) Section 5.1 states
> 
>   setting TRILL boundary at aggregation
>   switches that have many virtualized servers attached can limit the
>   number of RBridge nodes in a TRILL domain, but introduce the issues
>   of very large MAC&VLAN<->RBridgeEdge mapping table to be maintained
>   by RBridge edge nodes and the necessity of enforcing AF ports.
> 
>   Allowing Non-RBridge nodes to pre-encapsulate data frames with TRILL
>   header makes it possible to have a TRILL domain with a reasonable
>   number of RBridge nodes in a large data center. All the TRILL-ENs
>   attached to one RBridge are represented by one TRILL nickname, which
>   can avoid the Nickname exhaustion problem.
> 
> As I understand it TRILL-ENs pre-encapsulate packets that they send, but when receiving packets the RBridge attached to the TRILL-EN decapsulates the TRILL packet and forwards it to the TRILL-EN “natively” (without TRILL encapsulation), as stated in section 3:
> 
>   When a TRILL frame arrives at an RBridge whose nickname matches with
>   the destination nickname in the TRILL header of the frame, the
>   processing is exactly same as normal, i.e. as specified in [RFC6325]
>   the RBridge decapsulates the received TRILL frame and forwards the
>   decapsulated frame to the target attached to its edge ports.
> 
> Therefore all the RBridges still need to maintain a very large "MAC&VLAN<->RBridgeEdge mapping table”? If that is the case, what advantage does this approach give over the “base case” of setting TRILL boundary at aggregation switches?
> 
> 4) Section 7 on Manageability Considerations only states that in order for the solution to work requires the availability of a directory service, which seems a bit redundant when the entire document is about "Directory Assisted TRILL Encapsulation”. Is this section required?
> 
> Regards
> Ben
>