Re: [Softwires] MAP and 4rd - Feature comparison table

Ole Trøan <otroan@employees.org> Fri, 10 February 2012 14: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 E9AD321F8757 for <softwires@ietfa.amsl.com>; Fri, 10 Feb 2012 06:25:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 D0H9rsytAtFN for <softwires@ietfa.amsl.com>; Fri, 10 Feb 2012 06:25:12 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF5921F8747 for <softwires@ietf.org>; Fri, 10 Feb 2012 06:25:12 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so2626928wib.31 for <softwires@ietf.org>; Fri, 10 Feb 2012 06:25:11 -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=WvAbDL5kMGikE3XRk3QhItih82rSO5+o7ApuKKewXDs=; b=nI+szDdc4+aFHsIZg736tluN6enqFi/qzT0Chd77miXxzb5efK6h2Pr0ZFqO2odzM+ 0I4JRwcD3CKEkp1hzeTCkYqi6W5ysEnxFY2q5uUJ0OVFZ7WzKu6gmIW7DEhcvb9Mti7/ W01psLH5Uu+6R0B8dsuvzWUQX9k8h+H5LlSmA=
Received: by 10.180.85.105 with SMTP id g9mr3519063wiz.12.1328883911201; Fri, 10 Feb 2012 06:25:11 -0800 (PST)
Received: from [192.168.4.69] (a50.fluent.fr. [195.68.67.50]) by mx.google.com with ESMTPS id ho4sm3594492wib.3.2012.02.10.06.25.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 06:25:09 -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: <972877C3-EFA3-4B65-BD98-547F643D94D1@laposte.net>
Date: Fri, 10 Feb 2012 15:25:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0239FF2-84C7-4ADB-A027-6E9469204C25@employees.org>
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> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <972877C3-EFA3-4B65-BD98-547F643D94D1@laposte.net>
To: Rémi Després <despres.remi@laposte.net>
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] MAP and 4rd - Feature comparison table
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, 10 Feb 2012 14:25:14 -0000

Remi,

>>> New version, after a discussion with Ole:
>>> 
>>> +----+--------------------------------------+-----+-----+-----+-----+
>>> |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd |
>>> |    |                                      |  -T |  -E |  -H |  -E |
>>> +----+--------------------------------------+-----+-----+-----+-----+
>>> |  1 | Full Transparency to IPv4 DF bit     |  N  |  Y  |  Y  |  Y  |
>>> |    |                                      |     |     |     |     |
>>> |  2 | ISP can impose a Tunnel traffic      |  N  |  Y  |  Y  |  Y  |
>>> |    | class                                |     |     |     |     |
>>> |    |                                      |     |     |     |     |
>>> |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  |
>>> |    | third-party CPEs                     |     |     |     |     |
>> 
>> possible with MAP-{E,T} too, but may require coordination of subnet numbering.
> 
> Your describing what you have in mind would be useful.
> So far I see the 4rd-U approach as the only specified one that is viable.

MAP uses the first subnet of a End-user IPv6 prefix. to deploy a MAP CE behind another IPv6 CE, the only thing required is to route the prefix (/64) used for MAP to this CE. 

both 4rd-u and MAP assume that prefix assignment with multiple routers is solved, and that some other  mechanism exists for provisioning.

I don't see the point of having text in the specification for this use case. it is a deployment option.

