Re: Tunneling and Transition Drafts

[JORDI PALET MARTINEZ <jordi.palet@consulintel.es>]

Hi Alain,

I see the pattern ... But I don't think we actually tried to look into a
single solution, and that may be why we haven't moved forward.

By the way, I don't agree that the approach on a single solution for wired
and wireless isn't the best approach. The point is that it may be or not,
depending on the actual solution ;-)

Regards,
Jordi




> De: Alain Durand <alain@tycool.net>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Thu, 7 Apr 2005 17:08:08 -0700
> Para: Fred Baker <fred@cisco.com>
> CC: Lindqvist Erik Kurt <kurtis@kurtis.pp.se>, David Kessens
> <david.kessens@nokia.com>, "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: Tunneling and Transition Drafts
> 
> 
> On Apr 5, 2005, at 4:34 PM, Fred Baker wrote:
>> 
>> In taking over the working group, Kurt and I basically were presented
>> with the following scenario:
>>  - this group is for operational questions (not protocols)
>>  - this group seeks to conform to RFC 1958 (we are not here to bless
>> very lame solution that comes along)
>>  - transition mechanisms are generally out of scope.
>> 
>> As I understand it, v6tc (which was intended to take over all the
>> tunneling stuff, which is to say a large proposition of the transition
>> stuff) is dead in the water. The expectation was that all the
>> tunneling/transition stuff would move there, but the BOF was a
>> non-event. There isn't likely to be a v6tc WG. (Dear AD: if you
>> disagree, this would be a good time to say so).
> 
> Is TC going to be chartered or not, I do not know yet, we are still
> talking about that.
> That said, as Pekka mentioned, TC was never meant to pick up all the
> left-overs
> from the NGtrans days that were not adopted by v6Ops, it was meant to
> be a very
> focused wg.
> 
> I'll send later the minutes of the meeting, but what I got (and all the
> people I talk to after
> shared the same feeling) is that:
> - We are very late in the game, folks have started to deploy their own
> ad-hoc solutions,
>    if we do anything, time to market will be critical
> - What is being deployed is either not documented or not standardized
> (i.e. not been through
>    community review)
> - The focus on latency was to try to get a common solution that will
> fit the wired and wireless case,
>     it seems that this may not be the best approach.
> 
> 
>> Which brings me to my question. I am being asked by various proponents
>> of various things what the working group wants to do with their
>> approach. I need to know what the game plan for this working group is:
>> let a thousand flowers bloom (they can all ask for informational
>> status from the RFC Editor and the probability that the transition
>> will happen in an orderly fashion rapidly approaches zero), or I need
>> a consensus statement from the working group that every single
>> approach on the table will be set aside and the working group will
>> actively work on providing a single solution that meets all those
>> needs that the IETF can look at and say "yes, that will accomplish an
>> orderly transition in a timely fashion and
>> *I*will*support*that*in*favor*of*all*others".
> 
> let's get into the time machine...
> 
> Spring 1999. Grenoble IPng & NGtrans interim meeting.
> Topic: we have too many transition mechanisms, can we converge on one
> and only one?
> 
> Summer 2002. Yokohama IETF.
> Topic: too many transition mechanisms, shut down NGtrans and focus on
> scenarios in v6ops
> 
> Spring 2005. now.
> Topic: too many transition mechanisms, can we converge on one and only
> one?
> 
> See a pattern here?
> 
> - Alain.
> 
> 




************************************
Barcelona 2005 Global IPv6 Summit
Registration open. Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.