IETF Logo Mail Archive

Re: TSV-ART review of draft-ietf-forces-interfelfb

Jamal Hadi Salim <hadi@mojatatu.com> Sat, 18 June 2016 14:03 UTC

Return-Path: <hadi@mojatatu.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB1F12D1EB for <ietf@ietfa.amsl.com>; Sat, 18 Jun 2016 07:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mojatatu-com.20150623.gappssmtp.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 TMZd3faF-I8I for <ietf@ietfa.amsl.com>; Sat, 18 Jun 2016 07:03:56 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 8748612D501 for <ietf@ietf.org>; Sat, 18 Jun 2016 07:03:55 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id c73so114060693qkg.2 for <ietf@ietf.org>; Sat, 18 Jun 2016 07:03:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HtyhD9G5UL3Rt9zwxCObSofNJlIvNMfKDGkze7N4ttI=; b=fRdypH7y4cSMYnbw8/8CeknhvZynf5hWKTPZX+vlVBVkcSEyBKuM5R5twP1qyYYKAj JszQGHMzsGpvEDL6qkym3Af5PNg6A9faOv1vahh52sK829d5JBf8XG2C6yaO2jTZLRib H6MwzgINlNjIhNmUF/CZ0r/1hKac06raaS5jY4VOz+vQTeslOB1UOzX9U2griHOb0J6l anPRbd4yzBp9jQmM05NJdZLFQXRyowda1Ao6Np0GTQZpn36KjZY0t1uItuEowaX0qV5T 3gyoWpSQcd8ygiK9nln/PME0+Tk7C8upZCLjhdToBqMg5f7qXIyJlG+rm88EL48dhY6S TUZg==
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:from:date :message-id:subject:to:cc; bh=HtyhD9G5UL3Rt9zwxCObSofNJlIvNMfKDGkze7N4ttI=; b=VUL1KWHzYF32bVktOY3Zx3sNnIRo0nv8h9VCGakOpK6U/gZDlQnfDLkM316Br487G0 /YdNJNKbW5EmkxiNyjoQ/0Qe8M0+MPuphwqfq54cwZrzc3seRCs5+5ZzGCBD0khbff74 wbOtAc867uL0UKTqayRpKayBFjb7lH0RxaPAcp7q67Vbzkj4VFCDGBsUe/21OzrhPtBk rm6/u+Hs7Q6rtg9HPwvOfgrGwBPfuyQqvpcE1+f8lYrRaPSe+gO5HcD5d5S+AH7/HE5L 0OYciBg+Q7yzaSo1X38k9Wmo8yYtSrKFLO/xdXcJtoQ4YCKZuQuD35/XFGItYAwBlP4t tX+w==
X-Gm-Message-State: ALyK8tIvBntdn1Mx2CNphU7noO8dRBVROAHh3RuVTniW4P18zlbymEXs9yUXk5sjVWyv/5R5N0TyIkBf69HbJw==
X-Received: by 10.200.37.98 with SMTP id 31mr9367018qtn.82.1466258634228; Sat, 18 Jun 2016 07:03:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.87.3 with HTTP; Sat, 18 Jun 2016 07:03:34 -0700 (PDT)
In-Reply-To: <57641D9D.7010007@isi.edu>
References: <be645f8a-61f3-7676-bd97-97b6049aa215@isi.edu> <CAAFAkD_8AzGvvVEd34Fit0KT764bUxgLKSikb9WKJ2fDKiDFOw@mail.gmail.com> <57641D9D.7010007@isi.edu>
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Sat, 18 Jun 2016 10:03:34 -0400
Message-ID: <CAAFAkD-wSYRkQ_wg6QGKF8n5MdyGGUrYRDdhOYkuR_e-LdAoMQ@mail.gmail.com>
Subject: Re: TSV-ART review of draft-ietf-forces-interfelfb
To: Joe Touch <touch@isi.edu>
Content-Type: multipart/alternative; boundary="001a11403cdc0b186505358df19f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/qPCVUluoMPYEK0tv_hQsQfuOKUE>
Cc: tsv-art@ietf.org, draft-ietf-forces-interfelfb@tools.ietf.org, IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 18 Jun 2016 14:03:59 -0000

Thanks Joe. I will make an update and post.

cheers,
jamal

On Fri, Jun 17, 2016 at 11:56 AM, Joe Touch <touch@isi.edu> wrote:

> Hi, Jamal,
>
> Focusing only on the portion needing continued feedback below.
>
> Joe
>
> On 6/17/2016 5:12 AM, Jamal Hadi Salim wrote:
>
> Hi Joe,
> Thanks for your review - responses below:
>
> On Wed, Jun 15, 2016 at 6:40 PM, Joe Touch <touch@isi.edu> wrote:
>
>> Hi, all,
>>
>> I've reviewed this draft as part of the TSV Area Review Team, paying
>> special attention to transport-related concerns. Please take these as
>> any other IETF last call comments.
>>
>> Joe
>>
>> ---
>>
>> The document contains two different types of transport issues: its
>> relation to supporting transport traffic and the way it exchanges
>> information between the FEs.
>>
>> ...
>
>
>
>> The document uses Ethernet as a "transport", as stated in Sec 3.1.1. The
>> claim that this is "simpler" than using UDP would benefit from a few
>> sentences of substantiation, especially because Ethernet does not
>> support fragmentation, which has an impact on the solutions proposed in
>> Sec 5.1.1 (see below).
>>
>
> The reference point is the common deployment use cases; within a single
> rack or network owned by one admin who does all the setup.
> Any suggestion on wording you'd like to see?
>
> from:
>
>    o  The FEs are already interconnected using Ethernet.  We focus on
>       Ethernet because it is a very common setup as an FE interconnect.
>       While other higher transports (such as UDP over IP) or lower
>       transports could be defined to carry the data and metadata it is
>       simpler to use Ethernet (for the functional scope of a single
>       distributed device already interconnected with ethernet).
>
> To:
>
>    o  The FEs are already interconnected using Ethernet.  We focus on
>       Ethernet because it is a very common setup as an FE interconnect.
>       Other higher transports (such as UDP over IP) or lower
>       transports could be defined to carry the data and metadata, but
>       these cases are not addressed in this document.
>
> ---
>

v2.23.0 | Report a Bug | By Email