RE: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt

John C Klensin <john-ietf@jck.com> Wed, 04 July 2007 18:27 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I69ZG-0007GL-Gr; Wed, 04 Jul 2007 14:27:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I69ZF-0007GG-PX for ietf@ietf.org; Wed, 04 Jul 2007 14:27:09 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I69ZB-0002Jx-1v for ietf@ietf.org; Wed, 04 Jul 2007 14:27:09 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1I69ZA-000HUA-3I; Wed, 04 Jul 2007 14:27:04 -0400
Date: Wed, 04 Jul 2007 14:27:02 -0400
From: John C Klensin <john-ietf@jck.com>
To: michael.dillon@bt.com, ietf@ietf.org
Message-ID: <CB895C734B43E64374D35AE8@p3.JCK.COM>
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B09F9807@E03MVC4-UKBR.domain1.systemhost.net>
References: <20070703145113.68830872D9@mercury.lcs.mit.edu> <D03E4899F2FB3D4C8464E8C76B3B68B09F956B@E03MVC4-UKBR.domain1.systemhost.net> <C78BA64D615CE76F09912786@p3.JCK.COM> <D03E4899F2FB3D4C8464E8C76B3B68B09F9807@E03MVC4-UKBR.domain1.systemhost.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Cc:
Subject: RE: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org


--On Wednesday, 04 July, 2007 15:52 +0100 michael.dillon@bt.com
wrote:

>> > That MPLS with 6PE is a superior migration scenario.
>> 
>> > Or perhaps, that defining migration scenarios without the
>> > full   involvement of network operations people is an
>> > exercise in  futility.
> 
>> If the lesson we have learned is that the only practical way 
>> to handle and route IP (whether v4, v6, or otherwise) 
>> requires the use of an underlying virtual circuit layer, then 
>> much of what we are doing in the IETF involves an 
>> architectural delusion about the fundamental datagram and 
>> packet model of the Internet. 
> 
> All that the IETF can do is to put the technology on the
> table. It is up to network operators, public and private (and
> very private) to try it out, test the limits, point out bugs
> to be fixed, and ultimately accept or reject it.

Of course.

> Over the past
> 8 or 9 years, this is just what many operators have been doing
> with MPLS and the verdict is that MPLS works very well indeed.

Intra-network.  Unless there have been major changes while I
wasn't looking (which is quite possible), MPLS is still a little
marginal for inter-provider (inter-carrier?) traffic absent some
rather serious integration of the network and network
conventions.  Put differently, MPLS is not [yet?] an end-to-end
solution across arbitrary peer or customer networks.

> Unfortunately, we have been a bit shortsighted in not
> realizing that we cannot live with only MPLS and IPv4 because
> we will run out of new IPv4 addresses by 2010.

Concur about the "shortsighted" part.  I've said (in other
forums) about all I want to say about forecasts of "run out"
dates and the associated assumptions and definitions... at least
in the absence of strong drink.

> But, given that MPLS works and works very well, it seems to me
> that a viable migration scenario is NOT to throw away MPLS and
> attempt to make pure IPv6 work right away, but to start with
> 6PE at the edge where most growth occurs (in terms of
> connections) and where we can run a viable business selling
> IPv6 services to financially support migration activities.

I'm ultimately a pragmatist about this and believe that anything
that gets us to IPv6 without locking us into innovation-limiting
technologies is a good thing.  So I think we agree about the
above.

> Yes, if a network does not use MPLS at all today, it may well
> be wiser for them to move to dual-stack throughout.

That was part of my point.   Another part was that at least some
of the networks that have chosen to run MPLS internally have
done so because its model felt more comfortable to people who
were used to thinking about circuits (virtual or physical) than
they were about packet models.  Independent of how well it
works, that is not necessarily a good basis on which to make
decisions, so I'm a little hesitant about "identifying
stakeholders" and adjusting to their needs: if one starts that
way, one may easily create a bias toward incumbent operators and
their favored technology.  Especially with a disruptive
technology like datagram-based networks, it seems possible to me
that is not the right thing to do.

> But where
> MPLS is in place, it seems to me wiser to leverage it for now,
> limit the impact of IPv6 on the network, and climb the
> learning curve. Along the way, we may well gain confidence
> that MPLS is not needed because a pure IPv6 network can do
> everything that is needed. I suspect that if we get to that
> point, it will only be through some additional IETF work to
> cover gaps that MPLS covers adequately today.
> 
> It is not unusual for movement forward to happen, two steps
> backward, three steps forward.

Again, I think we agree.  

>> Maybe we are all deluded and that, as has occasionally been 
>> claimed by some telco-based bodies, datagram networks are 
>> only useful for research and the future, as well as the past,
>> of "real" networks lies in end-to-end circuits.   But I'm not
>> convinced yet.
> 
> John, we are more in agreement than disagreement. But you must
> realize that a business has to protect its customers and that
> often means keeping old technology running longer than leading
> edge developers would like. But eventually, the risk of
> hanging on to old ways rises and people find a way to upgrade
> themselves and leverage that upgrade for financial gain. MPLS
> technology happens to be in its prime right now, so that
> rising risk is many years down the road. We will run out of
> IPv4 addresses before MPLS runs out of steam. 
>...
  
> It seems to me that recommending MPLS with 6PE as a migration
> strategy to IPv6 does not rule out pure IPv6 networks sometime
> in the future.

Our analysis may be different, but our conclusions are fairly
similar, which is certainly consistent with your "more in
agreement..." comment above.   I am concerned about only two
things in this regard.  First, I'd hate to see us tell anyone
who is not running MPLS that going to MPLS is the best way to
transition to IPv6 (there may or may not be perfectly good
reasons for going to MPLS, but IPv4->IPv6 should not be it).
Second and as a near corollary, I'm a bit concerned that the
thinking of some of us has gotten a bit sloppy because of an
unspoken assumption that there will always be an underlying MPLS
(or equivalent) fabric underneath IP in WAN environments and
that such an assumption is causing us to be more relaxed about
IPv6 routing, etc., work than we should be.  If the work gets
done and IPv6, or datagram models generally, prove inadequate to
a global network, then so be it.  But I'd prefer to not lose
that model either by default or to the thinking habits of
traditional carriers.

    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf