[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enterprise Analysis DSTM Issue



On Tue, Aug 09, 2005 at 01:50:18PM -0700, Fred Baker wrote:
> 
> c) I said that a working group draft needs to reflect working group  
> input, and that if this could not be accomplished then maybe the  
> document should not be a working group document.  That is not a  
> position I plan to apologize for; it is also related to the reason  
> that v6ops doesn't work on transition strategies - the various  
> transition discussions in v6ops did not lead to convergence on a  
> single or small number of recommended strategies.

And here's the funny thing, or it is if I understood Paris correctly.  
At IETF 62, the v6tc BoF showed one way forward for nailing down tunnelling
solutions (which could include DSTM).  Sadly due to blockage somewhere in 
the IETF upper reaches the WG never formed.  At Paris, a non-advertised BoF
on tunneling, called 'lrw' (!?) was held with near-identical goals to v6tc.
And now we hear that lrw (hopefully with a better name) will be formed, and
as an Internet area WG will be able to do protocol work.   Provided the
work is based on existing drafts.  This is good.

So after all the stalling since ngtrans closed up, we now have a WG that
*could* publish DSTM, or something very like it, potentially, since it covers
4 in 6 and 6 in 4 in its charter (and oddly inter-network tunnelling).

Anyway, one could see tunneling protocols emerging soon from lrw.

> Pekka's observation is that while this is mostly transparent to the  
> end system, it is hardly transparent in the network and (being  
> experimental) is not something the IETF is at this time recommending.  

But lrw has something not too different as its goal?

<devil's advocate>
What does the IETF recommend for dual-stack nodes in an IPv6 infrastructure?
</devil's advocate>

> So, I have two expectations of a working group document: that it  
> reflect the opinions of the working group, and that it reflect the  
> recommendations of the IETF. As you and I discussed in July, the  
> statement
> 
>      Later in the transition process, after the enterprise has
>      transitioned to a predominately IPv6 infrastructure, the architect
>      should implement the Dual-IP Transition Mechanism [DSTM, DSTM+].
> 
> fails the latter point, and from the sound of Pekka's comment, fails  
> the former point as well.

Something 'like it' is likely to be needed though?   e.g.

      transitioned to a predominately IPv6 infrastructure, the architect
      is likely to need to deploy IPv4-in-IPv6 tunnelling solutions, such
      as the Dual-IP Transition Mechanism [DSTM, DSTM+].
?

But again, what would the IETF's recommended tool be here?

Tim