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

From: [email-masked] (Noel Chiappa)
Date: Tue, 3 Jul 2007 10:51:13 -0400 (EDT)

> From: Mark Andrews <[email-masked]>

    > This is the time when everyone should be running dual stack.

So, what lesson(s) ought the IETF to take away from the fact that people
aren't?

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Jul 2007 12:34:34 -0400

> So, what lesson(s) ought the IETF to take away from the fact that people
people will nearly always choose a quick fix that adds complexity over a
fix that has better long-term viability but is more disruptive. 
especially if the latter requires them to change how they think.  few
people are flexible enough to change how they think.  the only way
people in general change is to be replaced by younger people.

the problem is exacerbated because the more people invest in complexity,
the harder it is to replace whatever marginal functionality is provided
by that extra complexity.  IPv6 was designed in a day where IPv4
security problems were still minimal.  meanwhile, IPv4 enterprise
networks have acquired all manner of security baggage.  those products
just  barely exist for IPv6, if at all, and they're not proven yet.  
even enterprises that want to adopt IPv6 because they understand its
advantages find it somewhat difficult.

---

From: <[email-masked]>
Date: Wed, 4 Jul 2007 11:50:43 +0100

> So, what lesson(s) ought the IETF to take away from the fact 
> that people aren't?

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. In
the business world this kind of work begins by identifying stakeholders,
getting full involvement from stakeholders, and only then doing design
and planning.

--Michael Dillon

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jul 2007 13:22:23 +0200

> involvement of network operations people is an exercise in futility. 

It would have been, if v6ops had done that.

    Brian

---

From: Joe Baptista <[email-masked]>
Date: Wed, 04 Jul 2007 09:58:56 -0400

>getting full involvement from stakeholders, and only then doing design

Thing have changed.

regards
joe baptista

-- 
Joe Baptista                                www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive,
Representative & Accountable to the Internet community @large.
----------------------------------------------------------------
  Office: +1 (202) 517-1593
     Fax: +1 (509) 479-0084

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jul 2007 10:04:35 -0400

>...

Michael,

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.  Some
applications work is insensitive to that delusion, others are
not, but, if the circuit underlayer is really necessary, then
much of TCP/IP represents unneeded complexity and we should be
working to dispense with it.

Despite the views of some "network operations people" (many, but
perhaps not all of them with their feet stuck in legacy telco
thinking), many of us still believe that datagram networks have
significant value for more than multiplexing circuits.  To us --
including people who have been involved in network operations --
it may make sense to optimize parts of networks with a single
policy environment by the use of underlying circuit
technologies.  But, like classic CSMA/CD Ethernet, they are
technologies that may be entirely appropriate in a restricted
network environment but not for a global Internet, even if the
global Internet interconnects several networks using such
technology.

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

---

From: Joe Baptista <[email-masked]>
Date: Wed, 04 Jul 2007 10:39:05 -0400

>"real" networks lies in end-to-end circuits.   But I'm not
I don't think the full poitential of the datagram network has yet been 
realized.  User control anyone?

regards
joe baptista

---

From: <[email-masked]>
Date: Wed, 4 Jul 2007 15:52:45 +0100

> 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. 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. 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.

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.

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

> claimed by some telco-based bodies, datagram networks are 
> only useful for research and the future, as well as the past, of

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. 

As a result, many network operators must plan for running both MPLS and
IPv6 services. Eventually, IPv4 services that require MPLS features may
be converted to IPv6 services that can run without MPLS. Just getting
rid of overlapping RFC 1918 ranges helps a lot here. 

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.

--Michael Dillon

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jul 2007 14:27:02 -0400

--On Wednesday, 04 July, 2007 15:52 +0100 [email-masked]
wrote:

>> > Or perhaps, that defining migration scenarios without the
>> > full   involvement of network operations people is an
>> > exercise in  futility.
> 
> 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.  

>> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jul 2007 08:47:35 +0200

Micahel,

> business selling IPv6 services to financially support migration

I don't understand the tone of complaint in the above. The IETF *has*
put 6PE on the table: RFC 4798 is a Proposed Standard. That's where
the IETF's role ends - this is one of the mechanisms for IPv6
coexistence, among which the market can choose.

       Brian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 5 Jul 2007 11:56:13 -0700

> From: Brian E Carpenter [mailto:[email-masked]] 

> I don't understand the tone of complaint in the above. The 
> IETF *has* put 6PE on the table: RFC 4798 is a Proposed 
> Standard. That's where the IETF's role ends - this is one of 
> the mechanisms for IPv6 coexistence, among which the market 
> can choose.

If we want to see deployment then maybe the IETF role should not end there. Or maybe the IETF should take a more active role in the handover process to those we hope to deploy.

There is a big difference between a change to a specification like S/MIME or HTTP where all we need to do is to get the software providers round the table to effect a change and an infrastructure standard.

I would like to see some more formal interaction between the principal standards bodies: IETF, W3C, OASIS and the industry groups that can help effect a change. The only group where there seems to be much crossover at the moment is to NANOG. We can get a heck of a lot more leverage by talking to groups like Jericho Forum, MAAWG, FSTC, APWG, etc.

And the dialog needs to be bidirectional. There are several IETF projects that have gone on for a long time, in one case a decade which appear to me to be profoundly misguided from a deployment and architectural point of view. That does not worry me much if they are spending their time, but when they propose their scheme as a platform others can build on, and MUST build on because its IETF, well there I see a problem.

Before sending NAT to historic I would like to see BEEP taken to the woodshed. It was a misguided attempt at 'me too' that never built up the necessary base of support. We should recognize that SOAP won that battle and move on.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf