[v6ops] comments on draft-gont-v6ops-ipv6-ehs-in-real-world-00

神明達哉 <jinmei@wide.ad.jp> Fri, 08 August 2014 16:41 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705951B2BA8 for <v6ops@ietfa.amsl.com>; Fri, 8 Aug 2014 09:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 uG_ihom8krUu for <v6ops@ietfa.amsl.com>; Fri, 8 Aug 2014 09:41:10 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8C11B2BA7 for <v6ops@ietf.org>; Fri, 8 Aug 2014 09:41:09 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id ho1so1330893wib.2 for <v6ops@ietf.org>; Fri, 08 Aug 2014 09:41:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=sJMf/nou80WcRjozZdPPWHB4IPvXqo6r+hL4q4MGL1U=; b=K4dk6bgd2cMdRuhzgpVxFW56V5CZuCN5Q92+xzRN6ylK3DMsTFD7n4h/EpLOVQK82R sNuogJbO7Oio9BCEOVgEYc/PUo/aRblz1ztZhDAGlRCotMuvNG0ipEfUEHj8mm+93GOW 32qVguSjq6grKHJFmzMnhga9S8VnRY3m++Xv6pxaiz+jQ8Iu/u62bb34625cgZyMt2Gw v4GoMAtID3FTxtIOLFTLi2A/Y3dKhc2Yu9HqkpXkDDt7Tc41TufPuUzYaOAOeF9qw2Ks gL5WOZ9NdB5jyB15iLl0oFKe772vEOOmY0vNB7svc0RwGDYxt+mcVeof7cQjq34CIBih UirA==
MIME-Version: 1.0
X-Received: by 10.180.12.38 with SMTP id v6mr323356wib.31.1407516068338; Fri, 08 Aug 2014 09:41:08 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Fri, 8 Aug 2014 09:41:08 -0700 (PDT)
Date: Fri, 08 Aug 2014 09:41:08 -0700
X-Google-Sender-Auth: cJi_BghWxdIBo-VPY_UKmKB1zbQ
Message-ID: <CAJE_bqf_u3+hz1mGnH7JvyNVi4HRpVu7mD4GN86vKwmUm_iWug@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jXAXlbDxxrzgbqImMkO4byOGUGw
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: [v6ops] comments on draft-gont-v6ops-ipv6-ehs-in-real-world-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 16:41:11 -0000

I've read the draft and have a few comments on it:

Section 4: for the probing measurement you should have sent packets
without the extension headers in question to identify the point where
the packets are dropped and make it more likely that it's dropped
because of that extension header.  It may be easily inferred from the
context, but I think it's helpful to note that explicitly.  As I read
the rest of the draft I found it would probably just suffice to refer
to Appendix A.1 from this section.

Section 4
   Packets dropped by the destination AS are less of a
   concern, since they can be assumed to be the result of an explicit
   policy of the organization to which the packets are destined (who can
   make its own decision regarding what kind of traffic is
   "acceptable").
I agree with the sense of this sentence, but I think the "since"
clause is a bit too strong.  For cases like ordinary household users
connected to ISPs, the situation shouldn't be so different from the
case where the packet is dropped in a transit AS in practice.

Section 4: the numbers in tables 1 and 2 are confusing to me.  For
example, in the following cell of table 1:

   +--------------+-----------------+
   |   Dataset    |       DO8       |
   +--------------+-----------------+
   |     Web      |      11.88%     |
   |              | (17.60%-20.80%) |
   +--------------+-----------------+

What exactly do these numbers represent?  I guess '11.88%' is the
percentage of the dropped packets against the total number or probe
packets.  The meaning of the "range" values were explained in the
draft, but it's still not clear enough to me...is 17.60% the
percentage of...what, for example?

Editorial nits:

- Section 3.1: s/patch/path/ ?
   Processing a large amounts of traffic in the slow patch may cause the

- Section 3.2: s/same same/same/
   for the RA-Guard case, but same same techniques can be employed for

- Section 4: s/list/list)/
   o  Mail servers (MX -> AAAA of such list

- Section 4: s/A.2/A.2)/ (?)
   to which a specific router belongs (see Appendix A.2, our

- Section 5.2: s/forged an/forged/
   sending a forged an ICMPv6 Packet Too Big [RFC4443] error message to

- A.1: s/dropping/dropped/ (?)
   Let us assume that we find that IPv6 EHs are dropping on their way to

--
JINMEI, Tatuya