Subject: [RRG] Thoughts on the RRG/Routing Space Problem

From: Russ White <[email-masked]>
Date: Thu, 29 Nov 2007 16:22:00 -0500

I was reading through all the various threads here over the last couple
of weeks, and also going through some of the proposals, and through some
of the slide decks that have been sent out, and I have a couple of
questions, actually.... These might seem fundamental, and maybe they're
answered someplace, but I thought they were worth asking, anyway. Maybe
someone can just say: "These are dumb questions!," I don't know. :-)

1. There seems to be a concensus that splitting the "transit" address
space from the "end user" address space is "the solution." I'm a little
worried about this assumption, for various reasons. I'm hoping someone
can tell me I'm crazy, and that my disquiet is just based on a figment
of my imagination.

Looking back to this quote from one of the slide decks:

Clark: "There are clearly two classes of network entities, subscribers
and providers; there may be a gray area but that is not important."

I'm under the impression that the "gray area" that's "not important" is
actually growing in size, rather than reducing in size--that the split
between transit and host/service isn't along provider/customer lines,
but rather within all of these networks, and that this is becoming more
common, rather than less.

For instance, it appears a lot of providers are moving out of the "pure
transport" space and into offering services, as well, because services
tend to produce higher revenues (?). At the same time, there are a lot
of "enterprise" customers who now host services directly, as well as
provide transit for others who provide services. For instance, a large
retailer might provide shelf space and transport for a brand name within
their store, rather than directly managing that shelf space themselves.
This happens in all sorts of venues--governments, theme parks, retail
spaces, etc., and I think this might be becoming more common rather than
less (?).

Does anyone else have any sort of sense on this? What's the impact if we
push an artificial split into this area, and find we're wrong--that the
gray area is, in a sense, the *only* interesting area with good revenues
for everyone?

2. There seems to be some idea that traffic engineering is primarily
done along the "provider/customer" edge, which I don't think to be true.
In fact, I think there are two sorts of "traffic engineer" in view, the
first of which is within a given AS, and the other of which attempts to
influence the point at which traffic enters an AS. These two sorts of
traffic engineering are, generally, opposed to one another, or rather,
in many situations probably attempt to influence traffic to take
different paths.

I think we've oversimplified the concept of "traffic engineering" in our
thinking, and therefore we've not considered the full impact of it. Is
it really true that providers don't care where traffic enter their
networks? If they do, then with what granularity do they care?
Traditionally, traffic engineering is done to the granularity of the
reachable destination. What new mechanism will be deployed to allow
granularity of this same fineness, and yet not cause the table size to
increase?

Anyway, those are my dumb questions. Maybe they'll spark some useful
discussion somewhere along the way.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

--
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: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Nov 2007 14:07:00 +1300

Russ,

On 2007-11-30 10:22, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

<snip>

> gray area is, in a sense, the *only* interesting area with good revenues

I've been worried about the notion of a "split" as too absolute for some
time, but I think the key point is not actually the notional split.
It's the addition of a (relatively static) locator-to-locator mapping
to the (relatively dynamic) use of locators for route computation.
As I've complained from time to time, LISP EIDs aren't really EIDs;
they are just locators that don't happen to be used for global route
computation.

I think that leaves scope for the gray area (e.g. map a locator to
itself to indicate that it keeps its own entry in the tables).

> granularity of this same fineness, and yet not cause the table size to

My guess is that it will be done to the granularity of a *mapped*
destination (RLOC), and that will be coarser grained than today. But again,
the gray area can remain to allow fine granularity in a few exceptional
cases.

     Brian

---

From: Robin Whittle <[email-masked]>
Date: Fri, 30 Nov 2007 23:43:46 +1100

Hi Russ,

I don't think of my Ivip ITR-ETR proposal as a locator-ID separation
protocol, though it could be viewed that way.  Nor does this
proposal rely much on a hard separation between ISPs and end-users.

The idea is that Ivip will provide some areas of the address space
with new capabilities, and certain restrictions.

Using terminology from http://psg.com/lists/rrg/2007/msg00533.html,
a BGP advertised prefix controlled by Ivip is a "Mapped Address
Block" (MAB) which can be split into any number of "micronets".

Packets addressed to each micronet are sent to a particular ETR,
anywhere in the world, and (ideally) this mapping will be changeable
with little cost, within a few seconds, to any other ETR.

Micronet address space can't be used for certain things:

  ETRs
  Anything to do with the Ivip infrastructure
  Root and probably TLD nameservers
  BGP routers

So micronet space is not suitable for the primary address space of
an ISP.

However, an ISP would be able to place its public-facing web servers
on micronet addresses.  I am not sure why the ISP would want to, but
there may be reasons.

Also, there are certain restrictions on where ITRs and ETRs can be
located, such as not behind NAT.

Administratively, people who use micronets have a different
arrangement and set of dependencies than they would if they had PI
space today.  The primary difference is that they don't need BGP
expertise, to be a member of an RIR etc. - so it would be much less
expensive.  Also, micronets can be assigned to different end users
without any impact on BGP - saving a great deal of administrative
costs and inertia.  In some ways, it would be like getting PA space
from an ISP, but the space would be usable via any ISP which
provides an ETR.  More on this in:

  http://psg.com/lists/rrg/2007/msg00536.html

The main benefit is that micronets can be of any size, from 1 IP
address to any number of them - compared to the effective 256
address granularity of the current and likely future IPv4 BGP system.

Ivip enables a much finer, faster, cheaper, slicing and dicing of
address space - including (ideally) for mobility with generally
optimal path lengths - without requiring more BGP advertised
prefixes (other than one for every MAB) and without involving the
BPG system in any changes to advertised prefixes when the micronets
are mapped somewhere different.

This obviously has lots of uses - including enabling millions of
end-user networks to be multihomed with their own genuinely portable
address space.

One benefit is that IPv4 address space will be able to be more
efficiently used, in terms of number of actually used addresses and
in terms of a greater number of separate multihomed end-user networks.

I think the other proposals - LISP, eFIT-APT and TRRP - can in
principle be used in the same way.  They may be presented in a more
mathematically defined way, such as "Locator ID Separation".  These
other proposals are not aimed so much at better address utilisation,
but I think they could all be used to achieve this.

Generally, micronets are useful for an "end-user" - someone who
wants Internet access but doesn't sell Internet access to others in
a big way.  As you write, many organisations known as ISPs also do
things which do not involve selling Internet access - so they may
find micronets useful for some of those activities.

  - Robin        http://www.firstpr.com.au/ip/ivip/

---

From: Scott Brim <[email-masked]>
Date: Fri, 30 Nov 2007 09:38:19 -0500

> can tell me I'm crazy, and that my disquiet is just based on a figment

I'm open to other ideas.  I just tend to like the map&encap approach
because it feels more architecturally deterministic.  Data plane
changes are constrained, hosts and routing protocols remain the same,
modularity constrains complexity, and we can focus on the mapping
function.  However, I'm still thinking outside of map&encap, and
welcome suggestions (even if I am behind on mail).

> common, rather than less.

This and everything you say below is all true, but I don't understand
the import.  The issue here is IP addressing and routing over the
global Internet.  If a higher layer service is provided via servers
attached to a local enterprise or ISP, then the packets aren't being
routed inter-domain, and I'm not going to worry about them (in this
context).  From the point of view of IP routing and addressing, it
doesn't matter what *kind* of network it is -- packets is packets.  

> they are just locators that don't happen to be used for global route

Sure, but you still need to clearly distinguish the scope of the
"locator" you are talking about.  I think our discussions have
demonstrated that the old uses of "identifier" and "locator" don't fit
current needs, and we never settled on new terms.  We all know what
the terms mean in the LISP drafts.  Lixia once suggested "globally
routed address" and "globally deliverable address".  I don't care
about terminology but if you say "locator" I'll say "what scope", and
if you say "identifier" I'll say "what context".  So for now I use
RLOC and EID.

> itself to indicate that it keeps its own entry in the tables).

If a locator already has global scope, there will be no need to do a
mapping lookup or use in doing so.  It will already be represented in
global routing, if present.  

> the gray area can remain to allow fine granularity in a few exceptional

NSPs might care very much where traffic enters, and might want to map
specific destination prefixes to specific entry points.  This can be
very fine-grained.  Some mapping mechanisms behave poorly with a  huge
number of mapping entries and may constrain this.  That should be an
evaluation criterion.  

swb

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 30 Nov 2007 09:48:54 -0600

Thus spake Russ White
> worried about this assumption, for various reasons. I'm hoping
> someone can tell me I'm crazy, and that my disquiet is just based on
> a figment of my imagination.

I don't think it's so much a separation of address spaces, but a separation 
of AS types.  I don't see how we'd get incremental deployability with truly 
split address spaces.

> and providers; there may be a gray area but that is not important."

I think this is a slight misstatement.  There _are_ clearly two classes of 
ASes: transit and leaf.  It's easy to tell which are which, and the vast 
majority of growth is in the latter.

I believe some people are using "provider" as shorthand for "transit AS" and 
"subcriber" for "leaf AS".

> I'm under the impression that the "gray area" that's "not important"
> is actually growing in size, rather than reducing in size--that the
> split between transit and host/service isn't along provider/customer
> lines, but rather within all of these networks, and that this is
> becoming more common, rather than less.

We've heard, in RIR meetings, over and over again that operators in the DFZ 
are scared of widespread multihoming and PI because each leaf AS requires a 
slot in the DFZ, and there aren't (and won't be) enough slots available to 
handle the demand.  This has resulted in high artificial bars to entry, 
denying a huge fraction of the Internet reliable service.

If we are able to constrain BGP tables to only transit ASes, the DFZ becomes 
a lot smaller and we can afford to let everyone, even home users, multihome 
with PI space.  (Of course, there's a hidden assumption there that the 
number of transit ASes will remain under control, but I haven't seen anyone 
dispute that.)

Under this model, hosts in a leaf AS would have EID != RLOC while hosts in a 
transit AS might have EID == RLOC.  Written that way, it becomes irrelevant 
whether the host is a client or a server (or both), or who owns what, or 
whether it's a "service" provided by a "transport" company.

> done along the "provider/customer" edge, which I don't think to be
> true.  In fact, I think there are two sorts of "traffic engineer" in view,
> the first of which is within a given AS, and the other of which
> attempts to influence the point at which traffic enters an AS. These
> two sorts of traffic engineering are, generally, opposed to one
> another, or rather, in many situations probably attempt to influence
> traffic to take different paths.

The first case is not our problem, since it's entirely within a single AS 
and not visible to the world; that can be handled by a variety of existing 
tools, e.g. MPLS, or proprietary vendor solutions.

The latter is an explicit goal.  Today, one really can't control which 
sources use which entrance, just a rough knob for the ratios of how much 
enters in each or which destinations can use which entrances.  LISP doesn't 
seem to make the situation any worse, and depending on how complex the 
mapping gets, might make it better.  For instance, it might be possible (at 
some point) to make the mapping dependent on the source address, though I 
haven't seen anyone propose that yet.  We're still trying to figure out how 
to get destination-only mapping working :)

> I think we've oversimplified the concept of "traffic engineering" in
> our thinking, and therefore we've not considered the full impact of it.
> Is it really true that providers don't care where traffic enter their
> networks?

They definitely do, as do many leaf ASes.  Heck, even in the context of a 
residential user I care whether the traffic to my PC uses my DSL line, the 
open WiFi AP across the street, or my cell phone.

> If they do, then with what granularity do they care?  Traditionally,
> traffic engineering is done to the granularity of the reachable
> destination.

Nit: it's traditionally done to the granularity that one can get peers to 
accept prefixes for groups of destinations.

> What new mechanism will be deployed to allow granularity of this
> same fineness, and yet not cause the table size to increase?

The EID-to-RLOC mapping can be far more granular since it doesn't impact 
routing tables; you can give individual EIDs different mappings if desired. 
This is far superior for destination-based TE than what we have today, where 
you have to apply BGP-based TE to an entire /24 or even /20.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Nov 2007 09:51:59 -0800

>  I don't see how we'd get incremental deployability with truly  
> split address spaces.

One way would be to split them in such a way that they jointly  
remained syntactically similar to the original address space.  This  
is one of the cuter things about GSE.  Then new generation systems  
could recognize them as split (via a compatibility bit someplace) and  
to legacy systems, it would appear to be a legacy address.

> If we are able to constrain BGP tables to only transit ASes, the  
> DFZ becomes a lot smaller and we can afford to let everyone, even  
> home users, multihome with PI space.  (Of course, there's a hidden  
> assumption there that the number of transit ASes will remain under  
> control, but I haven't seen anyone dispute that.)

There's also a hidden assumption there that you can do that.  One  
practical definition of PI space today is that your prefix is in BGP.

Tony

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 30 Nov 2007 13:00:57 -0600

Thus spake Tony Li
>>  I don't see how we'd get incremental deployability with truly  split 
>> address spaces.
>
> One way would be to split them in such a way that they jointly  remained 
> syntactically similar to the original address space.  This
> is one of the cuter things about GSE.  Then new generation
> systems could recognize them as split (via a compatibility bit
> someplace) and to legacy systems, it would appear to be a
> legacy address.

I suppose that's a "split"; I thought Russ was worried that there would be 
two (potentially overlapping) address spaces, one for providers and one for 
customers, as opposed to a single address space which was divided into RLOCs 
and EIDs.  For instance, there's been mention of using IPv6 for EIDs and 
IPv4 for RLOCs, which has some interesting properties.

Along your lines of a split, I like the idea of using 4000::/3 for 
LISP-mapped EIDs and deprecating PI space in 2000::/3.  It's a bit tougher 
to apply the same split to v4 since there won't be any /8s left by the time 
a solution is standardized...

>> If we are able to constrain BGP tables to only transit ASes, the  DFZ 
>> becomes a lot smaller and we can afford to let everyone,
>> even home users, multihome with PI space.  (Of course, there's
>> a hidden assumption there that the number of transit ASes will
>> remain under control, but I haven't seen anyone dispute that.)
>

That's one way of looking at it, but that's only a result of the fact that 
PI space _can't_ be reached today unless a prefix is in BGP.  Technically, 
if I got a block from my RIR for internal use, it's still PI space even if 
it never shows up in BGP.

With LISP, I envision a world where PI space and EID blocks are the same 
thing, and neither shows up in the DFZ -- other than a single EID aggregate 
that leads to anycast ITRs (to handle legacy senders).

S

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Nov 2007 11:21:27 -0800

> I suppose that's a "split"; I thought Russ was worried that there  
> would be two (potentially overlapping) address spaces, one for  
> providers and one for customers, as opposed to a single address  
> space which was divided into RLOCs and EIDs.  For instance, there's  
> been mention of using IPv6 for EIDs and IPv4 for RLOCs, which has  
> some interesting properties.

Russ' concern is certainly a valid one, however it presumes that  
we're using the address space in a LISP-like way.  That's not the  
only game in town.

>>> With LISP, I envision a world where PI space and EID blocks are  
>>> the same thing, and neither shows up in the DFZ -- other than a  
>>> single EID aggregate that leads to anycast ITRs (to handle legacy  
>>> senders).

That's certainly an interesting vision.  The EID allocation problem  
seems like it could be quite daunting politically and only applicable  
to v6.

Tony

---

From: Scott Brim <[email-masked]>
Date: Fri, 30 Nov 2007 14:43:00 -0500

> majority of growth is in the latter.

Sure, but to clarify, "AS" is used in a generic sense, including some
sites which would not have an AS Number today.

> to get destination-only mapping working :)

Map-Replies can be source-dependent in at least some of the mapping
proposals.  In ALT (and EMACS), the Map-Reply comes from the ETR, so
the owner of the ETR gets to apply policy.  In NERD and CONS, you can
still apply policy, but since mappings are disseminated and cached the
policy itself has to be disseminated to be effective, and some sites
might be reluctant to do so.

Excerpts from Stephen Sprunk on Fri, Nov 30, 2007 01:00:57PM -0600:
> customers, as opposed to a single address space which was divided into 
> RLOCs and EIDs.  For instance, there's been mention of using IPv6 for EIDs 
> and IPv4 for RLOCs, which has some interesting properties.

I am concerned about totally decoupling the addressing domains, and
allowing reuse of addresses, for two reasons.  First, operations: I
think it would be confusing to operators to always have to provide
context when talking about "240.1.2.3".  Second, it might be useful to
allow end nodes to send packets directly to globally routed addresses
in the DFZ domain.  On both of these, we don't know yet if it's going
to be a problem, so let's put off reusing addresses for a while.  

> a solution is standardized...

The more LISP gets deployed, the more inconsequential the PI/PA
differentiation problem becomes, so I'm hoping this kind of stringent
rule will "quickly" be relaxed (I'm not going to define "quickly").

Excerpts from Tony Li on Fri, Nov 30, 2007 11:21:27AM -0800:
> seems like it could be quite daunting politically and only
> applicable to v6.

I'm not sure what this means.

---

From: Kevin Loch <[email-masked]>
Date: Fri, 30 Nov 2007 18:12:46 -0500

Tony Li wrote:
> syntactically similar to the original address space.  This is one of the 
> cuter things about GSE.  Then new generation systems could recognize 
> them as split (via a compatibility bit someplace) and to legacy systems, 
> it would appear to be a legacy address.

I've been thinking about how a new address format definition would help
a scenario like this.

Scalable Address Format (SAF):

0001[ASN 5-15]:[ASN 16-31]:[inter-ASN topology 0-31]:[routing hint 0-63]

inter-ASN topology allows variable length subnetting between /32 and
/63.

ASN bits 0-4 are not used
ASNs 4096.0 - 65535.65535 must not be used with this format

Higher network layers must ignore and/or set bits 64-127
to zero.  For compatibility border routers may set these
to zero if necessary.

For example ASN 6.3:

1006:3:100:1:: saf host address with no hint
1006:3:100:1:2001:4810:0:100 saf host addr with global uni subnet hint

Forwarding routers that understand and act on SAF addresses space
only need to have a route for the hint network.   The hinted network
needs to know how to get to the end site but nobody else does.

The hint could be set by originating host, forward dns or reverse dns
lookups.  ASN tricks might also work as the end site ASN is encoded.
Routers may need to dump packets to lookup servers for setting hints.
All dns servers should be located on addresses covered by conventional
global unicast routes if DNS is used for hint resolution.

There are many ways to define who is allowed or not allowed to set the
hint bits and how lookups are done.  You could also do lookups by
ASN as it is encoded in the address as a last resort.

A side effect of this is that RIR's only need to manage ASN's, not
address blocks.  Each ASN allows for 32 bits of inter-ASN topology,
which the site can divide between subnet/host bits as desired.

- Kevin

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Nov 2007 16:03:30 -0800

Kevin,

> 0001[ASN 5-15]:[ASN 16-31]:[inter-ASN topology 0-31]:[routing hint  

In this scheme, is there any hope for aggregation above a /32?

IMHO, 4 billion routes is a tad too many.  ;-)

Tony

---

From: Kevin Loch <[email-masked]>
Date: Fri, 30 Nov 2007 19:22:28 -0500

> IMHO, 4 billion routes is a tad too many.  ;-)

If you are a transit provider, you only need the routes for your 
customers and routes for other transit providers.  You do not
need the routes of other transit providers customers, the routing
hint points you to one of their providers.

Of course it would be possible to leak customer routes to other
providers if the participants preferred that for some routes.

If you were a multihomed end site, you would probably get
a feed of all global transit provider routes, minus remote
customer routes, plus your own providers customer's routes.

The minimum set of routes is all transit providers (the
address space used for hints).

- Kevin

---

From: Russ White <[email-masked]>
Date: Sat, 01 Dec 2007 08:24:16 -0500

I started off a thread I can't keep up with. :-) I'm going to try and
summarize a bunch of things here, in one email.

> I think this is a slight misstatement.  There _are_ clearly two classes
> of ASes: transit and leaf.  It's easy to tell which are which, and the
> vast majority of growth is in the latter.

This is precisely what I question. I've provided some examples below, so
as not to make the main text here too long, but, IMHO, the main area of
growth in the 'net today is in AS' which have the characteristics of
both a transit and a leaf.

> Nit: it's traditionally done to the granularity that one can get peers
> to accept prefixes for groups of destinations.

Right--the smallest block of reachable destinations, today, is the
longest prefix your peer will accept.

> routing tables; you can give individual EIDs different mappings if
> desired. This is far superior for destination-based TE than what we have
> today, where you have to apply BGP-based TE to an entire /24 or even /20.

Doesn't this increase the size of the Locator table, over time, to be
precisely the size of the EID table? There appear to be several drivers
in place to push more discrete routing into the fore--again, see below
the sig for instances.

The net result is granularity ends up at the host level, or perhaps
below, at the flow level. I'm not certain mapping helps this--because
mapping assumes that once you hit the leaf/transit divide, the
granularity levels automatically decrease. I'm concerned this no longer
true--the 80/20 rule is in it's last gasps, I think, and we have to
figure out how to work in a world with 20/80, maybe, or 100/100, in some
sense.

It's easy to say: "We'll map at the edge, and then aggregate the space
we're mapping in to." Then along comes a situation where we need more
granular traffic engineering than the mapping we're using, so we break
the mapping space up into smaller chunks, and give each piece a more
granular piece. This is of little cost to the provider who does it--it
only increases the mapping table size by one--and gives them much more
control over traffic flow to destinations for which traffic transits
their network. There must be exceptions, and exceptions turn out to be
the rule.

Anyone see any similarity to the way the IPv4 address space is handled
today? Everyone still gains by pushing more granular information into
the table, at little cost to themselves. We could say: "Ah, but we'll
just limit the length to something quite a bit longer than what is
allowed today!" Given the drivers for more granularity, what you most
likely end up with here is either:

1. People need the service, so they will find a way. If IP won't do it,
then IP==POTS. Let's retire now, and be done with it.

2. An exponentially growing table of short prefixes, facilitated by the
huge IPv6 address space (as Tony has pointed out, routing /32's in IPv6
is the same thing as routing hosts in IPv4, so you've gained nothing in
table size if you go in that direction).

:-)

