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

["Tony Hain" <alh-ietf@tndh.net>]

> -----Original Message-----
> From: BAUDOT Alain FTRD/DMI/CAE [mailto:alain.baudot@francetelecom.com]
> Sent: Tuesday, May 04, 2004 6:44 AM
> To: Tony Hain; v6ops@ops.ietf.org
> Subject: RE : 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.
> >
> There is no intend to stale anything here. The point is just about spefic
> addressing, as already discussed in another thread.

Nobody pays attention to addressing except routers and the geeks who run
them. Moving from 2003:: to 2001:: is no more of a problem than moving from
2001:abcd:: to 2001:fedc:: (ie: switching providers). If the first hop
provider stalls their deployment too long there is a chance the end customer
will embed 2003:: addresses in places they shouldn't, but rapid deployment
of native service will avoid that.

> 
> > > - 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.
> >
> I mean that other mechanisms enabling a network or a router to get
> IPv6 connectivity and adresses should move forward, as well. The idea
> is to standardize as soon as possible tools enabling ISP to be good
> and ready and not the opposite.

We did that first as dual-stack routing, and found the ISPs are standing
around waiting for IPv6 traffic before they deploy it. The end customers
can't deploy IPv6 apps to generate that traffic without some of the
additional tools. At the same time, we should not be stalling tools that an
ISP might want to use.

> > >
> > > 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.
> >
> This is the way I understood "without ISP support" that is connected
> to unman 1.1 scenario, and  not to unman 1.2 and unman 2 scenarios.
> Distinction between service provider, IP provider and ISP maybe
> confusing anyway.
> > > 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?
> >
> I guess TB+TSP may apply in both cases (deploying applications and
> providing IPv6 connectivity and service) and it may be aesier to move
> from one another when provided by different roles. Indeed this is
> not a MUST.

What??? Do you really think people would put in the number of static routes
necessary to move assignments from a TB to the appropriate PE router?
Unless you are talking about the massive expense of putting in an array of
TB's at each edge, then wholesale replacing them in a simultaneous move of
all customers as native service is turned up on an edge, you will end up
with a routing nightmare, or readdressing the customers as they are moved
individually. TB is a fine tool for what it does. Just don't promote it to
the magic bullet that solves all problems, because it doesn't. 

Popping up a level:
Again, we have a minimum set of tools on the table. There are some overlaps
between them, but no complete duplication of functions. All belong on the
standards track because implementations will be expected to interoperate. It
is not the IETF's job to dictate what the market can have, just to provide
standards so that an interoperable set of tools can be offered. It is the
marketplace that will decide which of the tools have value, and in which
scenarios. At this point, all the arguing about which tool is better than
another is simply stalling the availability of all of them. 

We needed to be able to explain to the IESG why we needed more than one
transition tool, and the scenarios documents set the stage for that. Now we
need to show how each tool applies, and why there is not a complete
duplication of function between any of them. At the same time, there are
concerns that the tools still need some polish before they are ready, so
that should be happening as a standardization effort. All the noise about
'Experimental' needs to stop, because that is fundamentally a political move
to push one tool down in favor of another. It is not the IETF's job to make
the determination of market favorite. If we are really unsure about an
approach then Experimental makes sense, otherwise the technology needs to be
PS. If the market accepts it we will have deployment reports so it can move
forward. If the market does not, it will not matter what status it has. 

Tony


> 
> I hope this comes a bit clearer. Thanks for your comments.
> 
> Alain.
> 
> > 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)
> > >
> > >
> >
> >
> >
> >