Subject: [RRG] Fast and sparse mapping?

From: Robin Whittle <[email-masked]>
Date: Tue, 16 Sep 2008 13:24:38 +1000

Hi Brian,

I don't understand any part of what you wrote clearly enough to
respond.  Could you be more expansive?

It seems there is a new Olympic sport of trying to discuss scalable
routing in as few words as possible.  Perhaps there could be similar
contests restricting communication to haiku, sign-language or charades.

I would prefer a more detailed initial exposition so I don't have to
write back to the list and report I wasn't able to guess the full
meaning the writer had in mind.

  - Robin

Subject: Re: [RRG] Consequences of no renumbering...

> On 2008-09-11 17:02, Tony Li wrote:
>> Hi Robin,
>>
>> |There is no scalable routing system - or transition scheme to a
>> |scalable routing system - which can meet our goals of being
>> |attractive to end-users and generating real scalability benefits
>> |if it is not allowed to require most small end-user networks
>> |(all PI and probably most small PA) to renumber once when
>> |adopting the new system.
>>
>> One word: translation.
>
> Two words: fast mapping.

Other than Ivip's essentially real-time control of ITRs by
end-users, I am not sure what "fast mapping" means.  Please explain
what you mean, with some examples.

> I missed the bit where it was proved that fast mapping
> mathematically requires aggregatable EIDs.

Who suggested this?

> As I said a couple of weeks ago:
>
> However, would a lower estimate, say 2^23 (8 million) prefixes be
> an issue?

An "issue" (meaning problem) for what?  I assume this figure is for
the number of EID prefixes (LISP and APT terminology) or micronets
(Ivip) which the mapping system supports.  Or is this a figure of
how many routes are advertised in BGP?

> If not, why can't we start on the assumption that we know how to
> support a map with 8 or 10 million entries, and have many years to
> figure out a sparse  mapping system with several orders of
> magnitude more entries?

I don't understand what "sparse mapping" means.

--
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: Tue, 16 Sep 2008 16:01:31 +1200

> what you mean, with some examples.

An EID to RLOC map that can be consulted in much less than one packet time
in an edge router.

>> mathematically requires aggregatable EIDs.

I've seen numerous references to EIDs needing to aggregate.
I'd like to know why.

> how many routes are advertised in BGP?

I'm thinking specifically of the number of EIDs to be mapped to
a significantly smaller number of RLOCs. And I'm assuming that
lookup in a table of 2^23 entries is a fast operation.

> I don't understand what "sparse mapping" means.

One where we assume that no aggregation is possible in the ID space,
i.e. the ID space is sparsely populated.

(Given the history of IP addressing, and the recent discussions
on this list, I don't know any other assumption we can make
except that IDs will look like meaningless randomly distributed
numbers.)

    Brian

---

From: Stephen Sprunk <[email-masked]>
Date: Tue, 16 Sep 2008 14:15:01 -0500

> I've seen numerous references to EIDs needing to aggregate.

It depends on what level you're discussing.  It would be advantageous if 
the entire set of possible EIDs could be aggregated, because that makes 
it easier to inject an aggregate route (or small set of routes) into the 
existing DFZ.

> i.e. the ID space is sparsely populated.

I think it's reasonable to assume that EIDs within a site will be 
commonly aggregated so that a site with a million EIDs may only need to 
consume one mapping entry rather than a million.  However, the system 
cannot require that will _always_ be the case, just optimize for it when 
it happens.  It does not help much if a site has to get 20+ EID prefixes 
so that they can have 20 different mappings...

> except that IDs will look like meaningless randomly distributed

That is the worst case: a swamp.  I don't think it'll be that bad 
overall, but there will definitely be pockets of it here and there.  How 
desirable that is, and how often it will happen, depends on whether 
creating a swamp for your own benefit results in external or internal 
costs.  Part of the problem with deaggregation in the DFZ is that the 
cost is almost entirely an externality -- I get the benefit, but every 
other operator pays.

S

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Sep 2008 10:09:46 +1200

Stephen,

> cost is almost entirely an externality -- I get the benefit, but every