Russ

- --

==
1. The Transit/Content Provider

I, like most folks on this list, get my 'net access through a cable
provider. They pick up the traffic from the edge of my network (I have
four routers in my house, all live, none just for lab or test--and I
assume, at some point, that every house is going to have an entire
network of devices, not a single device), transport it through their
network, and send it to their upstream. They do the same for entire
business networks, with their "business class" services. Hence, they
should be treated as a transit AS.

OTOH, they provide services, such as pay for play, where they provide
the content locally, and allow their subscribers to use those services.
Those services consist of information carried across a transit network,
the 'net, from some content creator to their network. They have
"terminal" servers in place to handle receiving and processing this
content. They also create content locally, and sell it to other content
providers throughout the world. Hence, they should be treated as a leaf AS.

2. The Content/Transit Provider

Suppose you have some entertainment company that creates a lot of
content. They have a lot of servers, and sell content to a lot of
different providers, and direct to consumers, as their primary forms of
business. Since they terminate a lot of traffic, they should be treated
as a leaf AS.

They also have a lot of subcontractors working for them, and have, in
fact, contracted out an entire facility (outsourced) from some other
creative house. These people must not only have access to the
entertainment company's network, they must also have access to their
"home" network, for tools, material, and management. The entertainment
company simply creates a path for them to reach their home company
through their 'net connection (it's cheaper to converge the traffic
rather than paying for separate access), and transit it. They should
then be treated like a transit AS.

In fact, this situation plays out in more ways.... A large theme park
operator also provides content locally, and then transits traffic for
contractors who run entire venues, such as stores and eateries, within
the confines of the theme park, for instance. They are also both a
transit AS and a leaf node AS.

3. The Government/Transit Provider

Any given US state government offers a number of, well, "services" to
the people who live there. For instance, the ability to pay their taxes
online comes to mind (I'm hesitant to use the word "service" and "pay
taxes" in the same sentence. :-) ). They also might provide information
about state colleges, tourist information, and others. Hence, they
should be treated as a leaf AS.

At the same time, every US state government also has a lot of
departments that want access to the 'net, and also to have transport
between the various offices of that department. Think your local DMV.
Okay, sorry for injecting such a horrible thing into your head. It's
like the tune that you can't stop playing in your head over and over
once you year it, isn't is? :-)

The state gov't provides all of these various departments transport and
access to the 'net across their network. Hence, they are a transit AS.

I'm certain there are a thousand more "grey area" networks--in fact, I'm
certain "grey area" networks are growing in percentages, and "pure"
networks are going away. Every coffee house is a "grey area" network,
although they handle it today by having two separate networks, or using
some other form of semi-physical separation. Every hotel is in the same
position. At some point, people are going to tire of using two
connections to do this stuff--we're telling them to converge, and they
want to. :-)

==
Drivers for more granularity

For instance:

1. Traffic engineering is quickly becoming a service by service affair,
rather than a network affair, particularly on the server side of things.
How many folks eat an entire subnet (/24) today, for a single service,
so they can engineer traffic to that service specifically?

2. Quality of service threatens to add more granularity--you can no
longer treat a host as a single traffic endpoint, from the network's
point of view. Instead, a single host actually needs multiple virtual
(or logical, if you will) connections, each with different
characteristics. You can provide those connections through different
queuing mechanisms in the network, or through layer 3 virtualization, or
through some other means, but you still have to deal with multiple
distinct streams with the same source/destination pair in some
way--which means it becomes harder and harder, over time, to treat a
subnet as a single "unit," I think.

3. Mobility adds more granularity, as well. While mobility on a per host
basis isn't a "killer app," it's quickly becoming something that's just
expected. People see they have partial mobility with their cell phones,
and they want more (or rather content providers want them to have more).
If IP doesn't step up the plate on this, then IP == POTS, and we can all
just retire into our easy chairs, and talk about the "good old days," IMHO.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 2 Dec 2007 03:08:24 -0600

Thus spake "Scott Brim" <[email-masked]>
>> I think this is a slight misstatement.  There _are_ clearly two
>> classes of ASes: transit and leaf.  It's easy to tell which are which,
>> and the vast majority of growth is in the latter.
>

Correct.

>> sources use which entrance, just a rough knob for the ratios of
>> how much enters in each or which destinations can use which
>> entrances.  LISP doesn't seem to make the situation any worse,
>> and depending on how complex the mapping gets, might make
>> it better.  For instance, it might be possible (at some point) to
>> make the mapping dependent on the source address, though I
>> haven't seen anyone propose that yet.  We're still trying to figure
>> out how to get destination-only mapping working :)
>
> Map-Replies can be source-dependent in at least some of the
> mapping proposals.  In ALT (and EMACS), the Map-Reply comes
> from the ETR, so the owner of the ETR gets to apply policy.

That makes sense.  I didn't catch that possibility when reading those 
drafts; thanks for the correction.

> In NERD and CONS, you can still apply policy, but since
> mappings are disseminated and cached the policy itself has to
> be disseminated to be effective, and some sites might be
> reluctant to do so.

Not to mention that the policy can't be very dynamic in those cases, due to 
the assumed slow propagation (and/or caching) and desire for low churn.

Ivip's goal of fast propagation is interesting, but the thought of millions 
of sites updating their EID mappings every few seconds based on server loads 
(and you know someone would try it...) scares me.

>> providers and one for customers, as opposed to a single
>> address space which was divided into RLOCs and EIDs.  For
>> instance, there's been mention of using IPv6 for EIDs and IPv4
>> for RLOCs, which has some interesting properties.
>

I don't understand how a solution could be incrementally deployable unless 
both the EID space and the RLOC space were distinct parts of our existing 
address space.  They can't overlap as long as there's a single legacy site 
left, which means forever in practice.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 2 Dec 2007 02:55:29 -0600

