> From: Geoff Huston <[email protected]>
> If we were to assume that each and every single experiment in IPv6
> ... were each to request an experimental allocation that was "once and
> forever" and assumed at the outset that the experiment would result in
> comprehensive deployment over a network many many times larger than
> today's then I hope you can appreciate that we'd not have enough space
> to accommodate each and every experiment's requirements in the IPv6
> space.
Understood.
But do you see a place to draw a useful distinction between 'reserved' and
'allocted'? E.g. if you _reserve_ a /12 for a particular thing, but only
_allocate_ a /24, then if the thing doesn't take off, you don't have to
rescind an allocation - all that happens is that the reservation for the
rest of the /12 is allowed to lapse.
> So of course we see many (most?) experiment proponents proudly proclaim
> that they are uniquely different and obviously their particular
> experiment will naturally result in universal deployment, so why not
> assume that happy outcome at the outset of the experiment and allocate
> resources at a scale commensurate
Sorry, but I don't think that's what's happening here (at least, not in a
simple form).
The thing that's different here is that (in my limited understanding of how
this space is to be used) the _code_ is different depending on whether the
destination is in this space or not. So there are major, real costs to be
paid in changing the block of space used, later on. Its those costs we are
interested in avoiding, _not_ just 'let's not have to come back and allocate
more space later'.
(And the reservation/allocation distinction above is my attempt for all sides
have their cake here, and eat it too.)
> If LISP is so fragile that it requires a very particular deployed
> address structure in order to operate, then frankly we could do
> precisely the same in BGP and achieve better results because of
> avoidance of tunnelling. I find it somewhat strange to see this adamant
> view that LISP absolutely requires a uniquely structured address plan
> in order to achieve any useful outcome in terms of scalable routing
Again, I think you've got it wrong. LISP does't _require_ this block to
operate, as shown by the operation of IPv4 LISP, which works fine (and is
hoped to have a positive impact on the routing) without any such reserved
block.
I gather (again, not too familiar, so take this with a grain of salt) that
having a specific EID block allows us to do some additional useful things
which we can't otherwise do.
> ignoring the simple observation that if one were to do the same surgery
> on the address plan in BGP the outcomes would likely to be just as
> good if not better
Again, no. For example, there's no way to do good support for widespread
(i.e. small entity) multi-homing support with a single-level namespace and
BGP, no matter what address plan one adopts.
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
