2012-06-23 à 10:52, Satoru Matsushima: > Dear Remi, > > Thank you for a kind offer. It would be a very positive compromise for us.
I think we are making progress. Thanks. > However, in the context of making another new stream document, which MAP-bis > as you said, I decline it. Nevertheless, if you abandon 4rd work, I'm very > welcome you as an author of MAP. Well, the idea is only to introduce one more possibility for the choice the WG will have to mùake. The three alternatives become: a. T+E (the current map proposal) b. H alone (the current 4rd proposal) c. T+E+H (whatever its name... MAP-T+E+H, 4rd-T+E+H, anything) With the third combination: - T is still included, thus satisfying some firm requests that justified MAP-T+E - E is still included, thus satisfying some firm requests that justified MAP-T+E - H is available, thus satisfying some firm requests that justified 4rd (ability to combine complete IPv4 transparency with IPv6-ACL compatibility) How to introduce this 3rd choice in WG documents is AFAIK in chairs' hands. Regards, RD > > Best regards, > --satoru > > On 2012/06/23, at 1:52, Rémi Després wrote: > >> Yong, Suresh, Ralph, >> >> For mesh stateless v4/v6, we have so far a choice between only two >> solutions, MAP as is and 4rd. >> On can hope that the consensus that couldn't be reached in Paris will be >> achievable in Vancouver, but this isn't sure, each "camp" keeping its own >> expectation. >> >> Looking at recent history, we can remember that, not long ago, the chair's >> approach was to have 3 specifications completed (MAP-T, MAP-E, and MAP-H, as >> Alain called it with H for Hybrid), and then to choose only one for >> standardization. >> >> After that, promoters of either -T and -E decided to merge -T and -E in a >> non-separable specification, as reflected in draft-ietf-softwire-map-00. >> Thus, the choice has become between a "two-variants" specification (MAP) and >> a "single-variant" specification (4rd). >> >> In this context, a larger choice might well be the best chance for a WG >> consensus. It would include a MAP specification in which the forwarding mode >> of 4rd would be added as 3rd, say a "MAP-bis" . >> With this MAP-bis: >> - vendors have to support 3 forwarding modes, which isn't ideal, but most of >> the design, in particular in what concerns mapping rules, remains common >> (Alain once said, possibly with optimism, the three were 99% identical!) >> - operators have a free choice between T, E, or H, based on their >> operational preferences. >> - we have (at last) a stabilized design with no one badly frustrated. >> >> If this approach makes sense for the WG, I can do the work of editing a >> MAP-bis proposal (taking the current MAP specification, adding a section >> that describes the hybrid forwarding mode, and adding a third variant in the >> address-format section). >> >> My personal preference remains for 4rd as single standard, but a choice >> between MAP-as-is, MAP-bis, and 4rd, is IMHO a sounder choice for the WG >> than just between MAP-as-is and 4rd. >> >> Hoping that this will be found constructive, >> Best regards, >> RD >> >> >> >> >> >> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
