Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

Jacni Qin <jacni@jacni.com> Wed, 12 October 2011 02:03 UTC

Return-Path: <jacni@jacni.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 49B5321F8C33 for <softwires@ietfa.amsl.com>; Tue, 11 Oct 2011 19:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.58
X-Spam-Level:
X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311]
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 iCLIa1vCP5ac for <softwires@ietfa.amsl.com>; Tue, 11 Oct 2011 19:03:27 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 483E221F8C2B for <softwires@ietf.org>; Tue, 11 Oct 2011 19:03:26 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id AE2F5380087 for <softwires@ietf.org>; Tue, 11 Oct 2011 22:03:25 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with SMTP id 6070C3400B7 for <softwires@ietf.org>; Wed, 12 Oct 2011 09:51:06 +0800 (CST)
Received: from [172.18.36.70] (unknown [221.11.61.96]) by app (Coremail) with SMTP id +AWowJAbSgN68pROoK8YAA--.33440S2; Wed, 12 Oct 2011 09:51:06 +0800 (CST)
Message-ID: <4E94F2E3.2000606@jacni.com>
Date: Wed, 12 Oct 2011 09:52:35 +0800
From: Jacni Qin <jacni@jacni.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Satoru Matsushima <satoru.matsushima@gmail.com>
References: <F259BF79-B3C9-4434-AAC4-9F84B8D9A0FA@laposte.net> <16C872EF-F79E-4FD8-89B9-21B50129BA70@employees.org> <2118E521-F0CC-46F3-9F63-0EC6893326C6@laposte.net> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA0576663D@SZXEML510-MBS.china.huawei.com> <F0571321-3F33-49DE-9350-1060AEF1532F@gmail.com> <815B27C6-4C23-4634-A619-912FCC37FEAE@laposte.net> <9988B501-6929-4C5C-9275-E3E7341823EB@gmail.com>
In-Reply-To: <9988B501-6929-4C5C-9275-E3E7341823EB@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CM-TRANSID: +AWowJAbSgN68pROoK8YAA--.33440S2
X-Coremail-Antispam: 1UD129KBjvJXoW7KFy7JF4fZw1xJw4xAr1UKFg_yoW8XF17pF 48ta15tFWvyr1xCrn3Xa1j9w45Zr1kWay7JrWjq34Y9wn0gFs2va1ak3WrZa98Zrs3Jrn2 vrs2vFy8JF45ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU7qb7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI 4VW3JwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM2kK67kvxFCE54 8m6r1fGryUXwAa7VCY0VAaVVAqrcv_Jw1UWr13Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv 7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41lc7 I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFI7vE0wC2zVAF1VAY17CE14v2 6r126r1DMIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07jOL05UUUUU=
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQATEko7lOiu6AAAsL
Cc: Softwires-wg <softwires@ietf.org>, "fine_sz@huawei.com" <fine_sz@huawei.com>
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
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, 12 Oct 2011 02:03:28 -0000

hi Satoru, Remi,

On 10/11/2011 5:47 PM, Satoru Matsushima wrote:
> ...
>>> Since Remi's draft doesn't specify 'CE IPv6 prefix length', IPv6 prefix can't be self delimiting to extract IPv4 address and port-set ID in the case of double translation. That's my understanding. Is that correct?
>> In my understanding, yes.
>>
>> Now, putting the "CE IPv6 prefix length" back as a rule parameter shouldn't be a problem if the idea of linking IPv4 and IPv6 sizes of address spaces is abandoned (a choice that, I have to agree, simplifies the design).
Not "abandoned" actually, just not that tightly :-). L is not necessary 
by a CE when deriving its v4 space, since it would have got the length 
of prefix delegated to it (so, the L in the rule picked should match the 
length of delegated prefix). The sharing ratio is determined together by 
the L (Rule IPv6 prefix), L (Rule IPv4 prefix) and the L (delegated 
prefix). For example, for a given L (delegated prefix), the other two 
"L" can be changed to get different sharing ratios, or to maintain an 
identical sharing ratio within a domain even the L (delegated prefix) is 
variable.

L (in the matching rule based on IPv4 destination address) allows the CE 
to know the exact number of bits to pick from the port when forming the 
IPv6 destination address.

>>
>> Cheers,
>> RD
> I think that it should be exclusive in a domain but it could be coexist in the map specification.
Sorry, I don't quite follow, can you please say a little more?


Cheers,
Jacni

>
> cheers,
> --satoru
>
>