Le 2012-04-02 à 12:33, Ole Trøan a écrit : >> If this is to say that until a BOF is started, you will keep your >> objection(s) unknown, I continue to take it as a lack of identified >> objections. > > the objections I'm aware of are: > - people are uncomfortable with only a double translation solution
Are you furtively suggesting that 4rd-U has all limitations of a real double translation solution like MAP-T? That mays sound tactically smart, but isn't justified by facts. > * injection of IPv4 routes into IPv6 No need for this with 4rd-U (and BTW not even needed with MAP-T, AFAIK) > * transparency 4rd-U is fully transparent. It has been precisely designed for this (and to simultaneously keep compatibility with IPv6-only O&M). > * hard to identify IPv4 traffic in the "core" The V octet is precisely what facilitates IPv4-traffic identification in the core. > * higher risk of leakage. i.e single translation / packets outside the > domain > (all these apply equally to MAP-T btw) ??? If you have a reference explaining which new risk you see, I will look at it. > - redefining the modified EUI-64 format (V-octet) As said in the draft, the u=g=1 combinations of the V octet 'differs from "u" = 0, reserved for local-scope Interface IDs, and also differs from "u" = 1 and "g"= 0, reserved for unicast Interface IDs using the EUI-64 format.' There is therefore no "redefinition" of the modified EUI-64 format. > and the consequences standardization wise of that > - overloading information in the fragment header Using, between CEs and BRs, unused bits of packet IDs doesn't interfere with any existing RFC, independently from its being considered overloading or not. > (please don't respond to these, FYI only. I'm on Easter holiday.) Asking that a list of objections shouldn't be answered is to me very unusual! (You need not to look at my response before you return from holiday!) > if it wasn't for my general "uncomfortableness" with double-translation I'd > could be convinced that a single solution was possible. > > the status quo; with no path forward just means that we'll effectively kill > A+P. Validating 4rd-U with running code, clearly isn't status quo; It is a path forward which, in case of success, will also be success of the generic A+P approach. > I would certainly not recommend my product managers to implement either of > this given the risk. Either of this??? > is there consensus to abandon these efforts (which is basically what we do by > publishing them as experimental anyway)? Suggesting that validating 4rd-U would be abandoning the A+P effort is very daring. It is precisely a way to try and have a clean and unique standard for shared addresses: - working on mesh topologies - without per-customer state in ISP nodes > the alternatives we have are perfectly fine: > - Shared IPv4 address over IPv4 transport -> NAT444 / CGN > - Shared IPv4 address over IPv6 transport -> 464XLAT / DS-lite > - Full IPv4 address over IPv6 transport -> DS-lite with Public IPv4 address Your suggesting that these three might be sufficient is really strange: - none of these supports mesh topologies - In order to support shared addresses, all these need per-customer or per session states in network devices. > problem solved. ;-) Enjoy you vacation. RD > > cheers, > Ole > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
