If we can find a way to collapse H and T such that we are back to one "encap/decap" and one "entrans/detrans" version, I think this would be significant progress. 3 options here just seems ridiculous though.
- Mark On Jun 25, 2012, at 8:24, Tetsuya Murakami <[email protected]> wrote: > +1. > > Making another new document might cause more confusion. But if 4rd work is > stopped and merged to MAP, it might be good. But from the implementation > point of view, I would like to eliminate the complicated code as much as > possible such as > > if (MAP-E) > ... > else if (MAP-T) > ... > else if (MAP-H) > ... > > But this is the implementation/deployment choice. So, from the standard > perspective, it might be good to merge H solution to MAP which has already > merged both E and T. > > Thanks, > Tetsuya Murakami > > On 2012/06/23, at 1:52, Satoru Matsushima wrote: > >> Dear Remi, >> >> Thank you for a kind offer. It would be a very positive compromise for us. >> >> 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. >> >> 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 > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
