Subject: Re: [rrg] making a difference

From: "William Herrin" <[email-masked]>
Date: Mon, 1 Dec 2008 17:54:55 -0600

On Mon, Dec 1, 2008 at 12:57 AM, Michael Meisel <[email-masked]> wrote:
> First of all, we need to push forward with ISP-only solutions. It's the
> ISPs that stand to suffer the most from a rapidly growing global routing
> table, and they need some tools available to them *that do not depend on
> end host involvement* in case it gets out of hand.

Michael,

I disagree. IMO, we should focus not on who has the most to lose but
on who has the most to gain.

Focusing on the losers is a losing strategy. Losers generally act to
mitigate or contain their loss at the minimum expense. This reactive
and conservative attitude is maladaptive when the solution consists of
fresh, change-oriented ideas. To succeed, we want our plans to speak
to folks who for a reasonable investment can expect to improve their
strategic position.

ISPs are the losers in the routing scalability problem. This is just a
cost to them, and most of the solutions ask them to spend more money
now so they can -hopefully- spend less later. They can be expected to
offer miserly resources towards change.

Small multihomed entities and maybe also mobile users are the winners
in a routing scalability solution. These are the folks who will show
excitement and pony up the cash if we find a solution that does
something they want.

> Thus, we can't rely on anyone deploying any particular scheme, but we
> can provide the tools that will allow for a future where routing is
> scalable and robust.

Yes and no. There's a tipping point beyond which we can rely on
self-interest to induce the remaining deployment. To an extent we can
also create the first movers. The hard part is getting the first
movers to bring in the second movers with enough momentum to carry us
through the tipping point.

I will say that we should avoid a model where the first-movers club is
focused on a dozen or so transit-free core networks with disincentives
for anyone else to jump in early. You might recognize this deployment
model by its name: IPv6.

Consider how IPv6 deployment might have gone differently if:

* all pre-free pool exhaustion IPv6 deployment had been based on 6to4 addresses
* 2002::/8 subblocks permitted in the BGP core with a "shortest prefix
only" policy where only the one shortest IPv6 prefix announced by a
given AS was propagated without special arrangements with each other
AS.
* a requirement that any IPv6 address introduced into the core have
someone (either you or your ISP) running a 6to4 decapsulator to catch
IPv4-encoded IPv6 traffic,
* no IPv6 address assignments outside 2002::/8 until after the IPv4
free pool ran out
* encapsulation the expected norm wherever an IPv6 route was not
available but an IPv4 route was.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Paul Francis <[email-masked]>
Date: Mon, 1 Dec 2008 20:50:04 -0500

Actually, I agree with Michael in in-so-far-as that *somebody* should be
looking at ISP-only solutions.  This of course doesn't mean that others
shouldn't be looking at inter-ISP solutions at the same time.  

I've been very focused on ISP-only solutions, which is what led to the
Virtual Aggregation draft.  But this work is quite narrow in scope and not
particularly appropriate for RRG.  

