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

Joe Touch <touch@isi.edu> Fri, 17 June 2016 15:56 UTC

Return-Path: <touch@isi.edu>
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 76FC212D7EB; Fri, 17 Jun 2016 08:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.325
X-Spam-Level:
X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 BmddrTf6sQEF; Fri, 17 Jun 2016 08:56:58 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 5F5BD12D7BD; Fri, 17 Jun 2016 08:56:58 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5HFuDZw008683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Jun 2016 08:56:24 -0700 (PDT)
Subject: Re: TSV-ART review of draft-ietf-forces-interfelfb
To: Jamal Hadi Salim <hadi@mojatatu.com>
References: <be645f8a-61f3-7676-bd97-97b6049aa215@isi.edu> <CAAFAkD_8AzGvvVEd34Fit0KT764bUxgLKSikb9WKJ2fDKiDFOw@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <57641D9D.7010007@isi.edu>
Date: Fri, 17 Jun 2016 08:56:13 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAAFAkD_8AzGvvVEd34Fit0KT764bUxgLKSikb9WKJ2fDKiDFOw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------070301010502000002060402"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/xM8uWdZAE_gGJ9ipHaE1OWA5ix8>
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: Fri, 17 Jun 2016 15:56:59 -0000

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
> <mailto: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.

---