Thus spake "Russ White" <[email-masked]>
>>> Clark: "There are clearly two classes of network entities,
>>> subscribers and providers; there may be a gray area but that is
>>> not important."
>>
> This is precisely what I question. I've provided some examples
> below, so as not to make the main text here too long, but, IMHO,
> the main area of growth in the 'net today is in AS' which have the
> characteristics of both a transit and a leaf.

I disagree; transit and leaf are fundamentally mutually exclusive.  Either 
your AS provides transit to the DFZ for another AS or it doesn't.

>> The EID-to-RLOC mapping can be far more granular since it
>> doesn't impact routing tables; you can give individual EIDs
>> different mappings if desired. This is far superior for destination-
>> based TE than what we have today, where you have to apply
>> BGP-based TE to an entire /24 or even /20.
>
> precisely the size of the EID table?

No.  The mapping table may get disturbingly large, but the locator table 
(i.e. DFZ) shouldn't grow in proportion.

For instance, if I (as a leaf AS) have five ISPs, there will be exactly five 
routes to my five locators -- the aggregates from those ISPs.  However, I 
could have potentially thousands of EIDs, each mapped individually to a 
random selection of those locators in a way that couldn't be aggregated.

> granularity levels automatically decrease. I'm concerned this no
> longer true--the 80/20 rule is in it's last gasps, I think, and we have
> to figure out how to work in a world with 20/80, maybe, or 100/100,
> in some sense.
>
> It's easy to say: "We'll map at the edge, and then aggregate the
> space we're mapping in to." Then along comes a situation where
> we need more granular traffic engineering than the mapping we're
> using, so we break the mapping space up into smaller chunks,
> and give each piece a more granular piece. This is of little cost to
> the provider who does it--it only increases the mapping table size
> by one--and gives them much more control over traffic flow to
> destinations for which traffic transits their network. There must be
> exceptions, and exceptions turn out to be the rule.
>

This is the problem the DFZ sees today, yes, and the goal is to get all of 
that junk out of the routing (locator) tables.  It's natural to assume all 
that junk will then inhabit the mapping tables -- and probably multiply like 
rabbits.  That means we've traded one problem for another, but we seem to be 
operating on the assumption that a mapping table is easier to scale than a 
routing table.

> should be treated as a transit AS.

Most ISPs will be transit ASes, though I can think of a few examples of ones 
that probably wouldn't be.

> OTOH, they provide services, such as pay for play, where they
> provide the content locally, and allow their subscribers to use those
> services.  Those services consist of information carried across a
> transit network, the 'net, from some content creator to their network.
> They have "terminal" servers in place to handle receiving and
> processing this content. They also create content locally, and sell
> it to other content providers throughout the world. Hence, they

If they're providing transit connectivity to other ASes, they're a transit 
AS.  What their business model is above the IP layer is irrelevant.

> Suppose you have some entertainment company that creates a
> lot of content. They have a lot of servers, and sell content to a lot
> of different providers, and direct to consumers, as their primary
> forms of business. Since they terminate a lot of traffic, they should
> be treated as a leaf AS.

Terminating a lot of traffic has nothing to do with it.

> They also have a lot of subcontractors working for them, and have,
> in fact, contracted out an entire facility (outsourced) from some
> other creative house. These people must not only have access to
> the entertainment company's network, they must also have access
> to their "home" network, for tools, material, and management. The
> entertainment company simply creates a path for them to reach
> their home company through their 'net connection (it's cheaper to
> converge the traffic rather than paying for separate access), and
> transit it. They should then be treated like a transit AS.

They're not providing transit to the outsourcer because they do not show up 
in the AS Path for the outsourcer as viewed from the DFZ.  For that matter, 
neither their address space nor that of the outsourcer should be in the DFZ 
at all; they'd have different EID blocks that were mapped to their 
respective ISP(s)' RLOCs.  They might have a private connection so that each 
others' EIDs were routed internally, or they might talk via their ITRs and 
ETRs across the public network.

> contractors who run entire venues, such as stores and eateries,
> within the confines of the theme park, for instance. They are also
> both a transit AS and a leaf node AS.

They cannot be both.  There are arguments both ways on which they should be, 
depending on how things are set up, but it'll be one or the other.

> access to the 'net across their network. Hence, they are a transit AS.

That depends.  If the state gov't is the sole transit for all those 
departments, one could make the case that they -- and all the departments --  
should be a single leaf AS.  If, as is often the case, the departments also 
get independent connections from private parties, then the state network 
would be a transit AS and the departments would be leaf ASes.

Ditto for your amusement park example.

That the amusement park or state govt has its own servers and clients 
terminating traffic does not change things; hosts can live in a transit AS. 
The defining characteristic is whether the AS's address space appears in the 
DFZ individually: if so, it's a transit AS; if not, and it needs to use an 
EID-to-RLOC mapping, where the RLOCs are from some other AS's address space, 
then it's a leaf AS.

S

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Dec 2007 15:03:37 +1300

On 2007-12-02 02:24, Russ White wrote:
<snip>

> table size if you go in that direction).

Er, yes, there's a reason that the IPv6 design assumes provider-based
aggregation of prefixes, and multiple prefixes if you have multiple
providers. The PI heresy is an import from IPv4 thinking. But if
that heresy sweeps the world, we're going to need LISP style
mapping to exorcise it from the core. I think that's how we got here.

     Brian

---

From: Scott Brim <[email-masked]>
Date: Mon, 3 Dec 2007 06:05:50 -0800

Excerpts from Stephen Sprunk at 03:08:24 -0600 on Sun 2 Dec 2007:
> >> space which was divided into RLOCs and EIDs.  For instance,
> >> there's been mention of using IPv6 for EIDs and IPv4 for RLOCs,
> >> which has some interesting properties.
> >
> > I am concerned about totally decoupling the addressing domains,
> > and allowing reuse of addresses, for two reasons.  First,
> > operations: I think it would be confusing to operators to always
> > have to provide context when talking about "240.1.2.3".  Second,
> > it might be useful to allow end nodes to send packets directly to
> > globally routed addresses in the DFZ domain.  On both of these, we
> > don't know yet if it's going to be a problem, so let's put off
> > reusing addresses for a while.
> 
> I don't understand how a solution could be incrementally deployable
> unless both the EID space and the RLOC space were distinct parts of
> our existing address space.  They can't overlap as long as there's a
> single legacy site left, which means forever in practice.

I think that sounds right.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 2 Dec 2007 21:22:03 -0800

On 30 nov 2007, at 11:00, Stephen Sprunk wrote:

> LISP-mapped EIDs and deprecating PI space in 2000::/3.  It's a bit  
> tougher to apply the same split to v4 since there won't be any /8s  
> left by the time a solution is standardized...

Hm, if that's true, does it make sense to even bother working on all  
of this for IPv4?

But you could use IPv6 for locator space even for IPv4 end-user PI  
space...

And reclaiming 240.0.0.0/4 for use as locator addresses within ISP  
networks seems possible for at least some values of "possible".

However, I disagree that it's necessary or even useful to make a  
syntactical distinction between existing PI space, the new type of PI  
space and locator space. Anything that's in the BGP tables is either  
existing PI space or locator space. Which of the two isn't terribly  
interesing. Anything that's not in the BGP tables is either unused or  
new PI space so it can safely be routed to an encapsulation device.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Dec 2007 09:38:19 -0800

> Hm, if that's true, does it make sense to even bother working on all

Indeed. There simply isn't space to do this.

> But you could use IPv6 for locator space even for IPv4 end-user PI

Right.

> networks seems possible for at least some values of "possible".

Mumble. I doubt this. First of all, this a small amount of space.
Secondly, all routers in the path would have to support 240/4 address
spaces and not drop the packets.

> new PI space so it can safely be routed to an encapsulation device.
The crux of the issue is whether there's any form of pushback for users
and organizations to insert their identifier space into the global
tables. If there is none, and there is no incentive that makes users
avoid that, the chances are that no amount of additional protocols will
actually solve the fundamental problems we have today.

(In any case, one syntactical difference is IPv6 vs. IPv4. If your
identifiers come from IPv6 space, they cannot be inserted to the IPv4
tables...)

Jari

---

From: Russ White <[email-masked]>
Date: Mon, 03 Dec 2007 18:56:18 -0500

> I disagree; transit and leaf are fundamentally mutually exclusive. 
> Either your AS provides transit to the DFZ for another AS or it doesn't.

So, your definition is that as long as you transit anything, you are a
transit AS. If you do not, you are a leaf. It doesn't matter if you
originate traffic, or you sink traffic, the only thing that matters is
that you transit traffic.

In this case, I posit this is a distinction without a difference. All
AS' should be assumed to be transit in all cases.

> (i.e. DFZ) shouldn't grow in proportion.

As long as you assume that the transit AS never has any reason to
engineer traffic towards the various actual destinations reachable
through a given locator, or that the peering AS never wants to split
their locator space into multiple pieces to accomplish TE.

IMHO, the end result will be that the locator space will be split to the
same degree the current routing table is, over time, and hence, the
locator table will be the same size, in the end, as the current routing
table--because:

1. The cost of adding another locator to provide traffic engineering is
low (to the person injecting it into the table).

2. Splitting locator blocks into smaller pieces to control inbound
traffic flow into your network adds value.

So, the value proposition is the same as with the current routing
table--you incur little cost, and you do gain something, by making the
locator table larger. If the value proposition is the same, the result
will be the same, IMHO.