PF

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of William Herrin
> Sent: Monday, December 01, 2008 6:55 PM
> To: Michael Meisel
> Cc: Routing Research Group Mailing List
> Subject: Re: [rrg] making a difference
> 
> > First of all, we need to push forward with ISP-only solutions. It's 
> > the ISPs that stand to suffer the most from a rapidly 
> growing global 
> > routing table, and they need some tools available to them 
> *that do not 
> > depend on end host involvement* in case it gets out of hand.
> 
> Michael,
> 
> I disagree. IMO, we should focus not on who has the most to 
> lose but on who has the most to gain.
> 
> Focusing on the losers is a losing strategy. Losers generally 
> act to mitigate or contain their loss at the minimum expense. 
> This reactive and conservative attitude is maladaptive when 
> the solution consists of fresh, change-oriented ideas. To 
> succeed, we want our plans to speak to folks who for a 
> reasonable investment can expect to improve their strategic position.
> 
> ISPs are the losers in the routing scalability problem. This 
> is just a cost to them, and most of the solutions ask them to 
> spend more money now so they can -hopefully- spend less 
> later. They can be expected to offer miserly resources towards change.
> 
> Small multihomed entities and maybe also mobile users are the 
> winners in a routing scalability solution. These are the 
> folks who will show excitement and pony up the cash if we 
> find a solution that does something they want.
> 
> 
> Yes and no. There's a tipping point beyond which we can rely 
> on self-interest to induce the remaining deployment. To an 
> extent we can also create the first movers. The hard part is 
> getting the first movers to bring in the second movers with 
> enough momentum to carry us through the tipping point.
> 
> I will say that we should avoid a model where the 
> first-movers club is focused on a dozen or so transit-free 
> core networks with disincentives for anyone else to jump in 
> early. You might recognize this deployment model by its name: IPv6.
> 
> * 2002::/8 subblocks permitted in the BGP core with a 
> "shortest prefix only" policy where only the one shortest 
> IPv6 prefix announced by a given AS was propagated without 
> special arrangements with each other AS.
> * a requirement that any IPv6 address introduced into the 
> core have someone (either you or your ISP) running a 6to4 
> decapsulator to catch IPv4-encoded IPv6 traffic,
> * no IPv6 address assignments outside 2002::/8 until after 
> the IPv4 free pool ran out
> * encapsulation the expected norm wherever an IPv6 route was 
> not available but an IPv4 route was.
> 
> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> 3005 Crane Dr. ...................... Web: 
> <http://bill.herrin.us/> Falls Church, VA 22042-3004

---

From: Dan Jen <[email-masked]>
Date: Mon, 01 Dec 2008 18:22:12 -0800

Hello,

On Mon, 2008-12-01 at 17:54 -0600, William Herrin wrote:
> To succeed, we want our plans to speak

Okay, but the scalability pressure will force the affected ISPs to act
in some way, however miserly.  So we could focus on giving them a good
option that will lead to a scalable Internet.  This would come in the
form of an ISP-based scalability solution.  

> excitement and pony up the cash if we find a solution that does

But the incentive to deploy for hosts(multihoming options and mobility)
is not to solve the problem(routing scalability).  Thus, what happens if
the routing tables grow too big for some ISPs to handle before enough
hosts adopt whatever host-based solution we propose?  With ISP-based
solutions, we can allow those that suffer from routing table bloat to
relieve that suffering through deployment of the new game.  The
incentive to deploy is exactly to gain relief from the problem.  I feel
this is an important property for a solution to routing scalability.  

We have a paper on separation vs. elimination that discusses this very
topic.  It can be found here:

http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

Dan

---

From: "Tony Li" <[email-masked]>
Date: Mon, 1 Dec 2008 19:02:11 -0800

|Okay, but the scalability pressure will force the affected ISPs to act
|in some way, however miserly.  So we could focus on giving them a good
|option that will lead to a scalable Internet.  This would come in the
|form of an ISP-based scalability solution.  

If the ISP's were going to act unilaterally, they would have done so by now.
They have trivial mechanisms to force aggregation of more specific prefixes
and have not deployed these. 

In short, ISP's expect others to solve this issue for them.  They push on
both vendors and on the I*TF to address this issue.

|But the incentive to deploy for hosts(multihoming options and mobility)
|is not to solve the problem(routing scalability).  Thus, what 
|happens if
|the routing tables grow too big for some ISPs to handle before enough
|hosts adopt whatever host-based solution we propose?

ISP's will then deply prefix filters (ala 1992), with concurrent loss of
Internet access/services to some parties.

Tony

---

From: Michael Meisel <[email-masked]>
Date: Mon, 01 Dec 2008 19:18:58 -0800

> and have not deployed these. 

To clarify, when Dan and I are talking about "ISP-only" or "ISP-based"
solutions, we mean *inter*-domain solutions that are deployed solely by
ISPs. So, solutions where perhaps one ISP can deploy unilaterally to
receive some benefit, but, more importantly, they can gain more when
other ISPs deploy.

> Internet access/services to some parties.

So shouldn't we be working on providing them with some better options?

-Michael

---

From: "Tony Li" <[email-masked]>
Date: Mon, 1 Dec 2008 20:31:46 -0800

|So shouldn't we be working on providing them with some better options?

That is the whole point of this.  However, to offer them something that is
both more expensive and less effective than the tools that they already have
is somewhat pointless.  Leading to an overall cleaner network architecture
is more likely to win adoption from them.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 1 Dec 2008 23:25:40 -0800

