Subject: Re: [RAM] moving a discussion from various I* lists to [email-masked]

From: "Jeremy Hall" <[email-masked]>
Date: Thu, 21 Dec 2006 08:37:21 -0500

Hi,

I'm joining this a little late, but what other options do we have to
routing based on ip-address? It may be a silly question, but what about
routing based on origin as? It might be harder to control it, even
harder to implement it given the current inconsistent announcements, and
not practicle to implement, and would require a global flag day, all
sound bad to me.

Maybe I am too simplistic, but it seems to me you either have to change
what you key on, increase memory/cpu/whatever to continue to use the
existing ipv4 protocol for routing decisions, or come up with a totally
new way of routing.

But one thing I do believe is that this problem will not go away,
people will not be willing to discard multihoming, and it will get more
costly.

So what about a hybrid solution between as-based and ipaddress-based
routing?

ip-address routing is preferred over regional-based routing, so that we
split the world into domains and only hints to that domain are leaked
into other domains.  I tend to have some-what of a US-centric view
myself, so I would be interested to hear from those who have more modern
exposure to emea and asia routing practices.  Is there a large desire to
cross the continents? Would it be reasonable to entertain one or more of
the following suggestions:

1: impose sprint-like rules on continent boundaries desiring /10s or
larger? (I'm willing to negotiate up to /16)

2: form a consortium of "international" players that are willing to
abide by common goals and interests, possibly sharing the international
bandwidth as a single entity?

I'm not *THAT* optimistic any of these ideas are new, but worth
thinking about if for the moment it takes you to read this note.

_J

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

---

From: "Jeremy Hall" <[email-masked]>
Date: Thu, 21 Dec 2006 08:37:21 -0500

Hi,

_J

---

From: "Chris L. Morrow" <[email-masked]>
Date: Thu, 21 Dec 2006 18:25:38 +0000 (GMT)

On Thu, 21 Dec 2006, Jeremy Hall wrote:

> That is kindda what I meant by as-routing.

yup, this gets back to the possible solution (which for now I think we
can't really talk about until we know there is a problem, or have written
down that there is a problem and everyone or 'most everyone' agrees to
that problem.) of loc/id split. I believe Dino was working toward some
code that maybe looks like tunnel endpoints inside AS's with a way to find
the tunnel that and endpoint is behind.

Certainly one way to think about that is: "as routing", another might be
'giant nat', still another seems a lot like 'interprovider mpls'.

but, we should really agree on a problem first :)

>
> >>> "Chris L. Morrow" <[email-masked]> 12/21/06
> 1:12 PM >>>
>
> On Thu, 21 Dec 2006, Jari Arkko wrote:
>
> > The mobility mechanisms for current and all planned mobile
> > networks that I know of do not interact with the routing
> > system. They use mechanisms that hide the mobility
> > either from the Internet or even the host itself.
>
> it'd sure be nice to fix that wouldn't it? remove some of the
> complexity,
> let the host just migrate gracefully from attachment point to
> attachment
> point...
>
>
>

---

From: "Jeremy Hall" <[email-masked]>
Date: Thu, 21 Dec 2006 16:06:47 -0500

>>> "Chris L. Morrow" <[email-masked]> 12/21/06
1:25 PM >>>

yup, this gets back to the possible solution (which for now I think we
can't really talk about until we know there is a problem, or have
written
down that there is a problem and everyone or 'most everyone' agrees to
that problem.) of loc/id split. I believe Dino was working toward some
code that maybe looks like tunnel endpoints inside AS's with a way to
find
the tunnel that and endpoint is behind.

ah good, perhaps he will share his findings soon.

Certainly one way to think about that is: "as routing", another might
be
'giant nat', still another seems a lot like 'interprovider mpls'.

I didn't write down interprovider mpls because there is too much room
for mistrust and manipulation imho.  I doubt it would actually get
implemented fairly.

I thought we did that? or am I just being optimistic?

I have seen a lot of good descriptions of problems, so maybe now it
would be good to order them in priority of which ones we want to solve
first.

_J

---

From: "Azinger, Marla" <[email-masked]>
Date: Wed, 27 Dec 2006 10:28:59 -0500

> >> - Number of IPv6 prefixes will be smaller than in IPv4, for the
> >>   same number of users, because of more flexible addressing
> >>   architecture.
> >>     
> >
> > 	I don't think you can support that. In fact, recent RIR
> > 	policy argues against this assertion.
> >   
> Ok. Can you point to the policy that you were thinking of?

	>http://www.arin.net/policy/proposals/2005_1.html

	>(for example)

I think a point of clarification is useful here for folks only quickly reading these postings.  ARIN Policy does not specifically (in written form) argue or support any theory of the number of IPV6 prefixes vs the number of IPV4 prefixes.  However, some analysis of the implementation of the referenced policy (2005-1 Provider Independent IPV6 Assignments for End Sites)reveals that utilization of this policy can lead to a larger number of IPV6 prefixes than IPV4 prefixes in the future.  This is speculation right now, but it can become our reality.

Marla

-----Original Message-----
From: David Meyer [mailto:[email-masked]]
Sent: Thursday, December 21, 2006 9:54 AM
To: Jari Arkko
Cc: [email-masked]
Subject: Re: [RAM] moving a discussion from various I* lists to
[email-masked]

On Thu, Dec 21, 2006 at 07:15:24PM +0200, Jari Arkko wrote:
> It seems that my plan of posting bad assumptions
> in an effort to get you figure out the right ones
> worked... ;-)

	:-)

