Re: [Softwires] [softwire] Merged version of lightweight 4over6

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Wed, 15 February 2012 19:55 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 D9C7621E804E for <softwires@ietfa.amsl.com>; Wed, 15 Feb 2012 11:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.678
X-Spam-Level:
X-Spam-Status: No, score=-100.678 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 2FfinksmpvTm for <softwires@ietfa.amsl.com>; Wed, 15 Feb 2012 11:55:29 -0800 (PST)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id C94AD21F8501 for <softwires@ietf.org>; Wed, 15 Feb 2012 11:55:28 -0800 (PST)
Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.6303209; Wed, 15 Feb 2012 12:45:21 -0700
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Wed, 15 Feb 2012 14:55:23 -0500
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: Maoke <fibrib@gmail.com>, Qiong <bingxuere@gmail.com>
Thread-Topic: [Softwires] [softwire] Merged version of lightweight 4over6
Thread-Index: AQHM7BvAIcvCW84xWEmWOqa5XFnJXA==
Date: Wed, 15 Feb 2012 19:55:22 +0000
Message-ID: <CB617575.1C9B6%yiu_lee@cable.comcast.com>
In-Reply-To: <CAFUBMqVCnbiSq9Kimx=UA4W_SeWnyDJasgm87cPsF4eaJhdh7A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [24.40.55.72]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3412162522_1222782"
MIME-Version: 1.0
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
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: Wed, 15 Feb 2012 19:55:36 -0000

Hi Maoke,

For 1, it is not a ds-lite problem but a general problem for any tunneling
protocol. Once option is the 4o6 TC passes the fragmented packets and hope
the destination would reassemble them. This option would break the
end-to-end model if the destination rejects fragmented packets. The current
model in RFC6333 will not in exchange with extra CPU and buffer overhead.

For 2, we can mention ALG could be implemented in the 4o6 TI. We still want
to keep the 4o6 TC simple.

Thanks,
Yiu

From:  Maoke <fibrib@gmail.com>
Date:  Wed, 15 Feb 2012 16:38:36 +0900
To:  Qiong <bingxuere@gmail.com>
Cc:  <softwires@ietf.org>
Subject:  Re: [Softwires] [softwire] Merged version of lightweight 4over6

sp. the merged document meets the requirements where flexible dynamic IPv4
address sharing in IPv6 domain and meanwhile 1) considerably reduces the
states that the AFTR needs to handle; 2) reduces the overload of AFTR
through distributing the NAT functionality over Initiators.

i think the document is ready for WG adoption.

a further discussion is: DS-Lite (RFC6333) states some limitations related
to the potentially high burden of AFTR. as i understand, there are at least
two:
1) for fragmentation and reassembly (RFC6333, sec 5.3, sec 6.3), it is
required to reassembly before the decapsulation. DS-Lite states because of
the high buffer requirements, AFTR doesn't do the reassembly but only B4 do
that. it is reasonable in the case of client/server communications where
large datagrams happen often in the inbound. however, it implies that
DS-Lite is not very suitable for the p2p communications where outbound
datagram might be large as well.
2) on the issue of ALG (RFC6333, sec 8.3), it is stated that DS-Lite AFTR
doesn't do ALG for any applications. thus some applications might be
impacted. 

my question is: can lightweight 4over6 improve 1) and 2) because the AFTR
load has been enlighted? if so, i suggest the author to state the
improvement of releasing the limitations.

regards,
maoke

2012/2/5 Qiong <bingxuere@gmail.com>
> Dear all,
> 
> We have published a merged version of lightweight 4over6 in:
> http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-0
> 5.txt. 
> 
> This mechanism moves the translation function from the tunnel concentrator
> (AFTR) to initiators (B4s), and hence reduces the mapping scale on the
> concentrator to per-subscriber level.
> 
> It has got wilely support in the last Taipei IETF meeting, and the only action
> we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite
> and I-D.zhou-softwire-b4-nat into one draft.
> 
> Now that the merge work has done, from the authors of this document's view, it
> is ready to be adopted as working group document. We would be appreciated to
> have your comments.
> 
> Thanks in advance !
> 
> Best wishes
> 
> Qiong
> 
> 
>  
> 
> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> 

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