> For instance, if I (as a leaf AS) have five ISPs, there will be exactly
> five routes to my five locators -- the aggregates from those ISPs. 
> However, I could have potentially thousands of EIDs, each mapped
> individually to a random selection of those locators in a way that
> couldn't be aggregated.

There will a route per destination you want to steer traffic to, not 5.
You could assume 5 if you could assume the mapping system converged
instantly, and if you could assume the transit upstream did not want to
steer traffic to specific entry points based on the exit point from
their network. I don't think these two are true, myself--the mapping
system's convergence speed will not be instantaneous, and traffic
engineering, will, in the end, trump the clean mapping implied.

Further, I think mobility throws another wrench into the works that
hasn't been addressed.

> This is the problem the DFZ sees today, yes, and the goal is to get all
> of that junk out of the routing (locator) tables.  It's natural to
> assume all that junk will then inhabit the mapping tables -- and
> probably multiply like rabbits.  That means we've traded one problem for
> another, but we seem to be operating on the assumption that a mapping
> table is easier to scale than a routing table.

We're assuming:

1. A large mapping table is easier to deal with. Well, it is for the
routing system, because the tables are outside the routing system. :-)

2. There are no drivers pushing the locator table size larger, and there
is no conceivable driver for the locator table size growing to the point
of the current routing table, or larger.

3. Splitting "transits" from "leaves" is going to be clean enough--and
the number of transits will always be a small enough ratio of the entire
set of attached networks--to provide a huge gain in table sizes just by
splitting these two categories apart.

Anyway, I'm not certain we're being productive--the conversation is
wandering into specific solutions, which is what I really wanted to
avoid. I'm having a hard time accepting the underlying assumptions--I
was hoping to get some data or some reasoning that proves or validates
the two assumptions above.

IMHO, there are drivers which will push the locator table size larger,
at least to the same size as the current table. IMHO, we are also going
to wind up, as the meshiness increases, with a much larger set of the
attached networks acting as transits.

:-)

Russ

---

From: Robin Whittle <[email-masked]>
Date: Tue, 04 Dec 2007 11:52:43 +1100

I am replying to Scott, Iljitsch and Jari.

The MAB, UAB and micronet terminology I use here is discussed in:
  http://psg.com/lists/rrg/2007/msg00533.html
  http://psg.com/lists/rrg/2007/msg00535.html

Scott Brim wrote:

> While core routing/forwarding is untouched by granularity, there
>  will be more prefix mappings in ITRs.  There are several things
>  that mitigate that.  First, if there is any "pull" at all in the
>  mapping system, an ITR only has mappings it uses, so small sites
>  that only connect to a few places can have small ITRs.  Second, 
> an ITR need not cache everything if there is a mapping node 
> nearby that will do the caching for it.  Third ... well, I just 
> woke up with melatonin in my brain, so it isn't quite working 
> 100% yet, but there are mitigation techniques in all the various 
> schemes.

Another mitigation technique is a full database (push) ITR reducing
the cost of handling every mapping update in the world by updating
its RIB with only those updates which are required by the current
traffic.  This is towards the end of my message:

  Re: [RRG] Thoughts on the RRG/Routing Space Problem
            - millions of micronets
  http://psg.com/lists/rrg/2007/msg00684.html

Iljitsch wrote:

> However, I disagree that it's necessary or even useful to make
> a syntactical distinction between existing PI space, the new
> type of PI space and locator space. Anything that's in the BGP
> tables is either existing PI space or locator space. Which of
> the two isn't terribly interesing. Anything that's not in the
> BGP tables is either unused or new PI space so it can safely
> be routed to an encapsulation device.

I agree.  I think there's no need to distinguish between the use of
address space, or between types of BGP advertisement, based on
whether the space is used in a conventional manner or as an MAB.

A MAB is advertised by many ITRs - I think "anycast" is an
appropriate term for this:

   http://psg.com/lists/rrg/2007/msg00683.html

But that doesn't require any new distinction beyond the fact that
there would be some list or database in the ITR-ETR system listing
all the MABs.  It is possible to make the system work with a single
ITR advertising the MAB in the DFZ - but it is more efficient in
terms of load spreading and optimal path lengths to have two or more
likely thousands, of ITRs advertising it.

Responding to Iljitsch, Jari Arkko wrote:

> The crux of the issue is whether there's any form of pushback for
> users and organizations to insert their identifier space into
> the global tables. If there is none, and there is no incentive
> that makes users avoid that, the chances are that no amount of 
> additional protocols will actually solve the fundamental problems
> we have today.

By "identifier space" I assume you mean the space which includes
host addresses, with this being either traditional BGP-managed PI
space - or the new kind of ITR-ETR managed "micronet" space, which
does not involve any new route being advertised in the global (BGP)
tables.

A form of pushback would be that the traditional PI space winds up
being significantly more expensive for many end-users than the new
type of ITR-ETR managed "micronet" address space.

The idea with Ivip is that each Mapped Address Block (MAB) - which
requires a BGP advertisement - covers the micronets of many
end-users.  As long as this is the case, the system is greatly
reducing the number of BGP advertisements compared to what would
happen without such a system.

The same is true of LISP Proxy Tunnel Routers:

  http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt

  5.1.  PTR EID announcements

     A critical characteristic of PTR functionality is to
     advertise aggressively aggregated EID-prefixes.

I think this means the same thing - as long as there are lots of
micronets (EIDs) in the MAB (prefix handled by PTRs), then the
overall goal of reducing BGP advertisements is achieved.

Although I think there needs to be a charge for every change in a
micronet's mapping, as I discussed in the above-mentioned message, I
think that having a micronet - or a UAB (User Address Block) within
the MAB which each end-user can split into micronets as they wish -
will be a lot cheaper than having a PI prefix today.

The end-user only needs to gain their address space with whoever
administers the MAB.  So the end-user doesn't need to known anything
about advertising BGP prefixes and they don't need to deal with an
RIR, unless the MAB is run by an RIR.

Assuming the address space managed by the ITR-ETR scheme doesn't
suck (in terms of path length, packet losses, PMTUD problems etc.)
and that there are lots of end-users who are happy with:

1 - Either less than 256 addresses (I am assuming IPv4) - which is
    bound to cost less than a PI /24 - or more addresses, but they
    are happier with ITR-ETR managed micronet space than ordinary
    PI space, because it still winds up cheaper.

and

2 - They don't need the space to run ETRs or a few other things
    which ITR-ETR-mapped address space is unsuitable for.

then I would expect this to result in "pushback" against them
getting ordinary PI space.  In addition to the new type of address
space being less expensive, there will be other advantages, or at
least not disadvantages:

1 - The new ITR-ETR managed micronet space will be as portable
    as ordinary BGP managed PI space - as long as the ISPs run ETRs.

2 - Depending on the characteristics of the ITR-ETR scheme, this new
    type of address space may have superior performance to ordinary
    BGP managed PI space in terms of flexibility, speed and
    reliability of TE and multihoming service restoration.

Furthermore, at the RIR level, micronets will enable a much more
efficient use of address space, in terms of the number of end-user
networks served per large address block - since each end-user can be
given whatever space they need without the usual 256 IP address
granularity of the current BGP system.

So RIRs might want to encourage the use of micronet space by lower
fees and/or making space more available to ISPs (or whoever) is
running the MABs.

All this should result in "pushback" - traditional PI space being
less attractive and/or more expensive than micronets - for a large
number of end-users.

 - Robin

---

From: Scott Brim <[email-masked]>
Date: Mon, 3 Dec 2007 16:59:50 -0800

Excerpts from Russ White on Mon, Dec 03, 2007 06:56:18PM -0500:
> So, your definition is that as long as you transit anything, you are
> a transit AS. If you do not, you are a leaf. It doesn't matter if
> you originate traffic, or you sink traffic, the only thing that
> matters is that you transit traffic.
> 
> In this case, I posit this is a distinction without a difference.
> All AS' should be assumed to be transit in all cases.

Different aspects matter in different contexts.  For IP routing, I
believe the main question is whether you are DFZ or not.  

> > No.  The mapping table may get disturbingly large, but the locator
> > table (i.e. DFZ) shouldn't grow in proportion.
> 
> IMHO, the end result will be that the locator space will be split to
> the same degree the current routing table is, over time, and hence,
> the locator table will be the same size, in the end, as the current
> routing table--because:
> 
> 1. The cost of adding another locator to provide traffic engineering
> is low (to the person injecting it into the table).
> 
> table--you incur little cost, and you do gain something, by making
> the locator table larger. If the value proposition is the same, the
> result will be the same, IMHO.

First, what locator table?  

In case you mean routing of globally routed addresses in the DFZ, in a
map&encaps scheme the routing information will only grow based on the
number of DFZ ASs and their policies on routing within the DFZ,
because RLOCs are assigned by upstream providers, and will aggregate.
Addresses of ETRs are just addresses in their upstream providers.  In
DFZ routing, policies can only be applied to the upstream providers,
not to things outside the global DFZ.  Policies on non-routed sites
will be applied in the mapping function (data plane and control
plane).

When you say "locator table" I think you mean the locally routed
"EIDs", and thus an EIDprefix->GlobalLocator mapping table (or
database).  In that case, let's not forget that some approaches don't
have anything resembling a mapping table or database, but are
completely distributed.  For them there is no problem of mapping table
size.  

