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

Le 2012-03-23 à 10:28, Ole Trøan a écrit :

> Yiu,
> 
>> I have to admit that I am not IPv6 protocol expert. I guess Remi took the fragmentation header and overload it  for his design. Say he defines a new extension called "transition" extension, I would guess it would no longer overload the fragmentation extension. I don't know enough the current implementation of the FIB and how <u,g> in 4rd-u design would impact the implementation. I have homework to do.
> 
> Type 3 Routing Header?
> we've tried this type of tunneling before. ;-)
> 
>> Apart from that, I found MAP and 4rd-u are similar technologies trying to solve the same problem. So far I follow all the discussions in the mailing list about this topics. Technically speaking, they have pros and cons. I fail to see one is absolutely superior than the other. Both designs make trade-offs.  
>> 
>> When we come to WG adoption, I am completely fine if the WG decides one over the other. That said, the current discussion reminds me about OSPF vs IS-IS. They are so similar but yet have subtle differences. Today, both protocols are running in production. Best case scenario is the authors can balance the trade-offs and merge two drafts. If not WG could potentially publish both techs (e.g. one standard track and one informational/experimental) and let the market force to decide.
> 
> the authors did already do that. the dIVI and 4rd authors met 16th of November at the last IETF.
> we collectively went through the complete feature list. the result is what you find in the MAP document series.

 This MAP meeting was immediately after the Taipei Softwire meeting. At this meeting, with an invalid technical argument, you had convinced most participants that -U couldn't work, so that a majority didn't believe the -U approach could be useful. 
 During this MAP meeting, a majority consequently expressed no interest in considering further, for MAP, new features that were part of the -U proposal (Reversible header mapping; Checksum neutrality, AKA CNP; Distinguishable address format, AKA V octet).

 After you had acknowledged on the WG list that, contrary to the technical argument made during the meeting, -U could work, the chair encouraged a separate work on -U. (On nov 29, Alain wrote to me, with copy on the WG ML, "I'd like to encourage you to keep working on 4rd-u and come back next meeting in Paris"). 
 Knowing that a majority expressed during an informal and unscheduled meeting of MAP contributors is in no way a full WG consensus, this was a fair decision.

> Remi, who was also at that meeting, later came up with a different solution and new features and decided to create a competing proposal. MAP is largely original 4rd and dIVI, considering its roots. there has been a continuing exchange of ideas and improvement of the proposals. Remi's latest 4rd-U proposal largely represents all the functions that there was no support for in the MAP design team. I do not think attempting yet another merger will be a good use of our time.
> 
>> P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one complete series.
> 
> yes, that makes sense.
> OK, what if we try this: MAP is a unified solution consisting of two transport modes (T/E), a provisioning (DHCP) and a deployment document.

> then we can pick between MAP and 4rd-U. the winner gets published on standards track. the looser gets documented as informational for the purpose of historical reference.

As already said, if MAP-T and/or MAP-E is standardized, I see no point in confusing people with, in addition, a -U RFC.
The ONLY purpose of -U is having simultaneously -E transparency and -T IPv6 compatibility.
It is NOT to multiply RFCs.

Chers,
RD

> 
> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires