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" <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