Then there's the cache of prefix maps in an ITR.  There would be a
problem for an ITR that wanted to send traffic to every prefix,
because it would have to cache many prefix mappings.  There are a
number of deployment heuristics we can both think of to avoid that
problem.

> > For instance, if I (as a leaf AS) have five ISPs, there will be
> > exactly five routes to my five locators -- the aggregates from
> > those ISPs.  However, I could have potentially thousands of EIDs,
> > each mapped individually to a random selection of those locators
> > in a way that couldn't be aggregated.
> 
> There will a route per destination you want to steer traffic to, not
> 5.  You could assume 5 if you could assume the mapping system
> converged instantly, and if you could assume the transit upstream
> did not want to steer traffic to specific entry points based on the
> exit point from their network. I don't think these two are true,
> myself--the mapping system's convergence speed will not be
> instantaneous, and traffic engineering, will, in the end, trump the
> clean mapping implied.

I don't understand this.  I thought the question is how much routing
information there will be in the global routing DFZ.  Behavior there
will be like BGP today.  In map&encap, traffic from ITR to ETR will
follow paths that BGP hunts out, just like today.  Yes, destination
sites will want to steer traffic to specific exit points (ETRs), and
they will do so in the mapping function.  Every ingress point (ITR)
might be asked to send traffic to a different exit point.  DFZ routing
won't care.  It will just carry routes to the ISPs that provide those
exit points.  

> Further, I think mobility throws another wrench into the works that

In map&encap, if you implement the optimized routing ideas in MIPv6,
then every time a mobile node moves to a site it has never been in
before, there is a *chance* that several mapping lookups may be
necessary.  This is true of any approach that restricts the scope of
end site prefix routing.  However, 

  - Routing and addressing are more fundamental than mobility.
    Mobility can adapt to R&A but not vice versa.  R&A need to take
    mobility into account as a general issue, but we have always lost
    when we tuned fundamental designs to specific mechanisms that ran
    over them, and we have always won by producing general purpose,
    flexible designs.  So we should take mobility into account but
    clean elegance in routing and addressing is of primary importance.  

  - In the real world mobile users are rather provider-aggregated, and
    even if we use the currently conceived route optimization
    mechanisms, the need for new map lookups will be less than one
    would think.

  - Route optimization has not, or hardly, been deployed in MIPv4 or
    MIPv6.  It is a theoretical requirement that I applaud, but it is
    not a hard requirement that we support it.

So MIP will be interesting, but not a hard obstacle.  We put a little
text in the last draft-farinacci-lisp draft about it.  Once we have a
better idea of where we are going in RRG, we can do a full draft about
interactions with mobility.

> routing system, because the tables are outside the routing system.

Do you mean that it's hard for ITRs?  If so, see above.

> IMHO, there are drivers which will push the locator table size
> larger, at least to the same size as the current table. IMHO, we are
> also going to wind up, as the meshiness increases, with a much
> larger set of the attached networks acting as transits.

Just because an ISP is multiply-connected doesn't mean it's a transit.

See you ... Scott (in SIDR)

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Dec 2007 17:59:17 -0800

Robin,

> does not involve any new route being advertised in the global (BGP)

Yes.

> type of ITR-ETR managed "micronet" address space.

Hmm. I think your argument is the wrong way around. It would of course
be great if we had new space that was significantly easier to get than
the current address space, and which would also be cheap.

But this would be appealing mostly for new entities that have not
contributed to the current bloat in the system so far. For instance, I
would personally be interested in that sort of an address space.

I'm not sure it would affect the current growth in the routing table
much. Lets review some of the basic characteristics of the situation:

- Getting PI space is possible.

- The cost of acquiring such space is negligible for organizations that
would be in a position to employ it; far, far lower than the cost of
equipment, for instance.

- Employing the new space instead of regular PI would imply getting some
new technology.

- The organization is capable of fulfilling its need with the existing
technology as well.

- The organization does not bear the costs caused to the rest of the
Internet by the injection of global routes.

Given these, I find it unlikely that the availability of even lower cost
address space would somehow affect the decisions that the organization
takes.

Jari

---

From: Tony Li <[email-masked]>
Date: Mon, 3 Dec 2007 19:09:52 -0800

Jari,

> would be in a position to employ it; far, far lower than the cost of

True, but it's decidedly non-zero.  To get PI, one currently has to  
spend time to justify the allocation.  This takes effort (i.e.,  
money).  If we have an architecture in which being multi-homed is no  
longer a sufficient justification for PI allocation, then we can  
further raise this bar.

Effectively, we should be able to drastically limit or even eliminate  
PI allocations.  Yes, I'm talking about making fundamental changes to  
the allocation policies that we have today.

> - The organization is capable of fulfilling its need with the existing

Hopefully, the existing technology (PI addressing) will become harder  
to acquire.

> address space would somehow affect the decisions that the organization

We have to be taking the decision out of the hands of the  
organization and giving them a workable alternative.  If not, then  
everyone will simply continue to use PI addressing and the non- 
scalability of the 'net is assured.

Tony

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Dec 2007 19:21:36 -0800

Tony,

> Hopefully, the existing technology (PI addressing) will become harder

Right -- and this would be very good.

All I'm saying is that technology alone may not solve our problems.
Policy changes, incentive changes, business model changes may be a part
of the solution. A couple of comments about such changes, however:

- Some changes might by themselves cause the desired change and do not
require any supporting technology change. This is not the case here,
however, because you cannot take away PI without giving something else
in its place.

- In a world that does not transition to a new system overnight, you may
have to be careful about raising the bar too fast -- you still want the
people with old technology to be able to do what they need to do.

Jari

---

From: Robin Whittle <[email-masked]>
Date: Tue, 04 Dec 2007 14:46:12 +1100

Hi Jari,

I hadn't considered the cost of equipment.  I figure the ITRs are
paid for, in general, by the ISPs where they are located - tunneling
packets originating from the ISP's customers' hosts.

For an end-user who gains some of the new kind of address space
provided by the ITR-ETR (AKA map&encap) system, the ETR(s) their
traffic flows through would be owned and operated by the ISP(s)
which they connect to the net with.  ETRs are going to be pretty
simple compared to ITRs - they don't need an FIB, a database or a
feed of mapping data (or access to a query server, if they are
caching ITRs).

So the end-user doesn't need to purchase or run ITRs or ETRs in
order to use the new kind of address space.

Their network may well include ITRs - to ensure the tunneling work
on outgoing packets is done locally and doesn't depend on anything
upstream, which is shared by others.  But that would be the case
irrespective of whether the end-user's network uses the new kind of
address space.

It may well be that the new "micronet" type of address space doesn't
cause many of the recent (say 5 years) new end-user networks with PI
space to relinquish that space and use micronet space instead.

In addition to these, hundred thousand or so "large" end-users there
is surely a huge number (millions) of "smaller"  end-users who want,
arguably need, and are keen to pay for multihoming (and in many
cases portability of addresses in the long-term between ISPs) - but
who don't have the resources or sufficient "justification" to get PI
space today.  These end-users are unhappy and not able to use the
Net as reliably as they need.

Without the ITR-ETR scheme, these millions of smaller end-users
generally have to do without multihoming, because they can't afford
the entry costs, in terms of equipment (maybe), expertise (probably)
and effort required to get PI space and to responsibly participate
in the global BGP system.  The current rate of growth in the number
of advertised prefixes would continue - which is not what we want.

With a good ITR-ETR scheme, some of the current "larger" type of
end-users - those currently with PI space and those who would
otherwise get it - would switch over to the new scheme.

The major impact of the ITR-ETR scheme would be on the millions of
"smaller" end-users, who would jump into micronet spaces and (with
suitable economic incentives = costs) fine-tune the amount of
address space they use and the number of micronets and mapping
changes they make, so that the space is used efficiently and without
excessive burden on the ITR system.

The other thing is that, over time, as the number of PI prefixes and
the changes to their advertisements becomes more and more of a pain,
I think there is likely to be some kind of pressure to limit the
number of end-user networks who use this.

Now, the only way of doing this is to tell the end-user they can't
multihome.  But with a good ITR-ETR / map&encap scheme, they will
have a perfectly good alternative.

So I think there will be this additional form of pushback not long
after the ITR-ETR scheme is up and running.

As Tony wrote:

> If we have an architecture in which being multi-homed is no
> longer a sufficient justification for PI allocation, then we
> can further raise this bar.
>
> Effectively, we should be able to drastically limit or even
> eliminate PI allocations.  Yes, I'm talking about making
> fundamental changes to the allocation policies that we have today.
>
> everyone ...

Not "everyone" in terms of all the "small" end-users, but certainly
enough end-users of various generally moderate to large sizes.

> will simply continue to use PI addressing and the non-scalability
> of the 'net is assured.

Yes - the future of the Net depends on there being a good ITR-ETR /
map&encap scheme ASAP.  I think the timetable for the RRG is
realistic - not too fast, but we to devise something which can be
deployed around 2011 and widely adopted by 2013.

I think that there won't be much trouble with ISPs providing ETRs.
They shouldn't cost much - they will probably be implemented as
software updates to existing routers.  A software only system for
standard Intel etc. PC-like servers would probably work well in some
settings, assuming it could be robust enough.

I think ITRs are going to be quite tricky. There could be software
updates for existing routers, and some low to moderate volume
software only systems which run on standard servers - and sit next
to a currently installed router, advertising the prefix on IGP or BGP.

Then there is the global query or push network - which is where the
various ITR-ETR schemes differ the most.  This will be challenging too.

