Le 2012-02-02 à 18:35, Alain Durand a écrit : > Please, Remi, do build such a table! That would be very useful.
OK, will do it next week. RD > > 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
