Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Tue, 12 June 2012 12:46 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 B967521F8547 for <softwires@ietfa.amsl.com>; Tue, 12 Jun 2012 05:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.231
X-Spam-Level:
X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, 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 DQyEaNGu1wCh for <softwires@ietfa.amsl.com>; Tue, 12 Jun 2012 05:46:19 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id E20E121F8532 for <softwires@ietf.org>; Tue, 12 Jun 2012 05:46:18 -0700 (PDT)
Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.20860374; Tue, 12 Jun 2012 06:29:42 -0600
Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 08:46:14 -0400
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: "softwires@ietf.org" <softwires@ietf.org>
Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Thread-Index: AQHNSJlZpXK6odl3xUusf1L2LJvHbg==
Date: Tue, 12 Jun 2012 12:46:13 +0000
Message-ID: <CBFCB14C.21DF5%yiu_lee@cable.comcast.com>
In-Reply-To: <CAKcc6AfZ2MDBNwz3eBKpS4UTzv+fB3qewEddjhnp7hZOM4_6Fg@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.2.2.120421
x-originating-ip: [24.40.55.72]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3422335569_43787"
MIME-Version: 1.0
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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: Tue, 12 Jun 2012 12:46:19 -0000

Hi Dapeng.,

This is not a specification draft. This is a draft to discuss the
motivations. IMHO, people who are working in this area would be able to
understand this draft. The focus of it is about the carrier network, CPE
is never the focal point. I think the current statement "States may still
exist in other equipments such as customer premises equipment." is enough.
Adding more text only causes confusion.

Thanks,
Yiu

On 6/12/12 6:21 AM, "liu dapeng" <maxpassion@gmail.com> wrote:

>2012/6/12, Ole Trøan <otroan@employees.org>:
>>> Ok, then we can make this more clear in our document.
>>>
>>> "States still should be maintained in other equipments, e.g. customer
>>> premises equipment or host, in order to restrict IP address or port
>>> number
>>> information into the configured context except that a non-shared IPv4
>>> address is
>>> assigned to a standalone host."
>>
>> I think this is just adding confusion.
>> the NAT44 on the CPE already does this.
>
>=>First off, we are not only talking about NAT44 here, but port
>translation and non-shared address. Secondly, NAT44 on the CPE is not
>doing what today NAT44 does. For example, override ID in ICMP with
>port information.
>
>that reminds me to update the proposed text a bit,
>
>"States still should be maintained in other equipments, e.g. customer
>premises equipment or host, in order to restrict L3 or L4 information
>into the configured context except that a non-shared IPv4 address is
>assigned to a standalone host."
>
>> I suggest we instead talk about no _additional_ state in the network.
>>there
>> is no need to mention the CPE, apart from stating that no additional
>>state
>> is required.
>
>=>I believe the above is clear for reader and designer. I don't see why
>we resist on clarifying and helping reader better understanding.
>
>Regards,
>Dapeng Liu
>
>
>> cheers,
>> Ole
>>
>>
>>
>
>
>-- 
>
>------
>Best Regards,
>Dapeng Liu
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires