Subject: [lisp] LISP EID Block Size

From: Luigi Iannone <[email-masked]>
Date: Wed, 30 Oct 2013 16:31:23 +0100

Hi All,

I was thinking that may be it is worth to (re)open the discussion about the EID block size.

Currently we are requesting a /16 and asking to reserve the /12 covering it. This was the outcome from the WG consensus, hence, it has not been changed in the document.

Yet, one of the main critics during the review was about the size of the block which seems too large.

Any thought about a change in the requested EID block size?

Should we keep it as it is?
Should we shrink it? How much?

Any feedback welcome.

see you next week in Vancouver

Luigi

---

From: Rene Bartsch <[email-masked]>
Date: Thu, 31 Oct 2013 14:51:21 +0100

Am 2013-10-30 16:31, schrieb Luigi Iannone:
> Currently we are requesting a /16 and asking to reserve the /12
> covering it. This was the outcome from the WG consensus, hence, it has
> not been changed in the document.
> 

To which document are you referring? draft-ietf-lisp-eid-block-06.txt 
proposes /16 with /12 reserved.

Having the possibility to establish global, provider-independant 
network-roaming for consumers with LISP, a /16 with 2^32 /48 will not 
suffice for each natural person on this planet. We already will have to 
assign /56 to natural persons and bigger prefixes to corporate entities 
with /16 only.

In fact I'm already considering the requirements for global, 
provider-independant network-roaming for consumers. In short:

1. Assignments of EID-prefixes should for lifetime, provider-independent 
and remain in force when EID-prefix-bearers change the RIR region.
2. Each natural person can register ONE /56 EID block (256 possible /64 
subnets should suffice for a natural person).
3. Corporate entities can register a reasonable EID-prefix based on 
their size, infrastructure and expected growth.
4. LIRs can charge a reasonable fee once but MUST NOT recharge fees. The 
fee should be low enough to allow any natural person to register a 
EID-prefix.
5. Bearer of EID-prefixes can select any Map Server service or run it 
themselves to encourage reasonable fees by competition.

And I think /16 is a good start. If LISP fails, the /16 will be usable 
again in 6 years. If it succeeds, IANA will have to hurry assigning the 
/12 block! ;-)

AVM-routers will provide LISP-clients for 50% of the german and 20% of 
the european internet-sockets until end of the year. LISPmob provides 
support for Linux and Android (although Android still requires rooting).

Regards,

Renne

---

From: Rene Bartsch <[email-masked]>
Date: Thu, 31 Oct 2013 16:43:54 +0100

Am 2013-10-31 14:51, schrieb Rene Bartsch:

> suffice for each natural person on this planet. We already will have
> to assign /56 to natural persons and bigger prefixes to corporate
> entities with /16 only.

To boost the discussion a little bit:

Just consider every consumer gets a /56-EID-prefix. He can assign a 
/64-EID-prefix to each home, car, caravan, boat, ...
LISP will boost home automation, car-to-car-communication, mobility 
services, etc. by bringing a roamable end-to-end-connectivity to each 
device. You can just park you caravan in the range of a public 
WLAN-hotspot and communicate directly with the air-conditioner half an 
hour before returning from hiking. Or you can call your cat home for 
lunch when it passes a public WLAN-hotspot. Or you can check if you have 
groceries in the refrigerator you moved from your old home to your new 
home a few days ago ...

The possibilities for consumers are endless and so they are for vendors 
... ;-)

-- 
Best regards,

Rene Bartsch, B. Sc. Informatics

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 31 Oct 2013 11:52:37 -0400

> And I think /16 is a good start. If LISP fails, the /16 will be usable again in 6 years. If it succeeds, IANA will have to hurry assigning the /12 block! ;-)

Renne, I am not picking on you but this language seems to be used by a lot of people. So you are just the latest messenger here. :-)

The language I am referring to is "... If LISP fails ..." with respect to what happens with this EID-block. 

We are not saying this entire block is being used for global deployment of LISP.  And no one is saying LISP can't succeed without this block. And no one is really refusing to return the block when LISP succeeds. 

We want to have a block that we can try to do different forwarding decisions on. Trying some new experiments with lookup and forwarding efficiencies. It does not mean that the current forwarding paradigm does not work or cannot work. 

We must not and will not require reassignment of addresses to use LISP. So as it has been said before, existing allocations and futures allocations can be EIDs. 

An address becomes an EID when it no longer is advertised by an edge BGP router (from a tail or stub portion of the Internet topology). 

Dino