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

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

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