Subject: Re: [lisp] LISP EID Block Size

From: Rene Bartsch <[email-masked]>
Date: Fri, 01 Nov 2013 11:51:11 +0100

Am 2013-10-31 22:36, schrieb Geoff Huston:
> On 31 Oct 2013, at 11:57 pm, Dino Farinacci <[email-masked]> 
> wrote:
> 
>> Geoff, LISP can route the entire allocated address space (but just not 
>> requires it to be everywhere). So arguably, LISP can do this at much 
>> cheaper cost and complexity.
>> 
>> The reason for a dedicated block is similar to why we have an address 
>> block for IPv4 and IPv6 multicast. To experiment to see if a 
>> hard-coded block can provide any interesting ideas.
> 
> 
> On the LISP page I already see LISP using IPv4 and IPv6 blocks for
> this experiment. So what have you found out already in terms of
> "interesting ideas"? What do you think that a larger block would
> inform you that is not possible with the existing block?
> 
> (using /56 end site prefixes a /32 can accommodate 16,777,216 end
> sites of course, and even at a 10% utilisation level thats 1.7 million
> end sites. So I;'m kinds mystified why a .32 can't tell you about
> scaling given that we are talking of the order of 10**6 end sites
> within such a block.)

The success of the internet is based on experiments which directly 
scaled into production (like the IP protocol by Cerf and Kahn). Remind 
the pain we have with the IPv4->IPv6-transition because there are not 
enough IPv4-addresses for the whole internet-community. If you just go 
for tiny experiments - like the last 6 years - LISP will never go on air 
for the internet-community. Currently AVM provides a great chance to go 
an air by integrating LISP into millions of consumer-routers 'til end of 
the year and we shouldn't scare them away by a never-ending experiment.

If consumers adopt LISP, we'll need 10,000,000,000 prefixes within the 
next ten years. That means each public PITR will have to announce 
10,000,000,000 BGP-routes to itself if consumers use random PI-prefixes 
from the global unicast space. Multiply the number of public PITRs 
necessary for such a deployment with 10,000,000,000 BGP-routes each and 
you'll realize LISP will either break the internet and go into decline 
or just be a limited luxury for big companies. Using a dedicated 
PI-prefix which can handle 10,000,000,000 subnets will reduce the 
BGP-routes a public PITR has to announce to ONE. So using 24 or 32 bits 
is way to less for the expected growth.

I want to ask everyone on the list: Which facts prevent a scaling 
experiment with the aim of global production state? In my opinion a 
/16-EID-prefix is perfect for that goal.

Best regards,

Renne

---

From: Sander Steffann <[email-masked]>
Date: Fri, 1 Nov 2013 13:45:47 +0100

Hi,

> I want to ask everyone on the list: Which facts prevent a scaling experiment with the aim of global production state? In my opinion a /16-EID-prefix is perfect for that goal.

The problem is in that what you describe depends on public PITRs, and we have seen how badly that worked for 6to4 public relays. Running a public relay costs money (equipment, maintenance, bandwidth), and when nobody pays for them then we cannot expect any decent quality. And LISP will be blamed and seen as an unreliable protocol, just like 6to4. Relying on public relays is a very bad idea.

Now, if some big tier-1 transit networks start running production quality PxTRs (because PxTRs attract traffic, and their customers pay for traffic) then I can see some possibilities. If the LISP traffic volume increases then other networks might also start running PxTRs so they don't have to pay their transits for it, and then we are getting somewhere. But as long as 'public PxTR' means 'someone with good intentions but no real responsibility' then this will be a dangerous experiment for LISP...

Cheers,
Sander

---

From: Rene Bartsch <[email-masked]>
Date: Fri, 01 Nov 2013 13:57:45 +0100

Am 2013-11-01 13:45, schrieb Sander Steffann:
> The problem is in that what you describe depends on public PITRs, and
> we have seen how badly that worked for 6to4 public relays. Running a
> public relay costs money (equipment, maintenance, bandwidth), and when
> nobody pays for them then we cannot expect any decent quality. And
> LISP will be blamed and seen as an unreliable protocol, just like
> 6to4. Relying on public relays is a very bad idea.
> 
> Now, if some big tier-1 transit networks start running production
> quality PxTRs (because PxTRs attract traffic, and their customers pay
> for traffic) then I can see some possibilities. If the LISP traffic
> volume increases then other networks might also start running PxTRs so
> they don't have to pay their transits for it, and then we are getting
> somewhere. But as long as 'public PxTR' means 'someone with good
> intentions but no real responsibility' then this will be a dangerous
> experiment for LISP...

