Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt

Maoke <fibrib@gmail.com> Thu, 12 April 2012 01:13 UTC

Return-Path: <fibrib@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E417E11E8108 for <softwires@ietfa.amsl.com>; Wed, 11 Apr 2012 18:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.197
X-Spam-Level:
X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSlUTaxS78h5 for <softwires@ietfa.amsl.com>; Wed, 11 Apr 2012 18:13:58 -0700 (PDT)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 273D811E80FD for <softwires@ietf.org>; Wed, 11 Apr 2012 18:13:58 -0700 (PDT)
Received: by qafi31 with SMTP id i31so4072727qaf.15 for <softwires@ietf.org>; Wed, 11 Apr 2012 18:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uIgZHeJFYOaMbf2ap1hvJwKCOehWDLcPspZnlivKG3g=; b=uTTlz4893oPsryWx+RlBT/ibcVN8uvvMSFCwndGZQcEc8mOewLc9Zx89w1QVGvFa3X nfsNcCQkKy1x6VjHqt6Vc7O5H2kg417l4Bpf0OkF8lB+fz1/W9KrGcn6V3OVNPNj4B8C hj0OHu9l4WFlslEArLzkxQrpOzMyr/mERyTGgiC932C1HZe9hVwmNLvnrf2CUNhRKGpB RhbaMR0gIK50PZMlvrnes1L15sgV12pBREP1g+cBMFStz7hP67dxs0c1zGpVmCsq+YGI GsEdOjQWO/LL0J3qWssHqC6t201zniERg9gRfXDUKSdUTROBzUNwWWkwQxtUn3g0SB1I SV6g==
MIME-Version: 1.0
Received: by 10.224.181.69 with SMTP id bx5mr1414654qab.49.1334193237741; Wed, 11 Apr 2012 18:13:57 -0700 (PDT)
Received: by 10.229.123.197 with HTTP; Wed, 11 Apr 2012 18:13:57 -0700 (PDT)
In-Reply-To: <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net>
References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <CAFUBMqXjnUK+-9eA4WwY27x_kkdNWO7vAJCYDpJk5jfd2K81xQ@mail.gmail.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net>
Date: Thu, 12 Apr 2012 01:13:57 +0000
Message-ID: <CAFUBMqWJHZn42093BWJoJWDdA4jQY_7LLprBNHPkBBzh6ydmEg@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary="485b397dcfc9ff4fd004bd7111b7"
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 01:13:59 -0000

second point, on tunnel and transparency.

2012/4/11 Rémi Després <despres.remi@laposte.net>

> 6. The statement that "double translation is also a sort of tunneling in
> general sense" is IMHO confusing in view of its lack of IPv4 end-to-end
> transparency.
>

limited to the definition of "a source route that circumvents conventional
routing mechanisms", IMHO, it has no business with the end-to-end
transparency and therefore not confusing with explictly specifying "in
general sense".


> The statement that "It needs further investigation to ensure if 4rd-U is
> qualified to be called as a tunnel in the narrow sense" expresses a doubt
> without substance to justify it.
>

because 4rd-u draft calls itself a "tunnel". the commentary identifies it
is surely a general-sense tunnel. the commentary tries to understand
whether it is also a narrow-sense tunnel but did not yet concluded at the
time of writing. now it looks we can conclude that 4rd-u is hard to be
called as a tunnel in the narrow sense. see below, regarding the
transparency.


> 4rd-U only claims that IPv4 packets traverse ISP domains transparently
> (unless they have IPv4 options in which case the domain signals it doesn't
> support them).
>

now we have clearified the checksum end-to-end transparency covering
payload length and payload protocol type is lost for IPv4/ICMPv4 datagrams
in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work will
continue, to reflect this understanding too, by explicitly claiming that
4rd-u keeps end-to-end transparency for most of IPv4 fields but checksum
covering payload length and payload protocol type (instead of only
mentioning options) when the payload is ICMPv4, less than the transparency
provided by encapsulation.

commentary document will include this understanding in next revision,
without judging how severe this concern is in practice.

if no further significant dissent, this subsubject is closed.

- maoke