Subject: Re: [lisp] EID allocation / ALT base

From: [email-masked] (Noel Chiappa)
Date: Fri, 15 Oct 2010 16:29:32 -0400 (EDT)

> From: "Joel M. Halpern" <[email-masked]>

    > If there is a single EID prefix, then it seems that someone has to be
    > authorized to give out EIDs from that space. According to some rules.
    > WHo do we give that job to?

The IANA, and delegated from them to the RIRs? The mechanisms are all there
already, why would we want to reinvent the wheel?

    > do they have to run some ALT routers, or does it suffice for them to
    > require that all entities which receive direct allocations from that
    > agency must run ALT routers and must peer with each other?

How does DNS do it, for the top-level domains authorized by ICANN/IANA? There
have to be root servers, etc. Again, something similar here, I would think.

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Oct 2010 17:09:40 -0400

Having IANA and the RIRs do the allocaiton of EIDs is one sensible strategy.
My concern is that at the moment, there is nothing written down that 
says who will do it, according to what rules, etc.  And since there has 
to be some relationship between those allocations and what gets 
advertised in the ALT (in terms of authority for information at least), 
it needs to be spelled out.  (For IP addresses, the addresses are 
delegated to the entities who advertise them, at least in theory.)

DNS does not have a connectednes problem.  Conceptually, everyone "peers 
with" the well known roots (A-root, ...)  Those devices all get their 
data from ICANN / IANA.  The connectivity is then downwards, because 
each device knows the information about the delegations (with glue 
records for all sorts of itneresting problems.)

But in the ALT, we have a BGP structure.  The paragraph you quote from 
me is a sketch pointing at two possible ways to ensure that things 
connect.  (This is, I think, quite separate from the lock-in issues 
which also have to be looked at.  I.e. EID provider lockin / fee 
escalation.  Although that is another story for another day.)

Yours,
Joel

On 10/15/2010 4:29 PM, Noel Chiappa wrote:
>      >  From: "Joel M. Halpern"<[email-masked]>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 18 Oct 2010 19:30:02 +0300

Hello,

I think that building on top of "administratively aggregatable"
allocation system of the EID space is going to lead to as rigid outcome
as the current IANA and RIR allocated addressing solution is. It will
have exactly the same drawbacks and limitations as the current one.
Allocation boundaries will degenerate as the networks keep on evolving
to meet the real life needs (many  times unforeseeable new use cases).
And suddenly the original optimal allocation scheme becomes a burden or
even a show stopper. If the ALT routing systems scalability depends
exactly on how the original aggregatable EID allocation was done and can
not be touched after the allocation then we have a problem again. (You
may optimistically think that this time we will get this alright since
we have experienced this problem earlier, but I am afraid that the
demand of addressable entities are highly unpredictable as it depends to
far too many factors, not only on technology but economics etc.) 

If EIDs were truly PI addresses as touted then binding them into
aggregatable (or topological) allocations would restrict the
applicability of the independence of these addresses, after the system
starts to evolve. 

The routing system would become more durable if we would allow
reshuffling of EIDs with their aggregation points. After all, we still
have RLOCs that aggregate independently from EIDs (ref. identifier
locator separation). The xTRs cloud select with the help of Mapping
Servers the "optimal" Map Server where to register its EIDs. This
selection should be such that it facilitates locality as well as
aggregation in a dynamic way. In fact, the question for resolving an EID
into an RLOC is the one of  which of the Mapping Servers know the
locator of the EID or the locator of the one who knows the locator of
the EID. This doesn't require any fixed allocation of EIDs or grouping
of EIDs. (We wrote about this in our proposal for compact routing based
mapping system. I would be happy to summarize that.)

I would even go so far that the end systems cloud generate their own
EIDs (self certified EID would be preferable) and try to register that
into the mapping system that ensures that each registered EID is unique.
In other words doesn't allow duplicate registrations in the mapping
system. The issue of using EIDs in the intardomain routing is a separate
issue, but easily solvable, ref. IPv6 autoconf. No real issue there.  

Best regards
Hannu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Noel Chiappa
>Sent: Friday, October 15, 2010 23:30
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [lisp] EID allocation / ALT base
>
>
>The IANA, and delegated from them to the RIRs? The mechanisms 
>are all there already, why would we want to reinvent the wheel?
>
>How does DNS do it, for the top-level domains authorized by 
>ICANN/IANA? There have to be root servers, etc. Again, 
>something similar here, I would think.
>
>	Noel