That's an important argument.
We shouldn't rule out public PITRs because of the huge traffic to be 
expected, provide a /16 EID-block and hope it will attract operators of 
backbones and internet exchanges. Maybe we can define some Quality of 
Service rules for PITRs to discourage fun installations with low 
quality.

Best regards,

Renne

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 1 Nov 2013 07:11:38 -0700

> If consumers adopt LISP, we'll need 10,000,000,000 prefixes within the next ten years. That means each public PITR will have to announce 10,000,000,000 BGP-routes to itself if consumers use random PI-prefixes from the global unicast space. Multiply the number of public PITRs necessary for such a 

You are making it sound that LISP is requiring the need for 10 million prefixes. If there are 10 million new sites added to the Internet, no matter which technology you use to connect them, there will be 10 million more addressable prefixes. And if they are indeed PI prefixes, every core router will have to store them. With LISP the edges will store probably 6 orders of magnitude less. And if I'm off with 6, then say 5, but that is just a rounding error IMO.

> deployment with 10,000,000,000 BGP-routes each and you'll realize LISP will either break the internet and go into decline or just be a limited luxury for big companies. Using a dedicated PI-prefix which can handle 10,000,000,000 subnets will reduce the BGP-routes a public PITR has to announce to ONE. So using 24 or 32 bits is way to less for the expected growth.

The PITRs will not have to advertise those. If a large portion of those 10 million new sites are LISP sites then legacy sites may just want to talk to them. When that demand comes, the PITRs will on path of the tail legacy sites (the default path into the Internet), so those 10 million won't need to be advertised.

In fact, a PE router at an ISP would be a fine place to configure the PITR. But the choice is left the ISP to design how it would want to aggregate state, maybe 100 PE routers fan into 10 upstreams where that is where the PITRs go. But I think a PE router can handle 1 million routes today. They do it for the 1000s of VPNs they support. So this isn't a stretch.

Dino

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 2 Nov 2013 12:47:34 +0100

> The problem is in that what you describe depends on public PITRs, and we have seen how badly that worked for 6to4 public relays. Running a public relay costs money (equipment, maintenance, bandwidt…

This problem you're touching here is the interconnect, and interaction
between LISP-world and legacy Internet (as I like to cal lit). We all
agree that the 6to4 path will not work, or scale well.

For the experiments we don't really need this interconnect either, and
if the need arise the mgmt-draft can be used anyhow since it don't
really care if there is interaction or not.  However the eid-block
draft do have some text on this, but it's probably not good enough to
get it done properly. Any idea on how to address it better there?

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 3 Nov 2013 14:32:08 -0800

> The problem is in that what you describe depends on public PITRs, and we have seen how badly that worked for 6to4 public relays. Running a public relay costs money (equipment, maintenance, bandwidt…

Hi Sander,

you are right. But IMHO this is one possible economic model.

What about third parties selling MR/MS services which include also PxTRs services?

Luigi

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Sander Steffann <[email-masked]>
Date: Sun, 3 Nov 2013 23:35:32 +0100

Hi,

> What about third parties selling MR/MS services which include also PxTRs services?

That is exactly what I am doing (oh, well, no real customers yet, but working on that :-). For the PxTR services such a third party would then only announce the block(s) used by his own customers though. Providing free transit for the whole EID block would get kind of expensive if LISP takes off...

Cheers!
Sander

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 3 Nov 2013 14:46:18 -0800

On 3 Nov. 2013, at 14:35 , Sander Steffann <[email-masked]> wrote:

> That is exactly what I am doing (oh, well, no real customers yet, but working on that :-). For the PxTR services such a third party would then only announce the block(s) used by his own customers though. Providing free transit for the whole EID block would get kind of expensive if LISP takes off…

…. or an opportunity to have “peering” agreements with other PxTR providers ;-)

L.

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 3 Nov 2013 14:59:04 -0800

Hi Geoff,

Let’s try to be constructive here, because I have no problem agreeing that the text of the document can be improved, but would be helpful to know where.

You complain about unclear text, but your comments look like being on the same unclear line ;-)

On 30 Oct. 2013, at 22:02 , Geoff Huston <[email-masked]> wrote:

[snip]

> 
> BGP is a huge success - it appears to route 100% of the address space. If LISP 
> becomes a huge success then why wouldn't it route 100% of the address space, just
> as BGP does today? And if it withers and dies then any dedicated address
> allocation will be too much at that point in time. If this is all about an 
> _experiment_ under some form of  experimental constraint then what are the
> bounds of the experiment?

