Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

[George Michaelson <[e-mail]>]

On 16/11/2012, at 7:24 AM, Dino Farinacci <[e-mail]> wrote:
> 
>> Secondly, you appear to assume these allocations to EID can simply use current RIR practices. The problem is that you need to understand what needs-based and justification means in process terms: Hostmasters in the RIR system try very hard not to be placed in a position of making arbitrary subjective decisions: they have processes which are designed to ask for objective justifications to specify why an allocation should take place, and at what scale. Those objective criteria face addresses as addresses. not EID.
> 
> No, I am not making any assumptions either way. How allocation gets done is subject to more work.

Maybe this is something you could come to an RIR meeting and present on or discuss? We've got an APNIC/APRICOT coming up early in 2013 and I am sure you'd be welcomed to submit some content. Its good to talk about these things.


> 
>> For an example: IPv6 address allocation process currently is implemented using sparse allocation (binary chop with some modifications) in the APNIC region. This maximises space around allocations to equalise the distribution of free blocks such that the commons, the unallocated space, remains as usefully large as possible and when the next binary stride is entered, there is some understanding its going to be applied in common to all occupants of that region of space (in terms of the size of hole around them, which is not a reservation per se, but provides for risk-management of future growth to the largest extent).
> 
> There is no special semantics of EIDs that require you to change this. EIDs are just addresses that do not get injected into the underlying routing system. Other than that, they are just like any other address an RIR allocates.

But by not being injected in the routing system they've already got a qualification against normal allocations, which are for globally routed addresses. So if under current criteria, somebody fronts to the RIR system and asks for a unique address assignment NOT to be globally routed, what do you think happens?

We try not to 'just make it up on the fly' -If there is going to be an EID space, shared footprint, with this behaviour, it will need to be documented in RIR policy.

> 
>> We're really quite proud of sparse: its extended the life of the /12 we occupy quite markedly. What impact will EID have on this? Is sparse an appropriate allocation engine to use for EID? What if eg you have expectations of almost-geographic aspects of address management in EID. Doesn't that require documentation as a process? And, you may be specifying a cost on the RIR system, to engineer support for the new allocation logic. If it doesn't logically fit in sparse allocation, we need to know. And we need to know why.
> 
> What Joel said.

4.  Expected use


   Sites planning to deploy LISP may request a prefix in the IPv6 EID
   Block.  Such prefix will be used for routing and endpoint
   identification inside the site requesting it.  Mappings related to
   such prefix, or part of it, will be made available through the
   mapping system in use or registered to one or more Map Server(s).
   Too guarantee reachability from the Legacy Internet the prefix could
   be announced in the BGP routing infrastructure by one or more
   PITR(s), possibly as part of a larger prefix, AGGREGATING several
   prefixes of several sites.

[my emphasis]


> 
7.  Routing Considerations


   In order to provide connectivity between the Legacy Internet and LISP
   sites, PITRs announcing large AGGREGATES of the IPv6 EID Block could
   be deployed.  By doing so, PITRs will attract traffic destined to
   LISP sites in order to encapsulate and forward it toward the specific
   destination LISP site.  Routers in the Legacy Internet must treat
   announcements of prefixes from the IPv6 EID Block as normal
   announcements, applying best current practice for traffic engineering
   and security.

[my emphasis]

thats in the 03 draft. So, naievely, I read that as meaning global unicast Aggregation. If it refers inside LISP only and is not implying aggregatable assignment to end entities holding EID, if EID are unique only and can be sparse and disjoint, Thats good to know.


>> EID are not going to be used like 'normal' addresses. So, the normal justifications don't look entirely
> 
> Define how a 'normal address" is used.

globally routable (normally) for starters. With assignment dynamics which relate an end-site to a customer, so with some scaling which reflects demand and the depth of network complexity to achieve it. Which is specified at time of assignment and tracked for subsequent reallocation/growth. 

Address management has costs btw. I expect many people in this community are concerned by that and there are times quite unpleasant language is used about the RIR process and its cost recovery needs, but it can't be avoided. So in that context, did you expect EID allocation and address management to be free? Its got to reflect its societal costs like other addresses is a possible position.

> 
>> appropriate to me from 10,000ft. The document needs to say "maybe we need to understand the allocation processes that the RIR should objectively apply" or maybe you need to step outside of draft space and engage inside the RIR policy process and seek a global policy which can document the process.
> 
> The working decided that this draft is solely for request purposes. We could use help from RIRs to write a document on how to allocate EIDs. But I am pretty sure it would look like documents that already exist.