As long as there is a reasonably wide distribution of ITRs, enough
to handle the traffic without too much stretch of the path lengths,
then I think ETRs will be installed at many ISPs and the new
micronet style of address space will be rapidly adopted.  Initially
most of it would go to the pent-up demand of the many "small"
end-users who currently can't play the "RIR PI BGP justify /24 or
more" game.

Those who manage the MABs will presumably rent out the space as UABs
(User Address Blocks) to end-users, charging according to the number
of addresses in each UAB, the number of micronets the end-user
configures this space into and the rate of mapping updates.

I figure such MAB operators will probably be able to make money
while financing their own global network of ITRs or participating in
a shared, global system.  Alternatively, they would pay one or more
other ITR operating organisations to run ITRs all over the Net,
catching packets from networks with no ITRs, so their address space
was useful and therefore highly rentable.

  - Robin

---

From: Scott Brim <[email-masked]>
Date: Tue, 4 Dec 2007 06:01:09 -0800

>   http://psg.com/lists/rrg/2007/msg00535.html

iirc a MAB is an aggregate of addresses that are not globally routed,
a "micronet" is a chunk of addresses within that, which need not be on
a power-of-2 boundary, and a UAB is somewhere in the middle.  For MAB,
I think it's just as easy to say what you mean.  For "UAB" and
"micronet", we have tried non-power-of-2 alignment in the past and it
has been a big problem.  We ended up with CIDR on power-of-2
boundaries for a good reason.  The term for a chunk of addresses
aligned on a power-of-2 boundary is a prefix.  We've been using this
for over 20 years.  Finally, the labels "M" and "U" unnecessarily
assume a simple two-tier system.  So just use "prefix".  It's
established, it's easier, it's more general purpose where we need it
to be and more specific where we need it to be.

> traffic.  

So the full database is pushed to start with, and incremental updates
follow based on observed traffic?  To start with, we should assume at
least hundreds of millions of prefix mappings.  Second, regarding the
incremental updates, how is the incremental update triggered?  Does
the ITR ask for an update when it notices it is sending packets to a
prefix for which it has a stale mapping entry?  If so, how is this
different from an LRU cache?  Does some upstream router notice, and
tell the mapping system to push an update?  If so, why bother when the
ITR itself knows best what it needs?

> appropriate term for this:

The appropriate term is "routing" :-).  Common use of anycast
overwhelmingly refers to routing and forwarding to an endpoint.

> all the MABs.  

This is not required either.

swb

---

From: Scott Brim <[email-masked]>
Date: Tue, 4 Dec 2007 06:03:31 -0800

Excerpts from Tony Li on Mon, Dec 03, 2007 07:09:52PM -0800:
> everyone will simply continue to use PI addressing and the
> non-scalability of the 'net is assured.

If PI addresses are only available if you use the new technology
(which takes them out of global routing) ... ?

---

From: Russ White <[email-masked]>
Date: Tue, 04 Dec 2007 18:21:44 -0500

> believe the main question is whether you are DFZ or not.  

I *believe* the number of default only AS' is going to reduce in size
over time, for various reasons.... Hence, my basic thinking that all AS'
should be treated as transit, or rather, any solution should be designed
with a zero size "default only" zone, if you will.

> First, what locator table?  

The "global routing table."

> because RLOCs are assigned by upstream providers, and will aggregate.

What is the business reason for aggregating locators into your peers,
rather than advertising more specifics? I believe this will be a strong
business case to deaggegrate, but I don't see any real reason to
aggregate. De-aggregation doesn't cost anything, and you can gain
through it, so the economics are the same as those in operation in the
global routing table.

> will be applied in the mapping function (data plane and control

Policy can only be applied to the longest prefix representation of the
locator space--in other words, you can only apply policy to the groups
of locators you actually advertise. As you aggregate the locator space,
you can apply policy, including traffic engineering policy, to larger
groups of exit points (seen from your network point of view). There's a
strong incentive to advertise finer grained locator information, to
control the flow of traffic through the transit AS. There is no
corresponding driver to aggregate this information.

> number of deployment heuristics we can both think of to avoid that

Caches, IMHO, will not work. Caching information is based on specific
traffic patterns that are going to probably change, dramatically, in the
near future--it's never good to presume existing traffic patterns are
permanent, and we can thus build an architecture based on those existing
traffic patterns. Second, any form of reactive routing, which is what
caches, in the end, represent, is going to have unacceptable side
effects in terms of traffic delays, technical difficulties, etc.

> will be like BGP today.  

There are two tables, and the question is--how much state*churn will we
have in both of those tables? IMHO, the state*churn in the DFZ routing
table, the "locator" table, will be similar to what's there today, if
not possibly worse. The state in the "mapping" table will be unbounded,
probably many times larger than the current table size.

> In map&encap, traffic from ITR to ETR will

This assumes that the end destination traffic can always be treated as a
single class, or a single monolithic block of traffic--or rather, all
destinations within a given "leaf" AS can always be treated as a single
destination. IMHO, this is not a good assumption, as shown by current
trends.

In the same way, this also assumes that all the locators within a given
transit AS can always be treated as a single destination from outside
that AS. Again, IMHO, this is not a good assumption.

>     Mobility can adapt to R&A but not vice versa.

In other words, mobility is a secondary requirement for IP transport.
Either it is a small part of the traffic, and will not grow, so there is
no need to address it (?).... Or, it's not a problem that needs to be
addressed through routing, it should be handled elsewhere. IE, IP == POTS.

That "stuff" folks are running over our transport are fine, just solve
your own problems, and don't ask me to do it for you. IMHO, this is
shortsighted.

>     mechanisms, the need for new map lookups will be less than one

Today. Again, I believe it's wrong to base an architecture on today's
traffic patterns. Part of the job of the IETF isn't to solve today's
problems, it's to solve tomorrow's problems in a way that doesn't impact
today's services.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Tue, 04 Dec 2007 18:26:01 -0500

> True, but it's decidedly non-zero.  

Certainly the cost of getting PI space is non-zero, but that's not the
critical cost. The cost to get PI IPv4 space is no-zero, as well--and
yet, that hasn't solved the "table size" problem.

The cost of getting space isn't, I don't think, the problem. IMHO, the
cost of deaggregating that space is zero. And I don't see anyplace where
the cost of deaggregating increases, hence, I don't see anything to stop
the current trend for larger table sizes.

Splitting the table into smaller pieces might make the problem go away
for a short period of time, but it will only prove to be a drop in the
bucket against the tide driving more granularity (state) into the network.

:-)

Russ

---

From: Tony Li <[email-masked]>
Date: Tue, 4 Dec 2007 15:50:52 -0800

On Dec 4, 2007, at 3:26 PM, Russ White wrote:

> IMHO, the

To be more precise, the cost of de-aggregating space is zero to the  
entity doing the deaggregation.  The cost is transferred to all ASes  
carrying the more specifics.  Otherwise, we agree.

Tony

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 4 Dec 2007 19:39:19 -0600

Thus spake "Robin Whittle" <[email-masked]>
> packets originating from the ISP's customers' hosts.

That's one option.  See below for my take.

> For an end-user who gains some of the new kind of address
> space provided by the ITR-ETR (AKA map&encap) system, the
> ETR(s) their traffic flows through would be owned and operated
> by the ISP(s) which they connect to the net with.  ETRs are going
> to be pretty simple compared to ITRs - they don't need an FIB, a
> database or a feed of mapping data (or access to a query
> server, if they are caching ITRs).

Now that's interesting...  ISPs seemingly have little motivation to operate 
ETRs because they defeat customer lock-in.

I'd rather run my own ETR(s).  Since it's a brain-dead simple function, I 
expect to see that make its way into even the cheapest CPE.  Ideally, I'd 
set my ETR(s) up with RLOCs from each upstream ISP (perhaps obtained via PPP 
or DHCP), set the mappings in the database, and be ready to rock.  My ISPs 
wouldn't necessarily even realize I was using one.

> irrespective of whether the end-user's network uses the new kind of

We need some way to make sure that either (a) every default-free entity 
(including, but not limited to, ISPs) runs an ITR, or (b) there are EID 
aggregates in the DFZ (most likely anycasted, but perhaps not).  The latter 
seems more achievable, but the question is who pays to install and run them. 
The most logical answer answer is "whoever issues EID space", which for the 
sake of argument let's call the RIRs.  However, those "ITRs of last resort" 
are going to be overwhelmed if map&encap is even moderately successful, and 
ISPs would be motivated to provide their own (presumably closer and more 
robust) ITRs to improve performance and keep customers happy.

Customers running caching ITRs may happen, but I'm doubtful we'll see 
full-database ITRs at many customer sites.  The largest may get the latter, 
but it's too much to ask for Linksys et al to put that in $50 consumer 
boxes; even a caching ITR may be too much complexity.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 4 Dec 2007 20:22:24 -0600

> [ I said: ]

Correct.

> AS' should be assumed to be transit in all cases.

That assumption is clearly incorrect.  As of last week, 87% of all ASes 
visible in the DFZ are origin-only.  There are tens of thousands of medium 
and large leaf ASes _not_ visible in the DFZ because they don't need ASNs, 
either because they have a upstream (transit) AS(es) announce for them or 
they're stuck on PA space.  There are hundreds of millions of small leaf 
ASes, like my house, that can't get BGP from their upstreams, period, but 
might want EIDs so they can multihome over their DSL/cable/wireless lines.