I fully agree, and what I'm suggesting is that the (sad) history of
the initial success of CIDR followed by the recent backsliding which
I call "the PI heresy" shows us that economics will always tend to create
a swamp, so we'd better engineer the system for a swamp. And in a swamp,
any benefit from aggregation is both limited and unpredictable. (Would
anybody like to predict the effect of the collapse of the US financial
system on BGP4 aggregation two years from now?)

Robin argues:

> One way of improving scaling is for any of these million SPI
> networks which have adjoining address space to advertise their two
> or more UABs as a single MAB, instead of each UAB being a separate
> MAB. 

True. But that is, to use the technical term, a crap-shoot, just as
BGP aggregation of adjoining PI prefixes is a crap-shoot. It will
be the exception rather than the rule; that's the nature of a swamp.
There are no natural economic forces that provide incentives for
aggregation.

So I stick to my guns: we need to map the edge-swamp into a significantly
smaller core-swamp, or nothing will change. Relying on aggregation at
the edge hasn't worked for BGP, so why should it work for any form
of EID/RLOC mapping (regardless of terminology)?

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Thu, 18 Sep 2008 10:22:13 -0700

More catch up... 

Brian wrote:
|I fully agree, and what I'm suggesting is that the (sad) history of
|the initial success of CIDR followed by the recent backsliding which
|I call "the PI heresy" shows us that economics will always 
|tend to create
|a swamp, so we'd better engineer the system for a swamp. And 
|in a swamp,
|any benefit from aggregation is both limited and unpredictable. (Would
|anybody like to predict the effect of the collapse of the US financial
|system on BGP4 aggregation two years from now?)

Do you really mean that?  Are you really suggesting that we engineer routing
for 2^48 prefixes?  

|True. But that is, to use the technical term, a crap-shoot, just as
|BGP aggregation of adjoining PI prefixes is a crap-shoot. It will
|be the exception rather than the rule; that's the nature of a swamp.
|There are no natural economic forces that provide incentives for
|aggregation.

True.  The alternative is for us to remove the incentives to deaggregate (as
best we can) and then to restrict things so that people can't hurt the
system.

|So I stick to my guns: we need to map the edge-swamp into a 
|significantly
|smaller core-swamp, or nothing will change. Relying on aggregation at
|the edge hasn't worked for BGP, so why should it work for any form
|of EID/RLOC mapping (regardless of terminology)?

I'd argue that if there's a core swamp, you've already failed to scale.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Sep 2008 09:33:18 +1200

Tony,

> Do you really mean that?  Are you really suggesting that we engineer routing

No. I still believe that the natural limit is somewhere around 10 million
PI prefixes, or just conceivably 100 million, so my target range is
2^23 to 2^27.

> I'd argue that if there's a core swamp, you've already failed to scale.

Well, yes, I'd rather see pure PA in the core, but I fear that ship
has sailed.

    Brian

---

From: Scott Brim <[email-masked]>
Date: Fri, 19 Sep 2008 12:53:29 -0400

> PI prefixes, or just conceivably 100 million, so my target range is

How is this a 'natural limit'?  Could you review how you got there?  My
totally casual estimate is that 2^27 is reasonable but that we had
better engineer for 2^30.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Sep 2008 14:08:51 +1200

> better engineer for 2^30.

10 million is my rough estimate for the number of medium-sized and larger
businesses that would exist in a fully developed world of 10 billion
people (i.e. one such business per thousand people). 100 million
is an upper limit - one multihomed network per hundred people - at
that level even the dentist's offices are multihomed.

I don't think we need to design for a world where most domestic subscribers
are multihomed, or care in the least if they get a new IP address
each time they connect.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Sep 2008 15:52:34 +1200

Hi Marshall,

Well, if there is some number like 2^23 or 2^27 of prefixes active
in a 64-bit prefix space, and they don't aggregate, that seems sparse
in exactly the sense of a sparse matrix. I'm not suggesting this is
fundamentally different (except in scale) from today's BGP4 situation
of something like 2^18 prefixes active in a 32-bit space.

I'm not aware of any solutions other than TCAMs or Patricia tries
for fast lookups in such a space, whether it's for mapping or
for forwarding.

   Brian

On 2008-09-21 14:54, Marshall Eubanks wrote:
> Dear Brian;
> 
> When I hear "sparse" I think of sparse matrix techniques (which I don't
> think could apply here)
> or sparse message passing techniques (see, e.g.,
> http://www.cs.umass.edu/~culotta/pubs/culotta07sparse.pdf ),
> which might.
> 
> Are you implying that such methods might be useful in routing in a
> "flat" internet ?
> 
> Regards
> Marshall
> 
> 
> On Sep 20, 2008, at 10:08 PM, Brian E Carpenter wrote:
>

---

From: David Conrad <[email-masked]>
Date: Sat, 20 Sep 2008 21:52:42 -0700

Brian,

> are multihomed, or care in the least if they get a new IP address

I would classify this as a failure of imagination. If RRG is indeed  
aiming at 10 to 20 years in the future, I would be quite astonished if  
an underlying assumption is that the way the Internet is today is the  
way it will be one to two decades in the future, just bigger.

My assumption is that as people become more and more dependent on  
Internet connectivity for their day-to-day lives, the less interested  
they will be in periodic outages.  When the myriad devices in your  
house depend on being connected to the Internet and you have a wide  
variety of layer 2 technologies over which to connect (e.g., WiMax,  
FTTH, Cable, DSL, and their successors), I fully expect most domestic  
subscribers to be multihomed.  Actually, I expect it to be worse than  
that -- I can very easily imagine multi-homed PANs connected to  
multiple providers via cell phone-as-router-equivalents.

As such, in my opinion, a design that does not anticipate (or at least  
cannot scale with) massive multihoming would be a waste of time.

FWIW.

Regards,
-drc

---

From: "Heinrich Hummel" <[email-masked]>
Date: Sun, 21 Sep 2008 21:31:00

Brian

--------------------------
I disagree. In a network topology you can add to each node an additional attribute. E.g. a color like red or blue. But also a geo-location id which is  like a second identifier, and it is as  stable as can be and as aggregatable as can be:
James A. Michener writes in "Alaska" that one day in the far future San Francisco will smoothly arrive at the North Pole. a) we don't have to bother when this day will come. b) even then the  geopatch of S.F. as of today will still be the same.
You can make any geolocation to be the center of multiple circles (neighborhoods) of different radius.
Regrettably, LISP creates a new namespace but hereby uses the same old IPv4 swamp address 
space :-(
Heiner

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Sep 2008 10:55:15 +1200

> way it will be one to two decades in the future, just bigger.

However, many people here seem to be assuming that current operational
practice will be just the same, specifically the attachment to
unscalable techniques such as PI addressing and boundary firewalls.
If we take those as givens, we're forced into a conservative mode
of thinking.

> they will be in periodic outages.  When the myriad devices in your house
> depend on being connected to the Internet and you have a wide variety of
> layer 2 technologies over which to connect (e.g., WiMax, FTTH, Cable,
> DSL, and their successors), I fully expect most domestic subscribers to
> be multihomed.  Actually, I expect it to be worse than that -- I can
> very easily imagine multi-homed PANs connected to multiple providers via
> cell phone-as-router-equivalents.

Agreed.

> cannot scale with) massive multihoming would be a waste of time.

We've had that design for almost 15 years - it's called PA, with
multiple prefixes per PAN. As I already said, I don't think the
mass-market users even know what an IP address is, and certainly
don't have any attachment to PI. PI and its consequent problems
are for larger networks.

I think this is very do-able: PI for ten million larger sites,
with LISP-type mapping if needed, and multi-prefix PA for
maybe ten billion consumer nodes, PANs and MANETs.

     Brian

---

From: Robin Whittle <[email-masked]>
Date: Mon, 22 Sep 2008 18:09:07 +1000

Short version:     Economic incentives for joining (aggregating)
                   multiple adjacent MABs (Mapped Address Blocks)
                   into one MAB.

                   In the future there may be annual fees for
                   advertising a prefix in BGP - any prefix, or
                   maybe just new prefixes.

                   Why a core-edge separation scheme such as Ivip,
                   LISP, APT, TRRP or Six/One Router can still
                   provide scalability benefits even if these
                   MABs (or whatever their equivalents are in
                   schemes other than Ivip) are not joined together.

