On 3/26/12 8:54 PM, "Satoru Matsushima" <satoru.matsush...@gmail.com> wrote:
>As a member of the MAT DT, I am naturally biased in favor of what Xing, >Maoke and Ole said. > >I also think that the chair's questions are not adequate. I don't think >that the questions should be which of document the wg choose, make >documents to be unified or not. I think that it should be what 'solution >space' has been clarified beyond the MAP suite. Let me try to figure >these out. > >1. Reduce the number of parameters for MAP configuration > The MAP currently needs bunch of parameters such as 'Rule IPv6 prefix', >'Rule IPv4 prefix' and 'EA-bits length' for each of BMR, FMR and DMR. It >would be more convenient when one or some of them can be reduced or >omitted. [Reinaldo] Good point. Irrespective of MAP/4rd-U it would be good to have a simplified model for ease of deployment. Usually when implementing such standards things get very complicated for both development and ISP due to - Consistency checks across all parameters - Consistency checks within a parameter - Debugging, operational commands, testing, - Interop testing, naming conventions - Network planning and staff training. Thanks, Reinaldo > >2. Trying to keep more header transparency > When operators think that it would be nice if the MAP-T can keep header >transparency, which includes checksum neutrality, beyond the current >header translation specification, the wg should be work on that, or ask >other wg to do that. > >3. Truly 'Unified' operation > Since encapsulation and translation are completely separated operation >in operator's network (I mean 'polarized' on Jan's comment) but the >implementation of both is possible into one box. Beyond just 'unified >document', does operators think it would be more attractive with >'unified' operation for which both encapsulation and translation co-exist >in same time, on same network, for same service. > >Above three are my thought of what 4rd-u proposed to the wg. Discussions >and more suggestions are welcome. > >Best regards, >--satoru > > > >On 2012/03/23, at 10:46, Ole Trøan wrote: > >> Alain, et al, >> >> we have been at an impasse, so thank you very much for proposing a path >>forward. >> >>> After a number of discussions with my co-chair, our AD and various >>>authors, here is how we would like to move forward wrt 4rd. >>> 1) There is an observation that all the solutions on the table E, T & >>>U actually solve the stateless problem we started with. >>> There are differences, but it is unclear if those differences are >>>really significant. E and T are the original Encapsulation and >>>Translation >>> proposals, U is an hybrid unifying solution. >> >> I do agree with that. the Venn diagram for the three solutions would >>look awfully similar to a single circle. ;-) >> there are some use cases though, that can only be fulfilled with one >>mode of transport versus the other. >> I left the interim meeting in Beijing having been convinced that there >>are use cases requiring both encapsulation and requiring translation. if >>we for a moment accept that, I would suggest that we treat MAP as one >>single solution. it will have two options/flavours of transport. >> >>> 2) We have already agreed back in Beijing that we would publish all >>>necessary documents. The issue here is the 'label' or 'status' those >>> documents have at IETF. In particular, do we want to publish them as >>>Experimental, Informational or Standard Track. >>> >>> We are at the point now where we need to make progress. In Paris, we >>>would like to ask for presentations from the proponents of each >>>candidate solution (E, T & U). >>> Each presentation should cover an overview of the proposed solution, >>>explain how it compares to the others and make a case as why it should >>>be the one on the Standard Track. We will allocate 20 minutes for each >>>presentation. >>> Then, we, chairs, would like to ask a series of questions to the >>>working group. In order to make this process transparent, here is the >>>list of questions we want to ask >>> and their sequence. >>> >>> Q1: Without pre-supposing which one will be selected, do you agree to >>>publish 1 of the 3 proposals on the Standard Track and publish the >>>other(s) as Informational if still asked to? >>> >>> If the answer is NO, then the process stops and we will publish >>>everything as Experimental and come back in 12-24 months to see what >>>gets adopted by the market. >>> If the answer is YES, we move to the next question. >>> >>> >>> Q2: Do you believe that the WG should publish U as the one Standards >>>Track document? >>> >>> If the answer is YES, the process stop, we put U on the Standard Track >>>and publish E & T as Informational. >>> If the answer is NO, we are left with E & T (U then might be abandoned >>>or published as Historical/Informational) >>> >>> >>> Q3: Which of E and T do you want to see moving on the standard track >>>(you can only express support for one)? >>> >>> If there is a clear outcome from this question, we would publish that >>>proposal on the Standard Track and the other one as Informational. >>> If there is no clear consensus on this question, we will publish both >>>E & T as Experimental. >> >> with the above proposal, we can drop question 3. >> >>> In the meantime, we would like to encourage discussion on the mailing >>>list to foster our common understanding of the various technologies and >>>how they relate to each other. >> >> can ask the chairs to take a hum of how many would want t-shirts for >>the meeting with: "Just pick one for F's sake and stop arguing". ;-) >> >> cheers, >> Ole >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
