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

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Sun, 20 November 2011 11:11 UTC

Return-Path: <yiu_lee@cable.comcast.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 19F3421F87D3 for <softwires@ietfa.amsl.com>; Sun, 20 Nov 2011 03:11:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.734
X-Spam-Level:
X-Spam-Status: No, score=-101.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 qnWhAIAHfTCO for <softwires@ietfa.amsl.com>; Sun, 20 Nov 2011 03:11:42 -0800 (PST)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id F2B9521F87C5 for <softwires@ietf.org>; Sun, 20 Nov 2011 03:11:41 -0800 (PST)
Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.62167526; Sun, 20 Nov 2011 04:11:55 -0700
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Sun, 20 Nov 2011 06:11:36 -0500
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: Maoke <fibrib@gmail.com>, "draft-ietf-softwire-dslite-deployment@tools.ietf.org" <draft-ietf-softwire-dslite-deployment@tools.ietf.org>
Thread-Topic: [Softwires] draft-ietf-softwire-dslite-deployment - review
Thread-Index: AQHMp3Uqq7qHjZOxVkqMroXL51/knA==
Date: Sun, 20 Nov 2011 11:11:34 +0000
Message-ID: <CAEE4A77.18943%yiu_lee@cable.comcast.com>
In-Reply-To: <CAFUBMqWge+QBNaHsaNxFNxuPgo6j3hYqVHAicRg87oOK8T9xuA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [58.153.61.254]
Content-Type: multipart/alternative; boundary="_000_CAEE4A7718943yiuleecablecomcastcom_"
MIME-Version: 1.0
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] draft-ietf-softwire-dslite-deployment - review
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: Sun, 20 Nov 2011 11:11:43 -0000

Hi Maoke,

Thanks for the review. We will capture your comments in next revision.

Yiu

From: Maoke <fibrib@gmail.com<mailto:fibrib@gmail.com>>
Date: Sat, 19 Nov 2011 23:08:36 +0900
To: <draft-ietf-softwire-dslite-deployment@tools.ietf.org<mailto:draft-ietf-softwire-dslite-deployment@tools.ietf.org>>
Cc: "softwires@ietf.org<mailto:softwires@ietf.org>" <softwires@ietf.org<mailto:softwires@ietf.org>>
Subject: Re: [Softwires] draft-ietf-softwire-dslite-deployment - review


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. :)

regards,
maoke


_______________________________________________ Softwires mailing list Softwires@ietf.org<mailto:Softwires@ietf.org> https://www.ietf.org/mailman/listinfo/softwires