>> in all solutions will require a different provisioning model.
> 
> Not sure what you mean.
> Anything missing in 4rd-U in this respect?
> 
>>> |    |                                      |     |     |     |     |
>>> |  4 | IPv6 port-based ACLs work for IPv4   |  Y  |  N  |  Y  |  N  |
>>> |    | packets                              |     |     |     |     |
>> 
>> suggest we rename this to "IPv6 features can be applied to the payload packet"?
>> (we're talking about applying features in between the translators/tunnel endpoints here).
> 
> The point being true, I don't see a need to change it.
> What you propose is less precise, and IMHO consequently less useful.

there are many more features than just ACLs.
you are misleading when stating that the IPv6 ACLs work on IPv4 packets. they don't.

>> you could also add a new feature:
>> "possible to apply IPv4 features on the payload"
> 
> Don't understand what it means in practice.

a reason for T is to be able to apply "native IPv6 features" in the network. given that there is a feature gap between IPv4 and IPv6 support in existing gear, where IPv4 features are better supported. then an E solution could allow IPv4 features to be applied to tunnel packets. in practice:
    pak->network_start += 40.
    apply IPv4 features to inner packet
    pak->network_start -= 40

>> which is possible if IPv4 features are enhanced to support offset the tunnel encap header.
>> so:
>> 
>> | 4.1 | IPv6 features can be applied to the payload packet"  | Y | N | Y | N|
>> | 4.2 | IPv4 features can be applied to the payload with     | N | Y | N | Y|
>> |     | "tunnel vision                                  
>> 
>>> |    |                                      |     |     |     |     |
>>> |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  |
>>> |    | packets                              |     |     |     |     |
>> 
>> suggest you rename to "IPv4 to IPv6 communication (single translation) supported"
> 
> With any interpretation I can imagine of of what you write, I see this as a different point.
> OTOH, I acknowledge that there is a point worth analysing about the relationship with single translation.
> More about this in my forthcoming answer to Xing.

can a T session terminate in a native unchanged IPv6 host? as long as this host has an IPv6 MAP address?
that is single translation. and implies that T packets "leak" into the native network. examples of use cases for this is web caching, captive portals, or just providing IPv4 access to IPv6 only servers.
given the wider scope, your feature name is not sufficient.

>>> |    |                                      |     |     |     |     |
>>> |  6 | No constraint on host addresses or   |  N  |  N  |  Y  |  Y  |
>>> |    | subnet prefixes in CE sites (V-octet |     |     |     |     |
>>> |    | format)                              |     |     |     |     |
>> 
>> I don't agree with this wording. actually the MAP interface-id has less constraints, in that it doesn't depend on the V-octet. what about emphasizing the problem V solves?
> 
> I added "addresses" following the technical discussion we had on Wednesday, understanding that it was sufficient for the statement to be true.
> Are you negating that current MAP drafts MAY imply a change of subnet prefix or host address in CE sites that assigned them before adding MAP support?
> If yes, please explain.

as I said with a mapping resulting in a 128 bit tunnel end point address, that can be taken out of the first /64 even if this is used by native hosts. the probability of collision is minimal.


>> "Native IPv6 hosts can co-exist with MAP node on the same subnet"
> 
> ??
> 
>> or  "Reserved subnet needed for MAP function"
> 
> The table is written so that Y is always positive.

yes, I think that a separate /64 prefix or separate /128 address is used for the MAP function is a positive.

>> I also think you need to add:
>> | N | "New format of interface-id needs to be standardized | N | N | Y | Y |
> 
> True, but not an operational feature.

your table has non-operational features. the usefulness of the table in my mind, is to identify the differences between MAP and 4rd-u and evaluate features that potentially can be added to MAP.
the purpose of the MAP team, was to do a first pass on that, and in the existing proposals we dropped many proposed features. you re-propose some of them in 4rd-U and all add some news ones. it is fair that those get a fair hearing. I don't think this table is restricted to "operational features"

> Clarifying that the unused combination of "u" and "g" bits can be used as an escape mechanism is useful for any new Interface ID formats that may prove useful in the future. 4rd-U is only the first instance of that.

if you did that, then the new mechanism would conflict with 4rd-U.

>>> |  7 | Number of excluded ports is flexible |  Y  |  Y  |  N  |  N  |
>>> |    | (GMA algorithm, 2 parameters)        |     |     |     |     |
>>> |    |                                      |     |     |     |     |
>>> |  8 | Possible migration from DS routing   |  N  |  N  |  Y  |  Y  |
>>> |    | to IPv6-only routing without         |     |     |     |     |
>>> |    | changing CE addresses and/or         |     |     |     |     |
>>> |    | prefixes (DMR may apply to CEs)      |     |     |     |     |
>> 
>> all mechanisms do support this.
> 
> Well, the current MAP draft says:
> - "There are three types of mapping rules"
> - In a CE, "A MAP IPv6 address (or prefix) is formed from the BMR Rule IPv6 prefix"
> I found this confusing, but I am ready to acknowledge that, by making it very clear that a mapping rule can have simultaneously several types, there can be Y in the 4 columns.
> 
> A problem will still remain in the hub&spoke case because MAP has "In hub and spoke mode, all traffic MUST be forwarded using the Default Mapping Rule." Then, if some CEs have their MAP IPv6 address (or prefix) derived with this rule, packets sent to them from other CEs will be routed directly to them, the contrary of hub&spoke. 
> 
> I suppose that MAP can add the "toBR" bit (bit 79 in 4rd-U) to solve this problem. (I didn't check however, whether this would remain safe without the V octet).

no, I don't see why the bit 79 would be needed in MAP.
the CE will configure itself with an IPv4 address and port set from the BMR. given that it is in hub and spoke mode it will not install any FMRs, but only a DMR. all traffic not being for itself, will be forwarded using the DMR.

>> this is purely a deployment option in my mind, more than it separates the mechanisms.
> 
> 
>> I would suggest you drop it.
> 
> Once you make clear that a Mapping rule can be both Default and Basic, I would rather restrict its scope to hub&spoke (see above). 

no, two rules are used for this.

>> it requires a separate IPv6 prefix purely for the MAP function, and it requires importing IPv4 routing into IPv6.
>> 
>>> |    |                                      |     |     |     |     |
>>> |  9 | BRs need no change for any new       |  N  |  N  |  Y  |  Y  |
>>> |    | protocol having ports at their usual |     |     |     |     |
>>> |    | place and TCP-like checksum          |     |     |     |     |
>>> |    | (checksum neutrality)                |     |     |     |     |
>> 
>> I don't think that is correct.
> 
> Please read the sentence once more, and say exactly which words make it untrue.

the "no change"

>> an implementation would have to verify that the ports is actually in the place the algorithm expects. and it needs to check that the transport protocol uses a TCP-like checksum.
>> any MAP node MUST be L4 aware.
>> you could add:
>> 
>> |9.1|New transport protocols can be supported regardless of L4 header format and checksum algorithm| Y | Y | N | N |
> 
> The point is "without change". 
> (With a change, any solution can be said to have new features.) 

you can't do that "without change". that would result using random bits for ports in L4 protocols that has a different layout. given that, you need to check the L4 protocol, and only accept the ones you support. CNP does not make supporting new L4s simpler.

>>> |    |                                      |     |     |     |     |
>>> | 10 | IPv4-options supported               |  N  |  Y  |  N  |  N  |
>>> |    |                                      |     |     |     |     |
>>> | 11 | Datagram reassembly avoided in BRs   |  N  |  N  |  Y  |  Y  |
>> 
>> right, I would expect this would be added to MAP too.
> 
> Good.
> 
>>> |    |                                      |     |     |     |     |
>>> | 12 | Packet IDs from shared-address CEs   |  N  |  Y  |  Y  |  Y  |
>>> |    | cannot be confused in destinations   |     |     |     |     |
>> 
>> likewise for this one. so it would be Y all around.
> 
> Good.
> As indicated, this table is about current drafts.
> 
>>> |    |                                      |     |     |     |     |
>>> | 13 | The number of rules CEs must be able |  N  |  N  |  Y  |  Y  |
>>> |    | to support is defined                |     |     |     |     |
>> 
>> do we typically state the lower limit of the size of tables (e.g. BGP table) in IETF specifications?
> 
> Completely different.
> ISPs that have many IPv4 prefixes MUST know how many rules to specify in each Domain to make sure all independently acquired CEs can work in mesh topology.
> Do you deny that this number is useful?

yes. the number is a guess. we risk ending up with implementations _only_ supporting the smallest number. as we have little deployment experience that's a bad idea.

> (BTW, sorry we didn't discuss this point on Wednesday, I had it on a list but skipped it.)
> 
>> 
>>> |    |                                      |     |     |     |     |
>>> | 14 | Minimum IP header length             |  40 |  60 |  48 |  60 |
>>> +----+--------------------------------------+-----+-----+-----+-----+
>> 
>> I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 | 40 |
> 
> Fortunately you have more substantial points ;-).
> (This line is just informational.)
> 
>> I also suggest you add the features:
>> 
>> | 15 | Handle IPv4 UDP checksum = 0 | Y | Y | N | Y |
> 
> Could you be more specific about what MAP does for this, separating MAP-T and MAP-E?

MAP-E carries the IPv4 packet unchanged and doesn't touch the UDP checksum.
MAP-T rewrites the UDP checksum to a valid IPv6 packet and re-translates it to an IPv4 UDP packet with a checksum.
not transparent, but keeps a valid IPv6 packet inside the domain.

>> | 16 | Running code                 | Y | N | N | N |
> 
> Running code is definitely good, but not sufficient to say that a feature is good to have?
> OTOH, we agree that lines 12 an 13 are good to have without running code.

I'm saying that the best technology, even if it was perfect doesn't "win". running code does.

cheers,
Ole