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

ISP requirement was:(RE: POLL: Consensus for moving forward with Teredo?)



> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of BAUDOT Alain FTRD/DMI/CAE
> Sent: Monday, May 03, 2004 10:26 AM
> To: v6ops@ops.ietf.org
> Subject: RE : POLL: Consensus for moving forward with Teredo?
> 
> c) because I don't understand why just considering teredo and not, at the
> same time, the other mechanisms  according to the WG "selection" process.
> a) in order to move forward. And ISATAP, TSP, DSTM, STEP, etc should
> benefit from that, as well.
> 
> Anyway I've got a couple of concerns with teredo:
> - it deals with a specific adressing plan. I quite agree it could be a
> kind of no start, and phasing out will result in some renumbering

Avoiding renumbering is not a requirement of ANY IPv6 deployment scenario,
including native RA's. So the only reason to raise an objection here is to
stall deployment.

> - it is host oriented and not routeur/network oriented.

And your point is ???  If complaining about teredo is about preventing IPv6
deployment until the ISP is good and ready to offer service, you should look
closely at the IETF's role. The IETF is about standardizing the mechanisms
used, not any specific provider's service offerings. If a provider doesn't
want their customers to use teredo, they can always block the UDP port.

> 
> Teredo is usually identified as a deployment solution without ISPs, and
> obviously does not meet their requirements.

WRONG. It is about getting service when the first-hop service provider is
lame. Many people are in a position where they can not select an alternative
ISP, so they need something that will get them across an ISP that doesn't
understand the term 'service'. As long as ANY service provider is willing to
deploy a teredo service, the end user can start using IPv6 enabled
applications without waiting for their IPv4 provider. 

> So, even if I don't really see
> the deployment model, why not simply deploy the same mechanism, first by
> non-ISPs and later by "real" ones ?

Something appears to have been lost in the translation here. What mechanism
are you talking about? The later end game is native IPv6 service, and the
transition mechanisms are about deploying applications prior to the ISP
providing that. What mechanism is useful in both cases?

Tony


> 
> Alain.
> 
> -----Message d'origine-----
> De : owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] De la part
> de Pekka Savola
> Envoyé : vendredi 30 avril 2004 19:32
> À : v6ops@ops.ietf.org
> Objet : POLL: Consensus for moving forward with Teredo?
> 
> 
> Hi,
> 
> (co-chair hat on)
> 
> As identified in the scenarios analysis at IETF59 and in draft-savola-
> v6ops-tunneling-01.txt, there appears to a need which cannot be filled by
> another mechanism for Teredo at least in one major Unmanaged scenario.
> 
> Is there rough consensus to move forward with Teredo? (i.e., to adopt it
> as WG document in this WG or elsewhere, for Proposed Standard.)
> 
> The main issue raised has been to call for a more extensive analysis for
> the deployment implications of native, 6to4, and Teredo.  There is already
> discussion of this in the Unmanaged Analysis document.  There seemed to be
> very little energy or interest in the WG to drive this much further.
> 
> The options regarrding Teredo at this stage seem to be:
> 
>  a) Go forward with Teredo, hone the deployment implications in the
>     unmanaged analysis in parallel (if and as appropriate),
> 
>  b) Conclude that there is no sufficiently strong need for Teredo, and
>     not support its advancement (for PS) at this stage, or
> 
>  c) Decide that we need to analyze the scenarios or deployment more
>     before being able to make a decision.
> 
>     If so, please state where you believe more analysis is needed..
>     and volunteer if possible :)
> 
> If you have an opinion, please state it within a week, i.e., by next
> Friday, 7th May.
> 
> Thanks!
> 
> (co-chair hat off)
> 
>