Re: [Softwires] MAP documents - next steps

Jacni Qin <jacni@jacni.com> Mon, 06 February 2012 02:24 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 80B1021F852B for <softwires@ietfa.amsl.com>; Sun, 5 Feb 2012 18:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.013
X-Spam-Level: ***
X-Spam-Status: No, score=3.013 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 v-L8t00L+jhD for <softwires@ietfa.amsl.com>; Sun, 5 Feb 2012 18:24:03 -0800 (PST)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 598D421F8514 for <softwires@ietf.org>; Sun, 5 Feb 2012 18:24:02 -0800 (PST)
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 17F323801D2 for <softwires@ietf.org>; Sun, 5 Feb 2012 21:24:01 -0500 (EST)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 5C4173400BB for <softwires@ietf.org>; Mon, 6 Feb 2012 10:23:59 +0800 (CST)
Received: from [114.81.86.160] (unknown [114.81.86.160]) by app (Coremail) with SMTP id +AWowJC7SQSkOS9P4jdpAA--.28659S2; Mon, 06 Feb 2012 10:23:47 +0800 (CST)
Message-ID: <4F2F3A6C.5090002@jacni.com>
Date: Mon, 06 Feb 2012 10:26:52 +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: =?ISO-8859-1?Q?Ole_Tr=F8an?= <otroan@employees.org>
References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org>
In-Reply-To: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org>
Content-Type: multipart/alternative; boundary="------------030301070400000102010108"
X-CM-TRANSID: +AWowJC7SQSkOS9P4jdpAA--.28659S2
X-Coremail-Antispam: 1UD129KBjvJXoWxGFWDtrWxtr1kuF1rWF4fAFb_yoWrWFWDpa 9ayrsxWw4DJr18Gwn7Xw4fZwnYvrn3XF47AFy5Jw1Fkr98Z3W0yF40kw1Fvay8ZryrAF47 Xr4j9ry5AFs8Z3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWkKwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07j6wZcUUUUU=
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIQEko7lP+F8gAAss
Cc: softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] MAP documents - next steps
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: Mon, 06 Feb 2012 02:24:04 -0000

Hi all,

On 1/30/2012 7:31 PM, Ole Trøan wrote:
> hi,
>
> the MAP (Mapping of address and port) design team has now written and published the following sets of drafts.
>
> the base document (port mapping algorithm):
>    http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03
>    http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping-address-and-port-03.txt
>
> the encapsulation document (MAP-E):
>    http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00
>
> the translation document (MAP-T):
>    http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00
>
> the DHCP option (MAP-DHCP):
>    http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02
>
> there is a MAP deployment document coming soon.
>
> the solution described in this set of documents, are written to satisfy the following from the softwires charter:
>     4. Developments for stateless legacy IPv4 carried over IPv6
>        - develop a solution motivation document to be published as an RFC
>        - develop a protocol specification response to the solution
>          motivation document; this work item will not be taken through
>
> in the design team's view, this set of documents are ready to be adopted as working group documents.

No objection to the adoption of the base document, with some comments 
(sorry if they've been discussed ever), please check below.
BTW, another question, I can' t remember the conclusion when the DT was 
chartered, whether the -E and -T were the missions of the DT, or not?


----------------------------------------------------
1. Section 4., ...

    The forwarding function uses the MRT to make forwarding decisions.
    The table consist of the mapping rules.  An entry in the table
    consists of an IPv4 prefix and PSID.  The normal best matching prefix
    algorithm is used.  With a maximum key length of 48 (32 + 16).  E.g.
    with a sharing ratio of 64 (6 bit PSID length) a host route for this
    CE would be a /38 (32 + 6).

I'm confused here. The forwarding is based on routing tables (while IMHO 
the Section 5.3 & 5.4 state it clearer),
the implementations may vary while the basic logic could be:
Each FMR should install one corresponding route in the IPv4 RIB, like,

Rule IPv4 prefix -> "connected", MAP Interface1

For outbound traffic from the private network, when the IPv4 RIB lookup is
performed, it should hit one element with a MAP interface, which can be
used as the pointer to the correct FMR in the MRT, to form the MAP IPv6
address of the destination.


2. Section 5.1.3., more text about what the "offset bits" is for, may 
need to
be added, something like, "The length of offset bits determines the excluded
ports ..."


3. Section 5.2., ...

    The offset of the EA bits field in the IPv6 address is equal to the
    BMR Rule IPv6 prefix length.  The length of the EA bits field (o) is
    given by the BMR Rule EA-bits length.  The sum of the Rule IPv6
    Prefix length and the Rule EA-bits length MUST be less or equal than
    the End-user IPv6 prefix length.

The prefix6-len + EA-bits len must be equal to the End-user IPv6 prefix
length, why there is a "less than"? Any reasonable use case about it?


4. Section 6.,  ...

    In an encapsulation solution, an IPv4 address and port is mapped to
    an IPv6 address.  This is the address of the tunnel end point of the
    receiving MAP CE.  For traffic outside the MAP domain, the IPv6
    tunnel end point address is the IPv6 address of the BR.  The
    interface-id used for all MAP nodes in the domain MUST be
    deterministic.

How to do that, to make the interface-id deterministic? By the
interface-id formula specified?

    ...

    The encoding of the full IPv4 address into the interface identifier,
    both for the source and destination IPv6 addresses have been shown to
    be useful for troubleshooting.

Does this statement apply to translation only, or to both?
----------------------------------------------------------


Cheers,
Jacni

>
> comments?
>
> for the MAP design team,
> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>