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

Rémi Després <despres.remi@laposte.net> Sat, 04 February 2012 06:46 UTC

Return-Path: <despres.remi@laposte.net>
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 D367221F853D for <softwires@ietfa.amsl.com>; Fri, 3 Feb 2012 22:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 NmS1Ejse-pPg for <softwires@ietfa.amsl.com>; Fri, 3 Feb 2012 22:46:35 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 845A121F8535 for <softwires@ietf.org>; Fri, 3 Feb 2012 22:46:32 -0800 (PST)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9B82994001B; Sat, 4 Feb 2012 07:46:20 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net>
Date: Sat, 4 Feb 2012 07:46:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF557BF6-C20D-455E-A873-00D9F811F9A0@laposte.net>
References: <B140D6B2-1B19-43D7-9B63-6BEA83CEB164@juniper.net> <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net>
To: Alain Durand <adurand@juniper.net>
X-Mailer: Apple Mail (2.1084)
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: Sat, 04 Feb 2012 06:46:35 -0000

Le 2012-02-02 à 18:35, Alain Durand a écrit :

> Please, Remi, do build such a table! That would be very useful.

OK, will do it next week.
RD

> 
> Alain.
> 
> Sent from my iPad
> 
> On Feb 2, 2012, at 10:56 AM, "Rémi Després" <despres.remi@laposte.net> wrote:
> 
>> Hi Ole,
>> 
>> This kind of table you have below is IMHO the tool we need at this stage :-).
>> 
>> It has however to be more detailed: so far, it covers 4rd-H (the header-mapping variant of the last 4rd-U), but not 4rd-E (its encapsulation variant).
>> A 4 columns table would be ideal. Also, It could have a sign identifying points that are N in current drafts, but  could easily become Y if the final consensus is that they are worth the additional complexity.
>> I can work on it if you are interested.
>> 
>> More specific points below.
>> They can be discussed one by one.
>> 
>> 
>> Le 2012-02-02 à 11:12, Ole Trøan a écrit :
>> 
>>>> More over, 4rd-U claims to solves a number of issues that the MAP suite of documents does not address. It would be beneficial to have
>>>> a discussion on the mailing list  to see if a) those issues are important or not and b), if they are, are they properties of 4rd-U or could they be solved as well
>>>> in MAP, they just have not been addressed there yet.
>>> 
>>> 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.)
>> 
>>> | 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).
>> 
>> 
>>> | 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. 
>> 
>>> | 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.
>> 
>> 
>>> | 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.
>> (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.
>> 
>>> | 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).
>> 
>>> | Fragment forwarding on BR     |        N       |         Y        |
>>> | without reassembly            |                |                  |
>>> | Shared fragmentation id space |        N       |         Y        |
>>> | BR rewrite fragmentation      |        N       |         Y        |
>> 
>> 
>>> | 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?
>> 
>>> | 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.
>> 
>>> | Provisioned with DHCP         |        Y       |         Y        |
>>> +-------------------------------+----------------+------------------+
>>> 
>>>                       Table 1: A+P comparison
>> 
>> 
>> Cheers,
>> RD
>> 
>> 
>>> 
>>> let us make it clear that these two solutions are solving exactly the same problem, and they solve it in the same fundamental way (A+P). the differences we're talking about here are what whistles, bells (and dongs) we want to add on to the base specification. consider it a buffet, any feature from one of them can be applied to the other.
>>> 
>>> cheers,
>>> Ole
>>> _______________________________________________
>>> 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