Re: [Softwires] draft-ietf-softwire-dslite-deployment - review

Maoke <> Sat, 19 November 2011 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6DE621F8A35 for <>; Sat, 19 Nov 2011 06:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.602
X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a0fdCNgktWmo for <>; Sat, 19 Nov 2011 06:08:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 80A5321F8549 for <>; Sat, 19 Nov 2011 06:08:37 -0800 (PST)
Received: by vbbfc26 with SMTP id fc26so1262211vbb.31 for <>; Sat, 19 Nov 2011 06:08:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=lU3FWshSp54/KtRwcW/7dlpGcgJZkjzajEFZFnsSUAo=; b=r+uYpLYpD1xAnT9x30sIQhxwJ1Kd3qo4IJJdnL1JXjSmZ5YJiLgu0Kh7HjZlQCMKba p1of1W0Zb8dDuJ/mBUJJqF/nJquhj6b+uZBFBKvSrHoLQtKO7UJt+IaTcPtnq+iyf8fx Vp+bivH5ZSNIh9UYADfT5ktQGQFvJLA9Ybq30=
MIME-Version: 1.0
Received: by with SMTP id e5mr3139713qan.0.1321711716877; Sat, 19 Nov 2011 06:08:36 -0800 (PST)
Received: by with HTTP; Sat, 19 Nov 2011 06:08:36 -0800 (PST)
Date: Sat, 19 Nov 2011 23:08:36 +0900
Message-ID: <>
From: Maoke <>
Content-Type: multipart/mixed; boundary="20cf3068447f6146cb04b216fdfb"
Cc: "" <>
Subject: Re: [Softwires] draft-ietf-softwire-dslite-deployment - review
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 19 Nov 2011 14:08:38 -0000

dear authors and chairs,

i volunteered to be one of the reviewers of the draft on dslite deployment
(v01), and now i send my comments as follows. i also attach a diff
(generated by "diff -u") containing modifications that i suggest for the
grammatical/wording. but i am not a native speaker and please forgive if i
make anything wrong. :P

Sec 1.

some grammatical concerns only.

Sec 2.
2.1: stating the AFTR "is the function deployed ..." and soon after
mentioning dual-stack interface for "both functions" might confuse. i
suggest to remove "the function" in the first phrase.

2.2: it is unfair to say any tunneling has a risk on MTU. it is not true
that FTP or HTTP would fail once there is a tunnelrfc2473 and rfc4213,
which rfc6333 cites normatively, have discussed this issue. it is needed to
explain here why those are not enough for ds-lite. on the other hand, how
do we increase the MTU of an access network in practice? and how do we
 prevent host to generate full-MTU-sized datagrams even we have the MTU in
access network increased?

2.3: it is mentioned that both host and the remote peer "may continue to
use the MTU size for communication"... here, "the MTU" is what sort of MTU?
of link or of path? if it is path MTU, it is necessary to explain why
DS-Lite tunneling doesn't support correct path MTU discovery to work.

regarding the editor question on whether we need to drop the IPv4 DF=1
packets, if we don't what we expect the result? if the ICMP error is
bounced, the packet could and should be dropped.

here a citation to RFC792 is needed.

2.4: interception "must be performed on the AFTR" => "has to be performed
on the AFTR if it is needed"? (why it is not fine to do that on B4?)

2.5: how does the AFTR create one log per port range? if it is the
timestamped log, each log entry has a unique timestamp, right? how do we do
the aggregation for the source-specific log?

2.7: "Policies" => "Filtering Policies" or "Filters"? what does the "port
creation" mean?

2.8: where we have the "levels" of B4, BNAS, AFTR defined? i removed the
"level" for each one in the diff.

the 3rd paragraph of this subsection is hard to read. i tried to re-arrange
the text but i'm not sure if my modification is what the authors mean.

there are 10 "operator" and 9 "service provider" throughout the document, i
suggest to use "operator" uniformly and i do this with the diff.

2.9: does the last phrase of the 3rd paragraph, "since the AFTR would
support B4 elements ...", refer to Model One or Model Two? what does the
"deeper in the network" mean?

2.11: this subsection is related to geo-location issue of sharing the same
IPv4 address in a wide area. geo-location is not only used for the service
optimization but directly used for by applications. what are the "existing
assumptions of the client source address"?

the "another possibility" is not qualified. for mobile devices, typically
we use either GPS or geo-location service provided in the Internet. if the
device doesn't have GPS module, the "application could rely on GPS" might
be a myth.

somehow, this part is of an limitation of the ds-lite. no matter what we
do, it exists. my suggestion is to admit the limitation and state carefully
locating AFTRs may mitigate the inaccuracy of geo-location services.

2.13: "accepting incoming UDP or TCP traffic" is confusing. any service may
require accepting incoming traffic. i suggest to modify as "incoming UDP or
TCP requests".

Sec 5 seems to me less informational but i don't insist to suggest removing
it. :)