On Nov 30, 2008, at 10:57 PM, Michael Meisel wrote:

> Hi all, I've just been catching up, and I've noticed the  
> reappearance of
> a common theme that I think warrants discussion directly -- what
> difference we should make, how to do it, and if it's even possible.  
> Here
> are my thoughts on the issue, many pieces of which have been said by
> others before me (Tony, Lixia, Christian, Noel, Dave Conrad, and  
> Brian,
> to name a few).

thanks for the credit! :)
though it seems to be quite a distance between what's said this msg  
and my thought...

Let me just first focus on your 3 principles below

> There are many tiny changes happening constantly in the Internet on a
> small scale. These changes have the potential to add up to a radically
> different picture sometime down the road, as we've seen happen with  
> NAT.
> So, to have any influence on the network, we should be thinking about
> how we can tweak the small changes to push things in a good direction.
>
> I believe this means a focus on three principles:
>
> (1) The network will always be heterogeneous

agree in principle.
but some clarification here would help more: exactly along what/which  
dimensions of heterogeneity are you referring to here?
given this msg is about making changes, I interpreted "heterogeneous"  
here as measured by different interest, different reactions to any  
proposed changes.

> (2) Any large change will only happen as the aggregate result of many,
> many tiny changes at individual networks and hosts

I am not clear what is the definition of tiny and large here: what are  
you measuring?

> (3) It's not up to us (or any central authority) which tiny changes  
> get made

if you are saying the Internet has no boss, then I agree.
But I do believe that it is our job to understand what is driving the  
trend, so that we figure out how best to influence or facilitate the  
changes.

and just one more thing:

> (1) and (2) imply that we should push forward with some
> host-based scheme that separates the host's identifier from its  
> routable
> address.

not exactly sure what you meant by "host's identifier" here (e.g. LISP  
calls hosts' PI addresses as identifiers, and separate that out of  
global routing--is that what you meant here?)

> This is orthogonal to ISP-based solutions, and it is bound to
> be just what *someone* needs, and could make some difference in the  
> size
> of the routing table.

TO make a difference in routing table size: it may only take the  
action of a single or small number of parties to increase the routing  
table size; but to remove a prefix from the existing routing table  
requires every party, not just some hosts, knowing how to reach that  
prefix thru some new way.

Lixia

---

From: Michael Meisel <[email-masked]>
Date: Tue, 02 Dec 2008 00:39:29 -0800

Lixia Zhang wrote:
>> Hi all, I've just been catching up, and I've noticed the reappearance of
>> difference we should make, how to do it, and if it's even possible. Here
>> others before me (Tony, Lixia, Christian, Noel, Dave Conrad, and Brian,
>> to name a few).
> 
> though it seems to be quite a distance between what's said this msg and
> my thought...
> 
>> different picture sometime down the road, as we've seen happen with NAT.

Right, that's what I meant by it.

> I am not clear what is the definition of tiny and large here: what are

An example of a tiny change would be something like a tweak to a router
configuration, or an OS upgrade on a single end host. An example of a
large change would be moving the whole network to IPv6.

> trend, so that we figure out how best to influence or facilitate the

Right, I think we're in agreement here, we just stated it a bit
differently -- when you say influencing and facilitating changes, I
think you mean what I meant when I said developing and promoting new tools.

>> host-based scheme that separates the host's identifier from its routable
>> address.
> 

No, I meant we should push forward with some scheme that introduces
another layer of indirection in the host stack. I wasn't using
"identifier" in the LISP sense of the word.

-Michael

>> be just what *someone* needs, and could make some difference in the size
>> of the routing table.
> 
> TO make a difference in routing table size: it may only take the action
> of a single or small number of parties to increase the routing table
> size; but to remove a prefix from the existing routing table requires
> every party, not just some hosts, knowing how to reach that prefix thru
> some new way.
> 
> Lixia

---

From: "Tony Li" <[email-masked]>
Date: Wed, 3 Dec 2008 19:01:51 -0800

Hi Lixia, Michael,