Hi Brian,

You wrote:

>> networks which have adjoining address space to advertise their
>> two or more UABs as a single MAB, instead of each UAB being a
>> separate MAB.
> 
> True. But that is, to use the technical term, a crap-shoot, just
> as BGP aggregation of adjoining PI prefixes is a crap-shoot. It
> will be the exception rather than the rule; that's the nature of
> a swamp. There are no natural economic forces that provide
> incentives for aggregation.

There might be some economic forces making the joining of two
adjacent MABs into one - since there will probably be economies of
scale regarding provision of mapping updates and OITRD services.

At some point in the future, it is possible that there will be a
more restrictive arrangement for BGP advertised prefixes.  For
instance, they may cost a certain fee per year, by some widespread
or universal agreement by a number of large providers that they
won't recognise any new prefixes which are not in this paid-for
scheme.  The revenues could be distributed in some way to help pay
for the core routing system in some way.  Even if the money was
given to charity, it would have the important benefit of reducing
growth in the number of DFZ routes.

There are various technical and administrative problems to solve,
and perhaps such a system would be contrary to various restraint of
trade laws - but I think that it is a likely development some time
in the next 5 to 15 years.  When the tragedy of the commons looks
like getting bad enough, a scheme such as this will be seriously
contemplated and then implemented - as is the case with taxes on
activities which release greenhouse gasses.

If that was the case, and if if the scheme developed to the point of
making each existing DFZ route a costly annual expense, then there
would be economic incentives to join adjacent MABs into a single
larger MAB (shorter prefix MAB), since OITRDs (Open ITRs in the DFZ)
for that space could then be provided with a single DFZ route.
There would be disincentives too, since whoever runs the currently
multiple MABs would need to agree on how they would all work
together with a single RUAS (Root Update Authorisation Server)
company for mapping changes, and with this, or another, company for
the OITRDs service.

However, I agree that expecting there to be a lot of aggregation of
MABs (joining adjacent MABs into one) would resemble a crap-shoot.

I wasn't suggesting that there should be a million MABs.  That was
an example of things not working out well.  If there were at some
stage a million PI end-user networks all converting their space to a
MAB, then it would still probably be better than before, assuming
many such networks split their space into two or more BGP advertised
prefixes.

It would be much better if most of those million networks decided to
relinquish their current PI space and instead gain some (perhaps
smaller) SPI space from a MAB operating company.  The very biggest
end-user networks such as universities probably wouldn't do this,
but it would be best if the smaller ones generally got out of the
BGP business and used SPI space, via Ivip or whatever.

There would probably be significant economic incentive to do this,
since the network wouldn't need BGP expertise, or have to worry
about responsibilities which go with advertising a BGP prefix.
Also, there would be a clear incentive to adopt SPI space if there
was some fee-based scheme for any BGP advertised prefix.

> So I stick to my guns: we need to map the edge-swamp into a
> significantly smaller core-swamp, or nothing will change. 

I agree.

> Relying on aggregation at the edge hasn't worked for BGP, so why should
> it work for any form of EID/RLOC mapping (regardless of terminology)?

Even if every existing PI network converted their space to an MAB,
and if none of them joined them together (aggregation), then the
core-edge separation scheme, such as Ivip, LISP, APT, TRRP or
Six/One Router would still be a routing scaling solution, because:

1 - Without the scheme, many of the existing PI end-user networks
    would have been splitting their space and advertising it as
    multiple prefixes.  With the scheme, they only advertise one
    prefix in BGP - their MAB.

2 - Most or all new end-user networks which need or want portable,
    multihomable, address space will obtain SPI space from an
    existing MAB, by renting it from a MAB operating company.

    Without the scheme, many of these would have got their own
    conventional PI space and advertised it in BGP as one or more
    prefixes.

  - Robin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Sep 2008 12:46:05 +0200

> that level even the dentist's offices are multihomed.

If you count the number of ASes per capita the low water mark is  
around 15k people per AS. With a 9G population max that would be 600k  
ASes so 10M allows for a 15 x increase. That sounds reasonable based  
on today's notions, but...

> are multihomed, or care in the least if they get a new IP address

