Subject: [RRG] On deployability

From: Tony Li <[email-masked]>
Date: Thu, 22 Mar 2007 16:21:47 +0100

Hi all,

One of the issues that came up today was that of incremental  
deployability.  Many people felt that incremental deployability is an  
absolute hard and fast requirement.

My question: suppose that we had a solution that was a ships-in-the- 
night deployment?  Would that suffice?  Just as we are rolling out  
IPv6 in parallel with IPv4, would it be sensible to roll out IPv6+ in  
parallel with v6 and v4?  Assume that some form of tunneling could be  
used to bridge islands of connectivity.

Regards,
Tony

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "Schliesser, Benson" <[email-masked]>
Date: Thu, 22 Mar 2007 10:35:37 -0500

In my opinion as an SP, a ships in the night approach only works when there is (speaking broadly) an economic case for the deployment. I.e. Motivation to use the new protocol. If we can find a solution that benefits the end sites / users as well as the network providers, then a ships in the night deployment model is ok, but otherwise it is not ok.

(For example, if we find 1 solution to solve both mobility / connection sustainability as well as provider scale, then users and SPs all benefit, there is an alignment of motivations, and no inherent tension over the deployment between user and provider.)

Just my 0.40CZK.

Cheers,
-Benson

----- Original Message -----
From: [email-masked] <[email-masked]>
To: rrg <[email-masked]>
Sent: Thu Mar 22 10:21:47 2007
Subject: [RRG] On deployability

Hi all,

Regards,
Tony

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Mar 2007 17:57:01 +0100

Tony,

> My question: suppose that we had a solution that was a
> ships-in-the-night deployment?  Would that suffice?  Just as we are
> rolling out IPv6 in parallel with IPv4, would it be sensible to roll
> out IPv6+ in parallel with v6 and v4?  Assume that some form of
> tunneling could be used to bridge islands of connectivity.

There's a lot of detail behind the word "deployability"...

There's the question of needing some other node to change because
you want to achieve something. That's why we are talking about network
based approaches where the routing pain and deployment opportunity
coincide.

It also relates to the question of needing your peer to upgrade
before you get any of the benefits.

Then there's the question of needing to change many software
components in your box. For instance, not enough to upgrade your
OS but also have to upgrade the applications.

And the question of what infrastructure (DHT etc) needs to be
in place.

But to answer your IPv6+ question, we'd have to know what "+"
means. From the first item above I think it follows that
hosts will not change. So this probably means that its plain
old IPv6 to the hosts. Hence, we're essentially talking about
fancy new routing and identifier schemes within the network.
That might not need to have anything to do with IPv6 per
se (as LISP has shown). But there are a lot of possible
designs, so my conclusions may not hold for new ideas
that we have not seen yet.

Research questions aside, I'm not personally convinced
that it is worthwhile to design architectures that would
require applications to use new APIs. At least not before
we have exhausted other alternatives.

Jari

---

From: Aaron Falk <[email-masked]>
Date: Sat, 24 Mar 2007 16:35:54 -0400

On Mar 22, 2007, at 11:21 AM, Tony Li wrote:

> deployability.  Many people felt that incremental deployability is  
> an absolute hard and fast requirement.
>
> IPv6 in parallel with IPv4, would it be sensible to roll out IPv6+  
> in parallel with v6 and v4?  Assume that some form of tunneling  
> could be used to bridge islands of connectivity.

Apologies to the folks who've seen this before but Mark Handley has a  
relevant paper on deployment called "Why the Internet Only Just  
Works"[1].  It makes the case that when there is a shared perception  
that the need for change is dire new technologies can deploy very  
quickly.  CIDR is an example of where this perception existed.  IP  
Multicast, Mobile IP, quality of service, and ECN are examples where  
it didn't.

Based on this I'd say that if the folks who need to implement &  
deploy the technology share that perception of dire need, a ships-in- 
the-night deployment could work.

--aaron

[1] http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf