On 16/11/2012, at 7:24 AM, Dino Farinacci <farinacci(_at_)gmail(_dot_)com>
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
lisp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/lisp