What do you mean exactly by bounds? 

IMO the real limit is to avoid indicting any more pain in the BGP infrastructure.

> What happens at the end of the experiment?

Worst case in 3 years the block is back in the free pool. 

> Why would there 
> be a continuing need to corral LISP into its own dedicated corner of the address
> space? Is there something about scaling LISP to a full unicast routing scale that
> simply does not work? Or is corralling of LISP into a dedicated block  of addresses
> unnecessary?

Noel and Dino gave you long answers on these, I just agree with them.

> Why do I feel that this experiment has not been well thought through?

Help us to clarify, what we did exactly miss? Or what is the big lack we did not cover?

Thanks

Luigi

> Or if it has, then it seems to me that the mapping of parameters of the proposed
> experiment into the words in the two drafts relating to this proposed action
> is still lacking.
> 
> regards,
> 
>    Geoff
> 
> 
> 
> 
>

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 4 Nov 2013 00:30:44 +0000

> …. or an opportunity to have “peering” agreements with other PxTR providers ;-)

We see just this (peering) happening between LISP Service Providers in the US now.

-Darrel

---

From: Sander Steffann <[email-masked]>
Date: Mon, 4 Nov 2013 09:36:32 +0100

Hi, 

> We see just this (peering) happening between LISP Service Providers in the US now.

What exactly do you mean with 'peering' in this context?

Cheers,
Sander

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 4 Nov 2013 14:44:46 +0000

> What exactly do you mean with 'peering' in this context?

If a given PxTR provider is responsible for originating EID prefixes into the DFZ on behalf of their subscribers (LISP Mapping and Proxy services customers) want to widen their footprint/capacity of transit of Proxy-ITRs, they can agree to exchange these EID-prefixes and announce them on each other's behalf.

So if LISP Mapping/Proxy Provider Foo is originating 172.16.1.0/20 and LISP Mapping/Proxy Provider Bar is originating 10.1.1.0/22, and they come to an bilateral agreement to share Proxy-ITR capacity they can agree to peer (via, for example, eBGP multi-hop) and propagate the prefixes that that the other is originating.  Note that the origin AS for these two EID prefixes remains Foo and Bar's respectively.

Today some providers are redistributing registered EID prefixes directly via their map-servers, and some are using static routes independent of redistribution for origination.  (I prefer the latter, but YMMV.)

-Darrel

---

From: Paul Vinciguerra <[email-masked]>
Date: Mon, 4 Nov 2013 15:22:22 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Darrel
> Lewis (darlewis)
> Sent: Monday, November 04, 2013 9:45 AM
> To: Sander Steffann
> Cc: LISP mailing list list
> Subject: Re: [lisp] LISP EID Block Size
> 
> 
> If a given PxTR provider is responsible for originating EID prefixes into the DFZ
> on behalf of their subscribers (LISP Mapping and Proxy services customers) want
> to widen their footprint/capacity of transit of Proxy-ITRs, they can agree to
> exchange these EID-prefixes and announce them on each other's behalf.
> 
> So if LISP Mapping/Proxy Provider Foo is originating 172.16.1.0/20 and LISP
> Mapping/Proxy Provider Bar is originating 10.1.1.0/22, and they come to an
> bilateral agreement to share Proxy-ITR capacity they can agree to peer (via, for
> example, eBGP multi-hop) and propagate the prefixes that that the other is
> originating.  Note that the origin AS for these two EID prefixes remains Foo and
> Bar's respectively.
> 
> Today some providers are redistributing registered EID prefixes directly via their
> map-servers, and some are using static routes independent of redistribution for
> origination.  (I prefer the latter, but YMMV.)
[PV] 
Darrel,

I am unaware of any providers in the US doing this.  I would welcome any introductions on your part :) 

Paul

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 4 Nov 2013 17:08:03 +0000

> I am unaware of any providers in the US doing this.  I would welcome any introductions on your part :) 

Sure, I'll talk to you off list.

-Darrel

---

From: Rene Bartsch <[email-masked]>
Date: Thu, 07 Nov 2013 16:11:51 +0100

> What about third parties selling MR/MS services which include also

What about a dual approach? Third parties for highly reliable PxTRs and 
long-term integration of public PxTRs in the ISP-/backbone 
infrastructure to handle mass deployment for consumer roaming and IP 
portability.

Today we have number porting between providers for phone numbers. Why 
not having global IP porting for consumers with a lifetime 
LISP-PI-prefix ...?

Renne

-- 
Best regards,

Rene Bartsch, B. Sc. Informatics