Re: [Softwires] Path to move forward with 4rd…

[Rémi Després <[e-mail]>]

Le 2012-03-25 à 05:34, Maoke a écrit :

> dear Remi,
> 2012/3/24 Rémi Després <[e-mail]>
> 
> Le 2012-03-22 à 15:40, Maoke a écrit :
> 
>> dear Alain, Yong, Ralph and all,
>> 
>> in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions  a little confused me: if we need to go back to the stage before the works of the MAP design team?  
>> 
>> The MAP series have reached running codes
> 
>> and the collective understanding of the community.
> 
> Here are some issues among those remaining before reaching "collective understanding":
>  
>  
> some issues remaining not yet reaching collective undertanding is not a reason of making things over. the collective understanding has been reached for the major part of the
> 1) MAP address format and the corresponding algorithms
> 2) encapsulation and translation modes being supported by MAP format and the existing header processing standards 
> 3) DHCP extensions as a way of distributing rules.
>  
> the above big picture are what i call "collective understanding". the correct way is: making these already gained approaches as bases, continuing discussion or even dabate on the details. i don't think it is a correct way of action to disrespect a team's work. 4rd-u's problem is even its big picture is still fuzzy.

Not more fuzzy than MAP (actually less fuzzy IMHO).
Debate on details is possible for U as wall as for T+E.

> a) T operation in hub&spoke (hasn't been so far answered in an understandable way).
>  
> i doubt i understand what you mean. may you please specify the question in details?

Is a DHCPv6 parameter needed, yes or no?


> b) IDs from shared-address CEs.  T currently has so far no solution while both U and E include one. 
>  
>  
> what do you mean with the IDs? or do you mean interface IDs? i don't see "IDs from shared-address CEs" in U too. please teach!

Sec 4.5.3. is "Packet Identifications from Shared-Address CEs".
Did you read the complete draft?


> c) MAP-A+P says "Each MAP node in the domain has the same set of rules" while MAP-T says "if a CE knows only a subset of the mapping rules ..."  
>  
>  
> first of all, they are not conflicting logically.

???

> second, if you mean one doc is superior than multiple with better consistency in writing, i could agree.

This is not the point.
Separate documents can be consistent, but they aren't on this point.

One of the two assertions must be changed. 
Remaining question: which one?

> but it doesn't mean one doc is definitely reflecting "collective understanding" better than multiple.
>  
>  
> d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp.
>  
>  
> single mapping rule for a domain != single mapping rule for the IPv4 world.

???

> the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and BMR being exclusive is a problem.

How many MAP mapping rules do you see for the equivalent of the IVI use case in a MAP domain? 
None? 
If one, is it a DMR or a BMR?
If two, what are they?


> The fact that no-one involved in the MAP design raised any of these issues is AFAIK sign that MAP has NOT reached "collective understanding of the community".
> (Note that, concerning stateless v4/v6 solutions, I think I should be considered part of this community. Right? ).
>  
>  
> well, "collective understanding" was mentioned by Sally Floyd to the community of Internet researchers, and i borrowed her term. but i understand: no matter it is research or engineering, collective understanding is the understanding on the problems and the architecture rather than the detailed technical solutions. the MAP architecture has been reflected in the works of the draft suite. on the other hand, the community is not the softwires wg but the whole Internet engineering circle.
>  
>  
> 
> Maoke, clarifications on these points will be welcome.
> 
> 
>> From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. 
>> 
>> in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment.
> 
> Note: This excludes ISPs that would like to offer full IPv4 transparency with some IPv6-only middles boxes.
> Right?
>  
>  
> i cannot follow your "full IPv4 transparency" with "some" IPv6-only middle boxes. what does the "transparency" mean for the middle boxes? i understand, when we talk about the Internet transparency, we refer to the "end-to-end transparency". please specify your question concretely.

OK, could have been clearer.
Yet, I think you understand that with U, one has SIMULTANEOUSLY, transparency to DF=MF=1 and applicability of IPv6-only middle boxes that look at TCP ports.


>> The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community. 
>> 
>> second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing the tunneling and translation, if accepted as standard, may trap the operators into a harsh situation of being unable to define what building block it really is.
> 
> Such an operator would know it uses 4rd-U. 
>  
>  
> well, this is what i mean the uncertainty of 4rd-U in the architecture to the common understanding. as a analogy, one of Mr. E and Mr. T said, "i give you a horse", while the other said "i give you a donkey". then people well understand when they need a horse when they need a donkey. now Mr. U said "wow, i give you a fantastic donkorse!". there would be 2 possible results, not certain right now:
> A. donkorse is just another sort of donkey, somehow good but somehow flawed.
> B. donkorse is just donkorse, and people, taking a long time to understand it, and finally find it either a flawed or a quite good hybrid, like mule, useful in some cases.
>  
> no matter if the future result is A or B, now Mr. O understand what he needs for his business is either a horse and a donkey, with their well-known characteristics. Mr. MAP provides a wheeled car as the common instrument, while Mr. O needs a standard suite for the wheeled-car, the horse-driving and donkey-driving methods and the way of feeding the horse and donkey. this is the task of our wg, right now.  
>  
> Mr. U said you must have another type of wheel and drive it with my donkorse --- and when Mr. O asked him, what your donkorse is, he answered: you will know it is donkorse, having both the advantages of the horse and the advantages of the donkey. however, Mr. O doubts donkorse hasn't also the disadvantages of horse and the disadvantages of donkey and some flaws not yet documented. why not?
>  
>  
> This doesn't seem to justify any FUD from co-authors from broadband and mobile operators (or from product vendors).
> 
>> It is stated as tunneling but actually behaves like tunnel in some aspects while like translation in some other aspects.
> 
> Yes indeed, thus achieving the best of both worlds without making it more complex. Actually making it clearly less complex than supporting both T and E.
>  
>  
> i don't think those who made out mule expected the mule could replace horse and donkey and achieving a better world without horse and donkey but only mule. surely mule-only world is simpler.

Comparison is not reason (French proverb).

>  
>> (I have pointed out in the 4rd-u discussion thread).
> 
>> We see it only a yet-another-translation that try to solve some corner problems but introduces new, possibly major flaws (also pointed out in the technical threads on 4rd.)
> 
> "Possibly major flaws" isn't an identified point on which U would do less than what it has been designed to do (unified replacement of T + E).
>  
>  
> i believe they are major flaws but i was gently argued with the "possibly" because i respected that maybe others didn't think so critically like me.

I have still to understand where you see "major flaws".
Just asserting they exist, without explanation although others who read the specification don't see them isn't enough.
Saying that E+T is better because its current inconsistencies are "details" isn't enough either (IMHO).

> IMPORTANT:  
> - The essential characterization of U (vs T and E) is its Reversible header mapping (as replacement of both Double RFC6145 translation and Encapsulation).
>  
>  
> yet-another-translation, with some issues still in debates.

You can call it as you wish, but the point remains that, with U, one doesn't need both E and T.


> - Other features of U that differ from MAP (V-octet, CNP), or are complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this respect. Each of these features could be abandoned in U, or, if the WG appreciates what they offer, added to MAP.
>  
>  
> MAP team has concluded V-octet and CNP are not necessary. do we need to debate again? i doubt people have unlimited time.

I made the point many times that the right to analyze problems didn't stop after a majority decision obtained during an improvised meeting.
Many MAP contributors were absents, and no time was given to correct invalid objections that had been made just before during a WG meeting.

Note that several co-authors of the U proposal have been MAP contributors.  


> - For this, community acceptance to listen to explanations, would be the normal process. I will be available this week for this.
>  
>  
> i think we are all open to listen to and to discuss on any explorations but it doesn't mean we should stop standardization of our wheeled-car/horse-driving/donkey-driving/feeding suite with an expectation of a "better world" with only donkorse and the donkorse-specific wheeled car.

Your stand is clear, but comparison isn't reason.

RD




> regards,
> maoke
>  
>  
> 
> Cheers,
> RD
> 
> 
>> In either the term of architectural philosophy or technical details, introducing 4rd-u into standards would be harmful. 
>> 
>> personally, i respect the exploration of the author(s), and the discussion between me and the author encouraged me to comprehensively review E and T, and the result is: i bacame much more confident of the correctness of the MAP track. We should move forward. 
>> 
>> regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be put into standard track. Question is not about T, E or U. 
>> 
>> best regards,
>> Maoke
>> 
>> 在 2012年3月20日星期二，Alain Durand 写道：
>> Dear wg,
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>>  Alain & Yong, wg co-chairs.
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
> 
>