Famous last words... It could happen, but only if it's actually  
possible. Supply creates demand. Another issue could be that in the  
future not every _organization_, but rather every _office_ becomes  
multihomed... That would be scary.

But why would we want to hardcode an upper limit, anyway?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Sep 2008 12:48:43 +0200

> for fast lookups in such a space, whether it's for mapping or

How helpful would it be if the prefixes were non-sparse? I.e., 2^25  
prefixes out of a /26.

Currently the RIRs are being extra sparse on purpose (reserving a /44  
for everyone who gets a /48) and I've long argued that this doesn't  
have the intended helpful effect in practice but it is harmful because  
of the increased sparseness.

---

From: Steven Blake <[email-masked]>
Date: Mon, 22 Sep 2008 08:18:43 -0400

> for fast lookups in such a space, whether it's for mapping or

It wouldn't hurt if the vast majority of those prefixes were the same
length (say /48).  There are max-two memory access schemes for fixed
length keys.

Regards,

// Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Sep 2008 14:35:27 +0200

> length (say /48).  There are max-two memory access schemes for fixed

If the space is densely populated you can simply use an array, this is  
extemely efficient.

---

From: [email-masked]
Date: Mon, 22 Sep 2008 09:56:21 EDT

In einer eMail vom 22.09.2008 15:41:56 Westeuropäische Normalzeit schreibt  
[email-masked]:

Brian  wrote:

And the right alternative is to do forwarding without any address prefix  
dependency at all, see also my previous emails.
 
Heiner

Tony

Subject: Fw: RE: [RRG] Re: Fast and sparse mapping?
From: "Heinrich Hummel" <[email-masked]>
To: <[email-masked]>
Date: Mon, 22 Sep 2008 15:41:34

-------- Kabel E-Mail Forward ---------------
From: [email-masked]
To : [email-masked];[email-masked]
Date: 18.09.2008 19:37:46

More catch up... 

Brian wrote:

Tony

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

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 22 Sep 2008 11:02:22 -0400

On Sep 22, 2008, at 8:35 AM, Iljitsch van Beijnum wrote:

> If the space is densely populated you can simply use an array, this  
> is extemely efficient.
>

Is there any actual chance of having a densely populated space in IPv6 ?

Regards
Marshall

---

From: Stephen Sprunk <[email-masked]>
Date: Mon, 22 Sep 2008 10:25:50 -0500

> of the increased sparseness.

The RIRs were told by operators that limiting the total number of routes 
(by allowing room for growth thus removing the need for most orgs to 
come back for additional blocks) was more important than keeping the 
space densely populated.

We are barely at the point where routers could theoretically handle a 
densely-populated 32-bit route table, years away from being able to 
handle a densely-populated 48-bit route table, and pushing either 
through BGP-4 is patently impossible.  So, I tend to think the operators 
had it right.

S

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Sep 2008 09:16:02 +0200

> Is there any actual chance of having a densely populated space in  

Not for the whole space, of course. But you could have parts of it  
densely packed and the same prefix length, so you could have a bunch  
of arrays... But then you need to have a two step lookup algorithm.

On 22 sep 2008, at 17:25, Stephen Sprunk wrote:

>> Currently the RIRs are being extra sparse on purpose (reserving a / 
>> 44 for everyone who gets a /48) and I've long argued that this  
>> doesn't have the intended helpful effect in practice but it is  
>> harmful because of the increased sparseness.

> The RIRs were told by operators that limiting the total number of  
> routes (by allowing room for growth thus removing the need for most  
> orgs to come back for additional blocks) was more important than  
> keeping the space densely populated.

Unfortunately, it doesn't seem to work much in practice because very  
many people simply advertise a bunch of /20s rather than something  
bigger. The move from /35 to /32 in IPv6 took forever and I'm willing  
to bet there are still some /35s out there.

> We are barely at the point where routers could theoretically handle  
> a densely-populated 32-bit route table, years away from being able  
> to handle a densely-populated 48-bit route table, and pushing either  
> through BGP-4 is patently impossible.  So, I tend to think the  
> operators had it right.

