TSV-ART review of draft-ietf-forces-interfelfb
Joe Touch <touch@isi.edu> Wed, 15 June 2016 22:41 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 CCBFD12D1A9; Wed, 15 Jun 2016 15:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e8-sT0NH3w0V; Wed, 15 Jun 2016 15:41:22 -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 4DC9812D740; Wed, 15 Jun 2016 15:41:22 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5FMegvO018682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jun 2016 15:40:43 -0700 (PDT)
To: IETF discussion list <ietf@ietf.org>
From: Joe Touch <touch@isi.edu>
Subject: TSV-ART review of draft-ietf-forces-interfelfb
Message-ID: <be645f8a-61f3-7676-bd97-97b6049aa215@isi.edu>
Date: Wed, 15 Jun 2016 15:40:42 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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/wuwTjCO9lsqP7gNwA5mXhOiAb0E>
Cc: tsv-art@ietf.org, draft-ietf-forces-interfelfb@tools.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: Wed, 15 Jun 2016 22:41:24 -0000
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's discussion of the impact on supporting transport traffic is sufficient. I'm not sure I concur with citing RFC5405bis as informational, because the correctness of the proposed approach to congestion control relies directly on definitions of controlled environments available only in the -bis update. I would prefer that claims using normative language necessitate using cited references as Normative. 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). Sec 5.1.3 indicates that packet sizes increase due to the ForCES metadata (using encapsulation indicated in Sec 5.2), which could exceed the Ethernet MTU as noted in Sec 5.1.1. Sec 5.1.1 suggests an approach of falsifying MTU information, but this could also result in a reported Ethernet MTU below the required minimum of 1500. This case should be addressed in Sec 5.1.1. Other comments: Sec 5.2: The Ethertype listed should be replaced with "Ethertype-TBD" with a corresponding note to update that text in Sec 9 / IEEE Assignment Considerations. The draft should not use a specific unassigned value, even if currently available, until assigned. (it currently cites 0xFEFE). This section should also refer to the Metadata IDs directly, either by name or by registry, as if assuming that IANA has created that registry. ---
- Re: TSV-ART review of draft-ietf-forces-interfelfb Jamal Hadi Salim
- Re: TSV-ART review of draft-ietf-forces-interfelfb Joe Touch
- Re: TSV-ART review of draft-ietf-forces-interfelfb Jamal Hadi Salim
- TSV-ART review of draft-ietf-forces-interfelfb Joe Touch