> >
> > 	Not turned on a single day would seem a reasonable
> > 	assumption (clearly). However, "grows gradually" is an
> > 	interesting assumption. I could see this go either
> > 	way. If all of a sudden every mobile handset has IPv6 and
> > 	HIP burned into it, is that "gradual"? What about
> > 	Microsoft's bet with Vista?
> >   
> Right. Its hard to estimate this, of course. But there
> are a number of factors to consider. For instance, as
> long as the hosts aren't getting native IPv6 from their
> ISP, I'm not sure the global routing table is affected
> by hosts that have IPv6 but don't use it or use it via
> a tunnel.

	So this is the "IPv6 deployment stalls" argument?  

> In any case, even a new mobile network or a popular
> OS version takes some time to actually be deployed
> and used. What I did in my model was to set a fairly
> aggressive IPv6 growth, in my case assuming 10%
> of the network would turn to IPv6 each year, i.e.,
> take 10 years for full IPv6 deployment. We could
> talk about whether this covers the sudden events.
> But is certainly much more aggressive than we are
> seeing today.

	Ok, its certainly worth looking at. 

> >> - Number of IPv6 prefixes will be smaller than in IPv4, for the
> >>   same number of users, because of more flexible addressing
> >>   architecture.
> >>     
> >
> > 	I don't think you can support that. In fact, recent RIR
> > 	policy argues against this assertion.
> >   
> Ok. Can you point to the policy that you were thinking of?

	http://www.arin.net/policy/proposals/2005_1.html

	(for example)

> >> - IPv4 keeps on growing until a certain day at which point
> >>   all the growth is in IPv6 (even if we run out of Ipv4 addresses,
> >>   we can split the current prefixes in smaller units... so the
> >>   day is far in the future)
> >>     
> >
> > 	I agree that the growth in IPv4 RIBs is bounded by some
> > 	O(m*2^32), <m> a description of the meshiness of the
> > 	Internet, and IPv4 FIBs are bounded by something like
> > 	O(2^32). The corresponding update streams have no such
> > 	bounds. So in that sense, if we got to /32 everything in
> > 	v4, it would stop growing. 
> >   
> Right.

	mod whatever dm/dt turns out to be, where dm/dt is (my
	notation for) the rate of change of the interconnection
	meshiness.  

> > 	Regarding all the growth being in IPv6, that is a loaded
> > 	assumption. What happenes if there is *no* v6 deployment,
> > 	but rather we see an (further) explosion of NAT (or
> > 	similar technology)?
> >   
> Indeed, that's also a possible future. I guess we want to
> see the worst scenario (within reasonable bounds)
> from the point of view of routing. To me that's the ability
> for people to get as much address space as they like.
> If it turns that we continue on the NAT path... I guess
> we would see somewhat less entries in the table. There
> would still be growth in the table, as the IPv4 space
> gets broken in smaller pieces. I don't have a good idea
> how to model this, do you? Or perhaps we don't need to.

	I'm not sure we need to either.

> > 	All that being said, the assumption is ok for purposes of
> > 	modeling.
> >
> >   
> >> - No upper bound on IPv6 growth
> >>     
> >
> > 	Meaning? No upper bound on the growth of the RIB? Well,
> > 	that would seem to be O(m*2^128).
> >   
> Right. Of course from our router construction point of
> view the crucial question is whether _speed_ of the
> allocation exceeds the speed of hardware improvement
> and whether the improvement stops at some future
> time. (Such as running out of steam on Moore's Law, as
> has been often predicted.)
>
> >> - Mobility is not a significant source of this problem *
> >>     
> >
> > 	Huh? Its one of the 3Ms (Multihoming, Mobility, and
> > 	Migration (to v6)).
> I think we can account for multihoming and provider independence based
> on the projected growth in the prefixes. The open question is whether
> the currently seen growth will change somehow, e.g., because more
> people will suddenly need provider independence. What's our best
> estimate for this now?

	Perhaphs Geoff's current work (the ATNAC2006 paper I've
	been citing)?

	Another issue (re: mobility) is the effect the larger
	effect of the impact of say, HIP, on the routing system.

> Migration to Ipv6 is handled as long as we count
> both Ipv4 and Ipv6 routes for the same users.

	Can you say a few more words about this? I'm not sure
	what you meant.

> But what I was saying was that I do not see any evidence of
> mobility suddenly changing the allocation or update rates,
> except for the network mobility part. But as I explained
> that it at least for now a very small part of the entire mobile
> market, and we might be able to find solutions for that.

	Sure.

> >  Regarding the note below (*), we do
> > 	need to understand how these technogies (i.e., HIP,
> > 	SHIM6, etc) interact with the routing system.
> >   
> system. 

	Right, which many folks think is a problem. So there will
	likely be some pressure to have the routing system become
	more "aware" of all of this. That is where the concern
	is, and where some good thinking will be required.

> They use mechanisms that hide the mobility

	Sure, see my previous comment.

> > 	How would you suggest moving forward with the modeling
> > 	exercise?
> >   
> Talking some more about the assumptions and growth
> predictions on this list would be useful. At some point
> the discussion needs to be turned into papers that
> have the full picture and which can be reviewed by others
> in the IETF and outside. And of course, if you can point
> us to existing work that would be great too.

	Sure. Have you read Geoff's stuff yet?

	--dmm