Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-trill-directory-assisted-encap-02
Donald Eastlake <d3e3e3@gmail.com> Wed, 10 January 2018 20:05 UTC
Return-Path: <d3e3e3@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 5325C12711B; Wed, 10 Jan 2018 12:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 IBq1F8RFDlFe; Wed, 10 Jan 2018 12:05:51 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 40912126DED; Wed, 10 Jan 2018 12:05:51 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id h2so184611oti.5; Wed, 10 Jan 2018 12:05:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LZTBlg1xcOiCkylgwBA7zgtvSobRFq7v4CvmQtpK3sQ=; b=G51CmXXYPqBKusWOXrFvVpgXTQm2pLDC+Vt23cDNd634PIOnVqSb0UYPvXiBcOHs3w pXAnLQIw3fpEIzDitT5QA0gKrPfsVn5LZvadkT54nbj2ZI5/YH9KLwVu/yN2FFJbfbiy X8WEbMGAuDUYBS88C0g84e/QXdFI9BkABtaTxODGne6uBVJVsm9HHqoSKPGQO0uYORmv 7ZCaiY1GpG29y5PGiND71pY4My7bqe0DT59EMaMwexht23LQYZbsZ1WfykJ5DWAx3Ehc BlnH+zBYGiysBtc8DCWqGnHWSzuzOONT8xIBKppWGzyiYjyptzX1uLxsvP84L0VPycQ6 02hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LZTBlg1xcOiCkylgwBA7zgtvSobRFq7v4CvmQtpK3sQ=; b=GyE0DAumqgXlwv31FrTpKx5KTJ+NanJlaoYztTURZmeeRmo2MkFVowrg9sZBFzNRVi Ojt94aLpa3ZLGDrVA0rBIFnYk98zMay1HAXVlRLcW8KLf2R73JxVBDXOlb0+hFZO3ey2 5fsHK3/0ssUGZzfbHfq3Gdnt+iJ/yTnGIAiDWFfQq6A3zixCfxNlFZz9JpnEecJ1ssZp 165VjU9C+b4h2/LvoxJi5p6+3MEyr3lnxMthZpBLiVN9P3bG7sfh/Lj90xW/nuKZWIKp gVp9j1oA18TLgEe7sd+Ufr63ihOo0hnZOGfoIUwKq6LDz2yfGtLPdzd9khMUs2Q6/vN5 tfYw==
X-Gm-Message-State: AKwxytdwqIsTt7J0u27fSqgJBiZVKNF2ZPjO+UKgbPX/HeRlULBR4HQP MpXEBZJkoK5xWLpM2Wrja9zVXmhsixoXRF1/3s+0Hg==
X-Google-Smtp-Source: ACJfBovYBJfcHZIi8EFdc6+sKcsWzyRWaxKjt48VJAp93ELMW+glr76KbnwmQ7luPry3JBANFsUqZsWLykqFHN1HzzU=
X-Received: by 10.157.60.204 with SMTP id t12mr8111033otf.135.1515614750270; Wed, 10 Jan 2018 12:05:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.53.129 with HTTP; Wed, 10 Jan 2018 12:05:34 -0800 (PST)
In-Reply-To: <CAF4+nEEwV_UXRy+d5z4yHRDe9daH1cH7reENxOevQTeBmSvaVw@mail.gmail.com>
References: <719932B6-AA05-47A4-99BA-EBB842D3AFF0@niven-jenkins.co.uk> <CAF4+nEEwV_UXRy+d5z4yHRDe9daH1cH7reENxOevQTeBmSvaVw@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 10 Jan 2018 15:05:34 -0500
Message-ID: <CAF4+nEGL+EvO7EPoDoe53S_Sbt5LSM7TWtj0Hk6MFLgfyLDDTQ@mail.gmail.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Cc: "<rtg-ads@ietf.org> (rtg-ads@ietf.org)" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, trill-chairs@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1929b8ce6b0b0562718e55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/batpIapuilptShe3T9Uhc4P12k8>
Subject: Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-trill-directory-assisted-encap-02
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 10 Jan 2018 20:05:53 -0000
Hi Ben, As far as I know, you never responded to the email below or to the subsequent email to you from Sue Hares asking you to check if the current version (-06) of this draft resolves your RTGDIR review comments. I realize there was a lot of earlier delay on the part of the TRILL WG but, please, can you repond on this now? Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Oct 26, 2017 at 10:29 PM, Donald Eastlake <d3e3e3@gmail.com> wrote: > Hi Ben, > > Thanks for your review. It appears that is was not responded to in a > timely fashion. Apologies on behalf of the authors. > > (Your review was of the -02 version. The current version is -05.) > > On Sun, Apr 24, 2016 at 4: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. > > Hopefully the changes made between the version -02 you reviewed and > the current -05 have made some improvements and, based on your > comments and WG LC comments, further improvements can be made. > > > 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. > > Well, in version -05 there is at least one keyword instance. > Furthermore, I don't know that such keywords need to always be used > when an implementation requirement level is being specified. That > said, we could see if additional RFC 2119 keywords are warranted. > > > 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? > > TRILL goes to great lengths to avoid loops and has a hop count in the > TRILL header so that, should there be a transient loop, a TRILL packet > in that loop (i.e., an encapsulated frame) will be discarded. In the > potentially more dangerous case of multi-destination packets, as > compared with known unicast, where copies could multiply due to forks > in the distribution tree, a Reverse Path Forwarding Check is used to > discard packets that appear to be on the wrong link or when there is > disagreement about the distribution tree. > > Security Considerations should probably say more on this. > > > 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. > > I agree that some further discussion is needed in the Security > Considerations section. > > > 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? > > Figure 2 is intended to show the header of a pre-encapsulated frame > going from a TRILL-EN to an edge TRILL switch. If it is retained in > the draft, there should be clarifying text that references it. > > > 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. > > That note no longer exists in the draft. Also the "[Directory]" draft > referred to has been issued as RFC 8171 and the draft should be > updated to reflect that. > > > 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? > > That text refers to snooping on IS-IS messages, not running IS-IS. > > There are problems with using IS-IS, designed for communication > between routers (Intermediate Systems) and the end station > implementing pre-encapsulation as described in this draft. At first > throught, you might want is an extension of ES-IS but the Memorandum > of Understanding between the IETF and ISO/IEC only covers IS-IS, not > ES-IS. So TRILL has specified a "TRILL ES-IS" in Section 5 of RFC > 8171. However, even then, push uses ESADI [RFC7357], which involves > encapsulation and VLAN/FGL scoping and which would need to be extended > for end stations so push is out of scope for this document. > > > 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? > > The reasons for using push or pull or some sort of hybrid are > discussed in RFC 8171. The -05 version of the Directory Assisted TRILL > Encapsulation document only covers pull. > > > 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? > > With pre-encapsulation, although edge RBridges need to learn local MAC > addresses so they can de-capsulate, they do not need to learn the > typically much larger number of remote MAC address because they do not > need to encapsulate. This should be explained more clearly. > > > 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? > > I agree that the Manageability Considerations section should have > some material added concerning configuration or be dropped. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > Regards > > Ben >
- [RTG-DIR] RtgDir review: draft-ietf-trill-directo… Ben Niven-Jenkins
- Re: [RTG-DIR] RtgDir review: draft-ietf-trill-dir… Jon Hudson
- Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-t… Donald Eastlake
- Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-t… Donald Eastlake
- Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-t… Ben Niven-Jenkins
- Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-t… Ben Niven-Jenkins
- Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-t… Donald Eastlake
- Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-t… Ben Niven-Jenkins
- Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-t… Donald Eastlake