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

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

Le 2012-02-09 à 18:23, Ole Trøan a écrit :

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

> you could also add a new feature:
> "possible to apply IPv4 features on the payload"

Don't understand what it means in practice.

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


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


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


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

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.  

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


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

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


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

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

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


RD



> 
> cheers,
> Ole
>