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

[Rémi Després <[e-mail]>]

Le 2012-02-03 à 13:25, Ole Trøan a écrit :

> 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.

Unless use cases showing a practical limitation of 4rd-U in this respect, this line can then be left out.
OK?

> 
>>> | 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.

The design team is mandated to assemble a particular proposal, and the WG then decides what to do with it, globally or piece by piece. 


>>> | 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

Present or future without change?

> (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.

Indeed, so that an IPv6 site to which MAP support is added may have to change its intra-site subnet assignments for this.
This is avoided with the V octet.

> 
>> (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:*

 (6.a) In BRs or CEs, the first * isn't needed because its value is fixed so that best matching works.
 (6.b) In middle boxes, if this is what you discuss, testing the V octet is sufficient. 
 (6.c) Note that use cases where middle boxes interpret tunnel packets is the case where MAP-T and 4rd-H have their functional advantages over MAP-E and 4rd-E. 


> 
>>> | 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 4rd-U algorithm is: "A port of the port set contains the PSID, starting at bit 4.

- The MAP algorithm is:
"1. The port number (P) of a given PSID (K) is composed of: P = R * M * j + M * K + i
Where:
 *  PSID: K = 0 to R - 1 
 *  Port range index: j = (4096 / M) / R to ((65536 / M) / R) - 1, if the port numbers (0 - 4095) are excluded.
 *  Contiguous Port index: i = 0 to M - 1 
2.  The PSID (K) of a given port number (P) is determined by: 
   K = (floor(P/M)) % R
  Where:
 *  % is the modulus operator
 *  floor(arg) is a function that returns the largest integer not greater than arg."

- It has to be faced that this isn't the same algorithm. This difference is significant because the simpler the algorithm, the simpler is personnel training, and the simpler if network maintenance. 
 
> 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?

 (6-bis) As explained in the draft, not for packets from ALL CEs.
 But the 4rd-U draft does propose ID rewrite in BRs for packets from CEs having shared addresses.
 Reason, explained in the draft, is that if original IDs are kept unchanged for shared-address CEs, reassembly may be broken in destination end points. 
 A discussion of this point, which so far had only been discussed verbally, is of course welcome.


> instead of making the CE use the fragmented fragmentation (sic!) space directly?

Not understood.

> 
> 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).

- Sec 5.1 says: 
"As far as mapping rules are concerned, the simplest deployment model is that in which the Domain has only one rule (the Default mapping rule). To assign an IPv4 address to a CE in this model, an IPv6 /112 is assigned to it comprising the BR /64 prefix, the V octet, a null octet, and the IPv4 address."
 Also, the use case of 5.3 uses full IPv4 addresses.
 I agree however that the text could make it clearer.

-  A Mapping rule that has Rule IPv4 prefix = 0 and EA-bits length < 32 assigns an IPv4 prefix.


Cheers,
RD

BTW, could you use my e-mail address that works in Softwire, otherwise my responses get lost.
Thanks. 

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