Subject: Re: [lisp] LISP EID Block Size

From: [email-masked] (Noel Chiappa)
Date: Thu, 31 Oct 2013 11:32:35 -0400 (EDT)

> From: Rene Bartsch <[email-masked]>

    > 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.

Giving a PI block to every person on the planet is an 'interesting' idea, but
I don't see that it has much connection with this experiment - which is, as I
just pointed out to Geoff, to experiment with 'facial' EIDs.

(Although I can see that if 'facial' EIDs turn out to have important
advantages over 'regular' EIDs, people might want 'personal' PI blocks to be
'facial' EIDs.)

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

I am fairly sure that this is outside the scope of this WG. I'm not sure where
is; perhaps someone who's more familiar with the current broad scope of IETF
efforts can point out the appropriate place for that.

Obviously, if personal PI blocks happen, they will need some sort of
identity/location suppport to make them work, but LISP is only one possibility
for that.

	Noel

---

From: Rene Bartsch <[email-masked]>
Date: Thu, 31 Oct 2013 17:07:42 +0100

> identity/location suppport to make them work, but LISP is only one 

I see the scope of this experiment to create an OSI-layer 3.5 which 
inserts an identity-location abstraction between OSI-layer 3 and 4 - 
which just means it creates end-to-end connectivity using roamable 
identities. And if improving communication and boosting the economy by 
consumer roaming is a by-product, we should jump at the chance.

And experimenting with a dedicated EID-prefix will help us to find ways 
to aggregate routing(-tables) to run a infrastructure with so much 
expected endpoints smoothly.

Best regards,

Renne

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 31 Oct 2013 20:16:47 +0100

On Thu, Oct 31, 2013 at 5:07 PM, Rene Bartsch <[email-masked]> wrote:
> I see the scope of this experiment to create an OSI-layer 3.5 which inserts
> an identity-location abstraction between OSI-layer 3 and 4 - which just
> means it creates end-to-end connectivity using roamable identities. And if
> improving communication and boosting the economy by consumer roaming is a
> by-product, we should jump at the chance.
>
> And experimenting with a dedicated EID-prefix will help us to find ways to
> aggregate routing(-tables) to run a infrastructure with so much expected
> endpoints smoothly.

I must admit I wrote the outline of the mgmt-draft on purpose in a
quite generic way so it is possible to use it without LISP.... it
would be really stupid (I think) to lock it to LISP use only. Does any
of you know what the future might bring? This might be the best idea
in quite some years for all we know.

However, as pointed out by Dino and Noel, the point with this
experiment is quite well defined, the text in the draft might not be
perfect so good have this feedback:-)

And about Sander Steffann's problem:
"I understand what the technical idea is. There are already EIDs out
there (including my own network) that are not in any special prefix.
Therefore "address is in special prefix" != "address is an EID".
Unless you break LISP for already existing sites I don't see how
having a special prefix is going to help in (correctly) determining
whether an address is an EID."

The _big_ difference between EID's out there today, and the one from
this new netblock are that any system should _know_ by matching the IP
that this is EID space, and by that know how to handle it.

If traffic grow as everyone predict, and continue todo so, optimizing
the handling of LISP EID's is probably a very good idea.

-- 

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

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 31 Oct 2013 19:37:18 +0000

> the handling of LISP EID's is probably a very good idea.

As long as the system handles sending map-requests for non EID_block prefixes, and interpreting the negative and positive replies, then the overall complexity of the system isn't really changed by the EID_block's existence.  That doesn't mean that it is not a good idea to experiment with this allocation - or that some here-to-now unknown use case will see great benefit by the using the EID_block's assumptions.  I just think we should keep our expectations for the benefits of this block modest.

-Darrel