Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U

Ole Trøan <otroan@employees.org> Fri, 03 February 2012 12:25 UTC

Return-Path: <ichiroumakino@gmail.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 2484E21F85D3 for <softwires@ietfa.amsl.com>; Fri, 3 Feb 2012 04:25:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.366
X-Spam-Level:
X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 ZaVUQiKEzYHt for <softwires@ietfa.amsl.com>; Fri, 3 Feb 2012 04:25:49 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0556A21F85CE for <softwires@ietf.org>; Fri, 3 Feb 2012 04:25:48 -0800 (PST)
Received: by werm10 with SMTP id m10so3249303wer.31 for <softwires@ietf.org>; Fri, 03 Feb 2012 04:25:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1m4Xa4gHjaZoSz67oZvN0CqEbhhLNwXgn+bLyEZwROU=; b=qeY2WNX9bYX2wqCkYRCTmoif04/RirIBLamAtdgn6ntii24NXRBvxoWZD0y3GjmDFh +cl2WdrMOo315Mdd4jveIUap1CvyUcdbayvGAZq/7PtjRXtCBhJbcHi4zJy8qHgxSinQ bYsQZwltj02rc9jjNVrvYZZKJHYB9zvHJE8xY=
Received: by 10.216.139.79 with SMTP id b57mr6379634wej.22.1328271948054; Fri, 03 Feb 2012 04:25:48 -0800 (PST)
Received: from [10.147.13.173] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id l8sm16899371wiy.5.2012.02.03.04.25.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 04:25:47 -0800 (PST)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="iso-8859-1"
From: Ole Trøan <otroan@employees.org>
In-Reply-To: <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>
Date: Fri, 03 Feb 2012 13:25:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C694D7DC-2F98-434F-8123-751E2C1A98D0@employees.org>
References: <B140D6B2-1B19-43D7-9B63-6BEA83CEB164@juniper.net> <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>
To: Rémi Després <remi.despres@free.fr>
X-Mailer: Apple Mail (2.1257)
Cc: softwires WG <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U
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: Fri, 03 Feb 2012 12:25:50 -0000

Remi,

>> here is a comparison table of the feature differences between MAP and 4rd-U.
>> (try a fixed width font if it doesn't survive your particular MUA mail mangling algorithm.)
>> 
>> Appendix A.  Comparions of stateless A+P solutions
>> 
>>  +-------------------------------+----------------+------------------+
>>  | Feature                       |       MAP      |       4rd-U      |
>>  +-------------------------------+----------------+------------------+
>>  | Encapsulation                 |        Y       |         Y        |
>>  | Translation                   |        Y       |         Y        |
>>  | Hub and Spoke mode            |        Y       |         Y        |
>>  | Nested CPE                    |        N       |         Y        |
>>  | End-user prefixes > 64        |        Y       |         N        |
> 
> (1)It is AFAIK also a "Y" for 4rd.
> (Not sure to understand the point.)

I might have misunderstood R-11 and R-24. it depends on the V octet.
but I suppose for any solution it is more of a deployment choice than a inherent limitation to the mechanism.

>>  | E-mode: Support for IPv4      |        Y       |         N        |
>>  | options                       |                |                  |
> 
> (2) 4rd-U draft 03 has excluded IPv4 options for both 4rd-H and 4rd-E but, for 4rd-E, they can easily be put back if found useful. (My vote is NO, but a WG consensus on YES for 4rd-E would not be a problem at all).

indeed, part of the smorgasbord of features the working group can choose between.

>>  | T-mode: MF bit and TOS bits   |        N       |         Y        |
>>  | transparency                  |                |                  |
>>  | T-mode: Checksum              |   L4 rewrite   |        CNP       |
> 
> (3) The functional point is guaranteeing IPv4-payload preservation, with compatibility with ALL protocols using TCP-like checksum, present of future, with checksums anywhere in the payload. 

the MDT recommends L4 rewrite:
 - this is what existing implementations do
 - works for any L4 protocol (MAP has to be L4 aware for port anyway)

>>  | H & S set bit 79 needed       |        N       |         Y        |
> 
> (4) The functional point is to permit use cases like that of 5.3 of the last 4rd-U draft.
> The added complexity for this is close to nil, and applies ONLY to H&S scenarios.
> 
> If abandoned (which is easy), it should be with due WG consciousness of  which use cases are thus abandoned.

indeed.

>>  | Interface-id                  |     RFC6052    |      V octet     |
>>  | MAP traffic identified by     | Address/prefix |  Interception of |
>>  |                               |                |      V octet     |
> 
> (5) The main functional point of the V octet is to avoid interfering with subnet assignments in customer sites.

the MDT recommendation is to set aside a prefix or an IPv6 address to terminate MAP traffic.

> (6) Not sure to understand what you mean by "Interception of V octet". IPv6 routing within CEs or BRs is sufficient to orient IPv6 packets to the 4rd function.

if classification of MAP packets versus native packets have to be done, not using the best matching prefix algorithm, but a non contiguous mask. e.g.:

 a match on:
2001:db8:1234:*:0V00:*

>>  | Port mapping algorithm        |   GMA. Prog.   |    GMA. Fixed    |
> 
> (7)  Substantial complexity added for GMA isn't justified, in my understanding, by real use cases that would need it. 
> This could easily be added to 4rd-U if so decides the WG (a waste IMHO).

GMA and the 4rd-U algorithm is the same algorithm. with the same bit representation on the wire.
the MAP text goes in more detail in explaining how to calculate the port ranges and so on.
4rd-U has fixed (a) the offset bits, while MAP has the same default, but allows it to be configured.

>>  | Fragment forwarding on BR     |        N       |         Y        |
>>  | without reassembly            |                |                  |
>>  | Shared fragmentation id space |        N       |         Y        |
>>  | BR rewrite fragmentation      |        N       |         Y        |

btw, in 4rd-U did you intend for the BR to rewrite the fragmentation id on packets to the Internet from the CEs?
instead of making the CE use the fragmented fragmentation (sic!) space directly?

I think the fragmentation ideas are well worth considering btw.

>>  | MSS update                    |        Y       |         N        |
> 
> (8) I found no reference to MSS in MAP-E, and no reference to MSS update in MAP-T.
> Did I miss them?

RFC6145 mentions it at least. I don't think MAP-E should do anything on MSS, in that case it would be part of the NAT function prior to encapsulation.

>>  | Complete IPv6 address /       |        Y       |         N        |
>>  | prefix                        |                |                  |
> 
> (9) Not sure what you mean by a complete IPv6 prefix. I see no functional limitation of 4rd-U with prefix lengths.

ah, misspelling. MAP describes how to provision a complete IPv4 address or IPv4 prefix. (not IPv6 of course).

>>  | Provisioned with DHCP         |        Y       |         Y        |
>>  +-------------------------------+----------------+------------------+
>> 
>>                         Table 1: A+P comparison
> 

cheers,
Ole