[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ocean: do not boil
yes why artificially limit the working set?
/jim
> -----Original Message-----
> From: Tony Hain [mailto:alh-ietf@tndh.net]
> Sent: Monday, September 23, 2002 9:17 PM
> To: 'Margaret Wasserman'
> Cc: 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun Hagino';
> v6ops@ops.ietf.org
> Subject: RE: ocean: do not boil
>
>
> Margaret Wasserman wrote:
> > Hi Tony,
> >
> > >The most obvious case at the moment is the substantial
> deployment of
> > >IPv4-only NAT CPE that for financial reasons *will not be
> upgraded*
> > >until the ISP is ready to provide native IPv6 support (in
> > North America
> > >that is looking like ~2006, or in the case of docsis devices much
> > >later). For those end sites that want to move sooner, and
> > don't have a
> > >reasonable option for an alternate ISP, just saying we
> only support
> > >dual stack is telling them they can't use IPv6 capable apps &
> > >appliances for at least 5 years.
> >
> > I'm not sure how this follows from Randy's comments...
>
> >> if i want my web site seen by both v4 and v6 users, then i can
> connect
> >> it to v4 and v6 space and run dual stack. in fact, i do
> so today.
> >> as v6 deploys, folk every useful site will do so.
>
> Asserts that if a content site wants to be seen as IPv6 that it is in
> control and can just advertise that and all IPv6-only nodes
> will be able
> to reach it. The reality is that a consumer behind an
> IPv4-only NAT CPE
> will need some form of IPv6-over-foo to get past the CPE. The
> hidden and
> invalid assumption in Randy's comment is that the IPv6 network is
> contiguous.
>
>
> >
> > If a node in the end site wants to access an IPv6-only
> > service, the user would need to install IPv6 on that node (or
> > buy a new appliance with IPv6 included, etc.). If the IPv6
> > infrastructure isn't present to route IPv6 natively, then
> > they might use one of our several tunneling mechanisms to
> > tunnel the packet over the IPv4 infrastructure to an IPv6 network.
>
> This is specifically what Randy's note was asserting, that we
> don't need
> the complexity that the mechanisms bring to the table.
>
> >
> > >Also, as a meta point, declaring an approach for transition out of
> > >scope before the scenario documents are done is just a bit short
> > >sighted.
> >
> > I actually think that we were discussing some prioritization
> > of the scenarios, not declaring any of the solutions in or
> > out of scope.
>
> >> trying to make pure v4 sites/hosts communicate for
> arbitrary services
> with pure
> >> v6 sites/hosts and vice verse is a nice way to make the problem
> vastly more
> >> complicated, the solutions vastly more complex, and the
> net much less
> reliable.
> >> let's not go there.
>
> Sounds like precluding a class of transition scenarios to me.
>
> >
> > Once we have a full set of scenarios, I think it will make
> > sense to try to trim down the set of scenarios, based on what
> > we think is most likely to occur.
> >
>
> This is absolutely silly. The whole exercise is designed to refocus on
> the scenarios that are actively being deployed, or currently on the
> drawing board for deployment. Claiming that we can out guess
> the market
> acceptance of those and whittle that down further presumes access to a
> crystal ball I haven't seen yet. Prioritizing based on relative broad
> applicability would make sense if there were limited resources, but we
> seem to have plenty of interested participants. Developing them in
> parallel doesn't appear to be a problem, so why artificially restrict
> the working set?
>
> Tony
>
>
> > Margaret
> >
> >
>
>
>