|>> (3) It's not up to us (or any central authority) which tiny changes
|>> get made
|> 
|> if you are saying the Internet has no boss, then I agree.
|> But I do believe that it is our job to understand what is driving the
|> trend, so that we figure out how best to influence or facilitate the
|> changes.
|
|Right, I think we're in agreement here, we just stated it a bit
|differently -- when you say influencing and facilitating changes, I
|think you mean what I meant when I said developing and 
|promoting new tools.

I think you underestimate the power of the I*TF to help focus techonological
development.  If we, as a group, reach consensus on an approach and start to
implement it, then it carries an enormous amount of weight in directing the
rest of the industry.  Now, that does NOT mean that we get to dictate the
solution.  In fact, if we converge on something that the industry things is
a non-starter, then it's just wasted effort.  However, the power of a
consensus can cause thought to crystalize in one direction very, very
rapidly.  Our deployment of CIDR is a perfect example of this.  In the
course of about two years, we made a decision on how we wanted to go, went
off, wrote the documents, wrote the code and deployed it.  Done.

Tony

---

From: Lan Wang <[email-masked]>
Date: Wed, 3 Dec 2008 23:06:23 -0600

Tony,

This is a very interesting discussion.  I have a couple of questions  
below.

On Dec 3, 2008, at 9:01 PM, Tony Li wrote:

> a non-starter, then it's just wasted effort.

Could you explain what kind of things are non-starters for industry?

> However, the power of a

CIDR is one success story.  However, there are perhaps many more  
failure stories from I*TF and other standardization organizations,  
e.g. inter-domain IP multicast, .  They also had group consensus when  
they're developed.  So it would be great to learn some lessons from  
them.

A related note: I found the IAB draft " What Makes For a Successful  
Protocol?" (http://tools.ietf.org/html/draft-iab-protocol-success-04)  
quite informative.  Some of the initial success factors listed in the  
draft are "Positive Net Value (Meet a Real Need)" and "Incremental  
Deployability".

Lan

************************************************
Lan Wang
Assistant Professor
Computer Science Department
University of Memphis
Memphis, TN 38152

Phone: 901-678-2727
URL: http://www.cs.memphis.edu/~lanwang
***********************************************

---

From: "Tony Li" <[email-masked]>
Date: Wed, 3 Dec 2008 23:15:05 -0800

Hi,

|> In fact, if we converge on something that the industry  
|> things is
|> a non-starter, then it's just wasted effort.
|
|Could you explain what kind of things are non-starters for industry?

I don't think that there's a closed-form answer for that.  We have a history
of getting some things right and some things wrong.  It depends.  

|A related note: I found the IAB draft " What Makes For a Successful  
|Protocol?" (http://tools.ietf.org/html/draft-iab-protocol-success-04)  
|quite informative.  Some of the initial success factors listed in the  
|draft are "Positive Net Value (Meet a Real Need)" and "Incremental  
|Deployability".

Exactly.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Dec 2008 09:30:15 +1300

On 2008-12-04 18:06, Lan Wang wrote:
...
> CIDR is one success story.  

I hate to be a contrarian, but I think it's more accurate
to say CIDR *was* a success story (which you can clearly see
by examining the BGP growth curve for the 1994-1998 period).
It's much less clear that CIDR has been holding the floods
back since about 1999; there are other factors at work,
and the growth in PI assignments is probably the main reason
we're here (on this list).

    Brian

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 5 Dec 2008 18:22:06 +0100

Hi Brian,

|> CIDR is one success story.
|
|I hate to be a contrarian, but I think it's more accurate
|to say CIDR *was* a success story (which you can clearly see
|by examining the BGP growth curve for the 1994-1998 period).
|It's much less clear that CIDR has been holding the floods
|back since about 1999; there are other factors at work,
|and the growth in PI assignments is probably the main reason
|we're here (on this list).

Without CIDR (and supernets), wouldn't we have > 2 million Class C prefixes
in BGP?

I would say Internet is a success story. That's the main reason we're here.

Teco

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Dec 2008 08:53:44 +1300

> Without CIDR (and supernets), wouldn't we have > 2 million Class C prefixes

Oh sure... but you may have noticed that we have more prefixes than we have
ASes, and in an ideally CIDRized and aggregated world that would not be the case.

> I would say Internet is a success story. That's the main reason we're here.

Undoubtedly.

    Brian