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

[Ole Trøan <[e-mail]>]

> 
> 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.
in all solutions will require a different provisioning model.

>   |    |                                      |     |     |     |     |
>   |  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).
you could also add a new feature:
 "possible to apply IPv4 features on the payload" 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"

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

"Native IPv6 hosts can co-exist with MAP node on the same subnet"
or  "Reserved subnet needed for MAP function"

I also think you need to add:
| N | "New format of interface-id needs to be standardized | N | N | Y | Y |


>   |    |                                      |     |     |     |     |
>   |  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. this is purely a deployment option in my mind, more than it separates the mechanisms. I would suggest you drop it.
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. 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 |

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

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

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

>   |    |                                      |     |     |     |     |
>   | 14 | Minimum IP header length             |  40 |  60 |  48 |  60 |
>   +----+--------------------------------------+-----+-----+-----+-----+

I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 | 40 |

I also suggest you add the features:

| 15 | Handle IPv4 UDP checksum = 0 | Y | Y | N | Y |
| 16 | Running code                 | Y | N | N | N |

cheers,
Ole