IETF Logo Mail Archive

Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

GangChen <phdgang@gmail.com> Tue, 06 March 2012 10:09 UTC

Return-Path: <phdgang@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 206DA21F8549 for <softwires@ietfa.amsl.com>; Tue, 6 Mar 2012 02:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 wHFctgP8CYTt for <softwires@ietfa.amsl.com>; Tue, 6 Mar 2012 02:09:56 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 596AA21F85C5 for <softwires@ietf.org>; Tue, 6 Mar 2012 02:09:55 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so3045221wgb.13 for <softwires@ietf.org>; Tue, 06 Mar 2012 02:09:54 -0800 (PST)
Received-SPF: pass (google.com: domain of phdgang@gmail.com designates 10.180.83.97 as permitted sender) client-ip=10.180.83.97;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of phdgang@gmail.com designates 10.180.83.97 as permitted sender) smtp.mail=phdgang@gmail.com; dkim=pass header.i=phdgang@gmail.com
Received: from mr.google.com ([10.180.83.97]) by 10.180.83.97 with SMTP id p1mr21792733wiy.19.1331028594626 (num_hops = 1); Tue, 06 Mar 2012 02:09:54 -0800 (PST)
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:content-transfer-encoding; bh=je7wMesb2jiDUD22wSW353dX2VnEjFQC5hHzHiGUAY0=; b=fZsPeOS1UGUqAL8khNrNa4IeTERXza2yBCN/2eWfzqKE5+0Kn7/w+y2sKzP06kviId Wm59fRR0OVmIRLJ0CTtkIUZ+4uJlnsAaTx655CNywZYtG+ymPnS6SjYyEYtQSanwe+fU syxhesulHCdoIfPl2z8/a4rDX5uRaS7WkHlNc7ZD6F6T/ev0MlqQrPNau7Jja18xnAAY 0SDandoPGB9NUYLBA/urH9N2cTAvwjsAqnfv0Cl1NbUx02rOtOTUqc0E/YNCKJPS2b3b 9pt94hSRTOYofExm4LeodYOSfjMAs/K/yEBqBex1W3hbcoytUaa5LW7uHMj5g+UJG+ie eZJg==
MIME-Version: 1.0
Received: by 10.180.83.97 with SMTP id p1mr17324349wiy.19.1331028594525; Tue, 06 Mar 2012 02:09:54 -0800 (PST)
Received: by 10.180.7.105 with HTTP; Tue, 6 Mar 2012 02:09:54 -0800 (PST)
In-Reply-To: <D6428903-FBA0-419C-A37F-A00874F28118@laposte.net>
References: <B509CB1C-4A0A-408B-9B4A-C0F847169431@juniper.net> <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <D6428903-FBA0-419C-A37F-A00874F28118@laposte.net>
Date: Tue, 06 Mar 2012 18:09:54 +0800
Message-ID: <CAM+vMERsVz7cuC1C52gw12wySaEgw8=44JjS8AUygj0vJ899Cg@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Softwires WG <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
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: Tue, 06 Mar 2012 10:09:57 -0000

Hello Remi,

Here are few comments for the draft.
Generally speaking, I'm not sure always carrying fragmentation header
in 4rd domain is a good idea.
Since the receiver always treat that as regular fragments.
That means it tries to reassembly on the BRs and cause some potential risks.
Some analysis is in draft-gont-6man-ipv6-atomic-fragments-00.txt

Secondly, -04 added NAT64+ parts.
If I understood correctly, there are no additional requirements for NAT64 boxes.
The only change is to add NAT64+ mapping rule into the domain.
I guess the intention is to let 4rd-u become friendly to NAT64, since
some operators already deployed it.
IMHO, that seems unnecessary. NAT64 is another standalone system.
4rd-U could naturally coexist with NAT64 by taking proper routing planning.
And, you have a good designing on V bits.
There should be no additional works requested to make these two sets
into unified one.
Besides, I guess NAT64+ mapping rule in some sense would do same thing
in I-D.ietf-behave-nat64-discovery-heuristic

Going into more detailed, I guess there are some editorial suggestions.
In Table 2:
I guess the field of IDENTIFICATION is missing

In R-5, there is term "Domain-IPv6-suffix". I guess it should be "Rule
IPv6 suffix"
In R-7, it uses the indicator of k. I guess that is different meaning
with k in R-5?
In Table 3, at the eighth column, it should be N-N-Y. Otherwise, it
would be duplicated with sixth column
I might back with more comments after my second review.
Many thanks

Gang


2012/3/6, Rémi Després <despres.remi@laposte.net>:
> Hello all,
>
> The new version of the unified 4rd proposal is now available at:
> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-04
>
> A summarized comparison of its features with those of MAP-T and MAP-E is
> about to be posted in draft-despres-softwire-stateless-analysis-tool-01.
>
> All questions and comments are most welcome.
>
> Regards,
> Remi, Reinaldo, Jacni, Yiu
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

v2.23.0 | Report a Bug | By Email