The problem is that if you have 64k /48s that would be a /32, but they  
actually reserve a /44 for each of those /48 users so they use up a / 
28. Now if you aggregate that /28 into /48s (and most of the prefixes  
in that /28 are /48s) then you end up with 1M /48s which will  
instantly kill any existing router and there is no filter that allows  
the actually assigned prefixes but doesn't allow this type of  
deaggregation. With a /32 worth of /48s this risk is much reduced.  
People who need more space can then get a /44 or whatever they need as  
a second block. Yes, this means two blocks instead of one (probably  
infeasible to make them return the original /48) but we're at more  
than 8 prefixes AVERAGE for IPv4 today so 2 in SOME cases isn't so bad  
if this makes it possible to filter against deaggregation attacks.

---

From: David Conrad <[email-masked]>
Date: Tue, 23 Sep 2008 08:46:52 -0700

> The problem is that if you have 64k /48s that would be a /32, but  
> they actually reserve a /44 for each of those /48 users so they use  
> up a /28.

When the global IPv6 (IANA to RIR) allocation policy was proposed, the  
RIRs promised to stop reserving IPv6 address space and allocate from  
the /12s they received using the "bisection" method (adding a bit to  
the prefix length to split a block in half).  The rationale behind  
this approach was to limit the number of independent prefixes  
allocated to a single ISP because that ISP ran out of space.  I am  
aware that at least one RIR actually followed through with their  
promise.  The last time people cared about dense packing address  
allocations was around 1993 or so.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 23 Sep 2008 09:28:47 -0700

Brian,

> maybe ten billion consumer nodes, PANs and MANETs.

If "multi-prefix PA" actually worked for folks, we wouldn't be having  
this discussion.

If RRG is supposed to be coming up with a scalable routing  
architecture, I would think it better to not have arbitrary boundaries  
between first class and second class network citizens.

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Sep 2008 09:42:42 +1200

> If "multi-prefix PA" actually worked for folks, we wouldn't be having

If it had been seriously tried out, we'd have some objective information
whether it actually works. All we actually have is conservative reactions
from people who've come to think of the way we do things with IPv4 as
the only way things could ever be.

> 
> If RRG is supposed to be coming up with a scalable routing architecture,
> I would think it better to not have arbitrary boundaries between first
> class and second class network citizens.

Nobody said anything about 1st and 2nd class. There's a qualitative difference
between sites with trained IT management and unmanaged sites, and they
operate different solutions today; why wouldn't they operate different
solutions in future? What's the benefit in constraining them to the
same solution?

    Brian

---

From: Scott Brim <[email-masked]>
Date: Tue, 23 Sep 2008 18:14:17 -0700

On 9/20/08 7:08 PM, Brian E Carpenter allegedly wrote:
> are multihomed, 

I agree residences will probably consolidate down to one or two
connections as long as the economic system looks something like it is
today.  However, I believe we should design for a world where most user
*devices* will be multihomed (radio), and for mobile personal area
networks.

> or care in the least if they get a new IP address
> each time they connect.

Agree.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Sep 2008 10:00:55 +1200

Resent, since the list's anti-trivia protection interpreted the
third word that I quoted as being an administrative request,
due to a rather generic regular expression. I can't really
explain it properly, since otherwise the same regular expression
would very possibly reject the message again.

On 2008-09-24 13:17, Scott Brim wrote:
> On 9/21/08 3:55 PM, Brian E Carpenter allegedly wrote:
>> ... the attachment to u n s c a l a b l e techniques such as PI addressing
> 
>> with LISP-type mapping if needed, 
> 
> Could we de-conflate PI please?  We had to sort it out a couple of weeks
> ago.  PI is literally "provider-independent" -- just that.  It does not
> necessarily imply global routing or unscalability.  If you are talking
> about globally routed provider-independent blocks, please say so.

Actually, for the point I was trying to make, I don't think it matters.
As long as FIB sizes in the core routers are economically feasible,
we can stay as we are (with globally routed PI). When we reach the
economic tipping point for FIB size, future PI prefixes would need to be
mapped-and-encapped; I assume that tipping point would be somewhere
between a million and ten million prefixes. That doesn't avoid the
issue that transparent communication between current and "new" PI
prefixes will be required. Of course, that's what I was getting at
with my half-baked hierarchical proposal last November.

    Brian