>>> Doesn't this increase the size of the Locator table, over time,
>>> to be precisely the size of the EID table?
>>

Granted.

Things are looking slightly rosier in v6 because the vast majority of 
transit ASes will have a /32, and current expectations are that all ISPs 
will filter at that boundary.  Even if some do not, perhaps because they are 
okay with deaggregates, everyone should also announce the covering aggregate 
as well because _someone_ will be filtering.  That allows ISPs to tune their 
filters based on how comfortable they are with the resulting table size.

Of course, such filtering has been tried with v4, but due to the large 
differences in allocation size and certain "important" sites not announcing 
covering aggregates, it's been discarded.  As the table passes 250k, it may 
be making a comeback, but it'll be ugly.

> locator table will be the same size, in the end, as the current routing
...
> locator table larger. If the value proposition is the same, the result

Indeed, that's probably what will happen; there doesn't seem to be any 
applicability of our present proposals to solving that, though.  At most, 
we'll be removing the leaf routes from the table, but there are analyses 
that show they could be fully half of the current routes (mostly legacy 
/24s).  Worst case, that just makes room for more locator deaggregation...

> attached networks acting as transits.

While the total number of visible ASes is going up, the number of 
origin-only ASes is growing faster than the number of transit ASes (i.e. the 
percentage of the former is _growing_).  This is due to the increasing 
number of leaf ASes (e.g. large corporations) that are starting to visibly 
multihome, which is happening significantly faster than new transit ASes 
(e.g. ISPs) are being created.

S

---

From: Russ White <[email-masked]>
Date: Wed, 05 Dec 2007 21:20:24 -0500

> will filter at that boundary.  Even if some do not, perhaps because they
> are okay with deaggregates, everyone should also announce the covering
> aggregate as well because _someone_ will be filtering.  That allows ISPs
> to tune their filters based on how comfortable they are with the
> resulting table size.

In other words, although you might want to traffic engineer to a finer
granularity, it doesn't matter, because you will be filtered. Since you
state this isn't acceptable in IPv4, I don't think it will be in IPv6,
in the long run.

> applicability of our present proposals to solving that, though.  

Which implies the current set of proposals are possibly not a complete
solution (?). Perhaps the "right" answer is that no single solution is
going to address three different economic drives, especially with the
people holding the money card are, somewhat, at odds with one another.
Maybe the entire problem needs to be split into smaller pieces.

> origin-only ASes is growing faster than the number of transit ASes (i.e.
> the percentage of the former is _growing_).  

Right now. IMHO, these proposals on the table will bring a lot of
"transit AS'" which currently aren't out onto the table.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Wed, 05 Dec 2007 21:20:24 -0500

:-)

Russ

- --

---

From: Scott Brim <[email-masked]>
Date: Wed, 5 Dec 2007 19:12:30 -0800

Excerpts from Stephen Sprunk on Tue, Dec 04, 2007 07:39:19PM -0600:
> Now that's interesting...  ISPs seemingly have little motivation to
> operate ETRs because they defeat customer lock-in.

First, if a customer is numbered out of a prefix allocated to an ISP,
it can't just up and move its sub-prefix arbitrarily, with or without
an ETR.  So I don't think what you say is true.  Second, it can be the
other way around (idea from Eliot).  If an ISP offers a customer the
chance to connect via an ETR, then the customer can multihome without
having to negotiate about injecting a longer prefix.

> set my ETR(s) up with RLOCs from each upstream ISP (perhaps obtained via 
> PPP or DHCP), set the mappings in the database, and be ready to rock.  My 
> ISPs wouldn't necessarily even realize I was using one.

Me too.

> aggregates in the DFZ (most likely anycasted, but perhaps not).  

Do you mean "EID aggregator", like a proxy tunnel router?

> However, those "ITRs of last 
> resort" are going to be overwhelmed if map&encap is even moderately 
> successful, and ISPs would be motivated to provide their own (presumably 
> closer and more robust) ITRs to improve performance and keep customers 
> happy.

As for being overwhelmed, a particular "DFZ ITR" (PTR) need not handle
the entire EID address domain.  How to split things up, and where to
place them, should depend on real operation considerations.

> Customers running caching ITRs may happen, but I'm doubtful we'll
> see full-database ITRs at many customer sites.  The largest may get
> the latter, but it's too much to ask for Linksys et al to put that
> in $50 consumer boxes; even a caching ITR may be too much
> complexity.

Very very very few houses would need a full cache.

swb

---

From: Scott Brim <[email-masked]>
Date: Thu, 6 Dec 2007 18:06:57 -0800

Excerpts from Russ White on Tue, Dec 04, 2007 06:21:44PM -0500:
> I *believe* the number of default only AS' is going to reduce in
> size over time, for various reasons.... Hence, my basic thinking
> that all AS' should be treated as transit, or rather, any solution
> should be designed with a zero size "default only" zone, if you
> will.

I don't understand why you would think that.  If that were the case,
why hasn't it happened already?  Specifically what do you think is
about to change?

> The "global routing table."

OK.  Then ... 

> There's a strong incentive to advertise finer grained locator
> information, to control the flow of traffic through the transit AS. 

Could you explain why that would happen?  What strong incentive (not
just a generalization) is there that would override the incentives not
to do so, and why hasn't it already done so?

> Caches, IMHO, will not work. Caching information is based on
> specific traffic patterns that are going to probably change,
> dramatically, in the near future--it's never good to presume
> existing traffic patterns are permanent, and we can thus build an
> architecture based on those existing traffic patterns. Second, any
> form of reactive routing, which is what caches, in the end,
> represent, is going to have unacceptable side effects in terms of
> traffic delays, technical difficulties, etc.

Why do you think anyone was talking about caching based on current
behavior?

When you say caching "represents" "reactive routing", I suspect you
are talking about the balancing act between delay, packet drops,
security and FIB size.  There is a lot of text about this in the
drafts and on the mailing list.  We don't know where the balance point
will come out, so what we are trying to do is to build in the
flexibility so that we *can* move network behavior to a better balance
point as the Internet evolves.  One possibility is to have no delay
(and thus no "reactive routing") in map lookup at all.

Given that, when you assert that any reactive routing is unacceptable,
what do you propose?

> There are two tables, and the question is--how much state*churn will
> we have in both of those tables? IMHO, the state*churn in the DFZ
> routing table, the "locator" table, will be similar to what's there
> today, if not possibly worse. 

You understand that all that will be in DFZ routing will be the DFZ
networks themselves, a relatively small number, is this because you
think they will advertise long prefixes to each other?  If so, see
above.  If not, please explain.

> The state in the "mapping" table will be unbounded, probably many
> times larger than the current table size.

I believe so too, although not unbounded.  However, there is not
necessarily a "table" at all.  Mapping information may not be
completely collected anywhere (except where people want to for
analysis).  There can be -- that's part of the flexibility discussed
above.

> > In map&encap, traffic from ITR to ETR will follow paths that BGP
> > hunts out, just like today.  Yes, destination sites will want to
> > steer traffic to specific exit points (ETRs), and they will do so
> > in the mapping function.  Every ingress point (ITR) might be asked
> > to send traffic to a different exit point.  DFZ routing won't
> > care.  It will just carry routes to the ISPs that provide those
> > exit points.  
> 
> This assumes that the end destination traffic can always be treated
> as a single class, or a single monolithic block of traffic--or
> rather, all destinations within a given "leaf" AS can always be
> treated as a single destination. IMHO, this is not a good
> assumption, as shown by current trends.

Are you saying there will be TE within the DFZ?  Sure.  I included
that in "routes" -- we have that today.  

Please don't tell me what I'm assuming.  If you think I might be, ask
me.

> In the same way, this also assumes that all the locators within a
> given transit AS can always be treated as a single destination from
> outside that AS. Again, IMHO, this is not a good assumption.

No it doesn't.  Ask me if you think I'm saying something wrong -- it
may be that your assumptions are off.

> In other words, mobility is a secondary requirement for IP
> transport.  Either it is a small part of the traffic, and will not
> grow, so there is no need to address it (?).... Or, it's not a
> problem that needs to be addressed through routing, it should be
> handled elsewhere. IE, IP == POTS.

I didn't say that.  You are inserting your agenda and cloaking it in
the guise of paraphrasing me.  Stop doing that.  It's no way to reach
an agreement.  Look again at the rest of what I said, about the
importance of mobility, and try again.  Maybe you could even
contribute a suggestion of how to solve the problems you think you
see.

> >   - In the real world mobile users are rather provider-aggregated,
> >     and even if we use the currently conceived route optimization
> Today. Again, I believe it's wrong to base an architecture on
> today's traffic patterns. Part of the job of the IETF isn't to solve
> today's problems, it's to solve tomorrow's problems in a way that
> doesn't impact today's services.

Nope.  This is not about network technology, it's about human behavior
and business behavior, regardless of underlying technology.  I can dig
out the studies but it will take a few days.  In the meantime, if you
have a proposal for an architecture to reach our goals ...

     1. Improved routing scalability                                                           
     2. Scalable support for traffic engineering                                               
     3. Scalable support for multi-homing                                                      
     4. Scalable support for mobility                                                          
     5. Simplified renumbering                                                                 
     6. Decoupling location and identification
     7. First-class elements                                                                   
     8. Routing quality                                                                        
     9. Routing security                                                                       
    10. Deployability    

... let us know.

swb