IETF to standardize new democratic selection mechanism – the coin
IETF Softwire working group on Friday was all about discussion on which proposal among “Stateless A + P” variants to choose as the standard, which means that winner goes to “Standards Track” and the ‘looser’ goes to the “Experimental Track”. We were deciding between the options MAP-E/MAP-T and 4RD-U …
After a long verbal battle (that seemed more like a boxing ring) there is yet no decision or consensus. I often mentioned at the microphone that the decision must be made here today in any case, even with a usage of a mechanism similar to the choice of Pope – locked room and nobody goes out until we reach consensus on a choice.
MAP-E is a variant of the A + P, which is using encapsulation as a transport, which means that the IPv4 “Payload” does not change, but only encapsulates the IPv6 packet.
MAP-T is similar variant of the A + P, but it translates IPv4 packets into IPv6 packets and at the core back to IPv4. E-MAP and MAP-T form a logical package and should be implemented in a single product where you can choose the behaviour – depends on if you want to operate in a translation or encapsulation mode.
4RD-U is a “Unified” solution that combines both options and operates both as a translation and encapsulation at the same time.
Difference and comparison between the variants is quite well described in this document .
Understanding the high polarization of A+P community, the undersigned has clearly expressed its support for the MAP system, since in this case the operator may decide between encapsulation and the translation mode. This means that if encapsulation is preferred, there is no trace of translation (and vice versa).
Since we did not achieve consensus and the Internet and vendors are waiting a decision, because the IPv4 address space is running out – the IETF decided to standardize the choice with the flip of a coin, because in this case it would came in very handy.
The first dilemma with the definition of the coin, of course, is the currency – or is it Euro or Dollar or something else. Then it is necessary to define the weight of the coin, the coin size and the minimum height of the coin-throw. We should also make a decision between two landing modes: a coin thrower captures the coin and turns it on hand, or letting the coin drop on the floor. Then it should be accurately identified who of the bidders decides first the side of the coin – as this is an important decision. Most important of all, it must be defined that the coin must have two different sides, one of which must contain at least one number, and what does it mean when a coin is dropped on the floor (or on hand) – does the up-facing side wins or looses …
Since this is not a standardized method of choice and consensus declaring in the IETF yet (and regarding the complexity of the dilemmas will not be anytime soon), it can not yet be used in decision-making procedures as this one, which subcategory of A+P will be “the one”. Well, pitty 🙂
But regarding the amount of new proposals and lack of consensus also in other working groups IETF is seriously looking into this democratic decision selection mechanism.
Jan Žorž 🙂
Vaš IP naslov (ali ste na IPv6 ?):
18.216.146.152
You know, I think this document: http://datatracker.ietf.org/doc/draft-despres-softwire-stateless-analysis-tool/?include_text=1 can be one of the causes of the lack of consensus in the meeting. It is very well written, but it’s just comparing theoretical behaviors. MAP is a good choice and it is the only one with some running code. Since we are running against time here, I think that we really should focus on this choice.
If I had considered just this text, this analysis-tool, without reading the actual drafts, without following the list, without seeing the presentations on dIVI at APNIC meeting, without considering the IPv6 transition status, I could have voted for 4rd, or for both… Maybe some people in that meeting had done just that, had read only this theoretical analysis-tool, and then voted.
It seems that the softwire list itself is not so divided.
[]s
http://fredbovy.com
thanks for ssharing!