Yes, but the conversation would be useful. So why not come into RIR policy development process and kick off a conversation about global address policy (which this clearly is)

Seriously: this could be talked about.

> 
> I don't understand why you think they look different or need to be treated differently. So you have to do the explaining.  ;-)

Cute. I'd like this document to explore the need for work in the area and say its for further study, and observe the IAB/IANA instruction might be pending that further work, because assigning a block without objective criteria and a global policy in RIR Process is not a good idea.

I really don't think the IAB should simply give the /12 on the basis of this document. If another document needs to be spun then this one can sit at IETF last call and share fate.


> 
>> To ask for an IANA allocation without having undertaken this process looks wrong to me. So, I stand by my concern the document isn't ready for IETF last call: it hasn't addressed substantive issues around the process and expectations of address/registry function, to manage the /16, and it hasn't documented the basis of asking for a /16 in the first place, or a /12 reservation.
> 
> Here is a real world example we have been using on the LISP beta network. It is so simple that it really needs no more explanation than what I am going to explain below:
> 
> (1) We have 2610:00d0::/32 allocated for EIDs.
> (2) Each site on the LISP beta network gets a /48 out of that.
> (3) Each site xTRs register their /48 with the mapping system using RLOCs that are PA addresses they use to attach to the Internet.
> 
> That is it. So I am not getting why there are so many issues. Can't we keep this simple and experiment please?

Ok. So work with me on this a bit Dino. I realize you are very busy, but I want to understand.

1) how many /48 have been allocated thus far from this experimental /32? it has 65,000 of them. The dynamics of the rollout would be very interesting.

I'm really interested in this number. Its pretty fundamental to an address application/reservation facing the IAB/IANA and I expect you will be asked it more formally anyway (not by me. I dont do this stuff, but its forseeable). Bearing in mind that Sander Steffan has already shown global-unicast can be used for EID, I don't expect it to be equivalent to the count of EID visible in LISP routing.
t
Anyway, even with that caveat 65,000 is quite a lot. If you've achieved high density, the experiment has very interesting scaling and we need to know. In particular, I would suggest that its possibly less an experiment, and more a product. If its in production, then applying under experimental criteria is a bit of a concern for me.

2) how many /48 do you foresee being allocated in a 1,2,5 year footprint heading to the /16 horizon? There are 4 billion /48 in a /16 

3) how many /48 do you foresee being allocated in the 5,10,20 year footprint heading to the /12 horizon? 

I have to say that to achieve 2) I do not believe this could be in any real sense "an experiment" except to the extent the entire IPv4 network we have is an 'experiment' because 2^32 is looking like a very large amount of EID, equivalent to the entire IPv4 space.

So from here, I can't grasp the /16, let alone the /12. If this is an experiment, then I think we should be having a conversation about what size above a /32 achieves your goals. If there is to be a reservation, we should understand the scoping it can grow to, which begins to look more like the /16 than the /12, although I suspect its a lot smaller than the /16 and more like a /22

[I am not a hostmaster and this is most definitely not an APNIC position: its my personal view]

BTW, comparisons to the /12 of 2002: are very unhelpful to your case. Firstly, it was a transition technology, in the main an automatic tunnelling mechanism and not structured, and the sub assigns in the space reflected their global routing via the IPv4 label embedded.

Secondly, there were very real administrative issues facing 2002: in terms of reverse-DNS, and the over-reach of an ISPs routing footprint and intrusion of services.

I think the /12 reflected the needs of the format to embed the server,client pairs into the footprint of address. Since you have demonstrated your EID is in /48, the size of the parent above that in global routing does not need to be the same as 2002 which depended on totally ad-hoc server IPs and the anycast cloud instance as fallback. 

I may be wrong, but I suspect if the 2002 protocol spec had been written not to need the /12 it would not have been assigned a /12.

I think in hindsight the Teredo footprint of a single /32 in 2001:0: is equally instructive. Microsoft deployed this into their core technology worldwide. clearly, a single /32 can scale to an entire global Internet for this class of tunnel. I appreciate that EID is a different kind of tunnel, but the difference tends to less EID doesn't it?

cheers

-george


> 
> Dino
> 
>> 
>> cheers
>> 
>> -George
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp