Subject: Re: [lisp] draft-ietf-lisp-eid-block-03.txt back in workgroup

From: [email-masked] (Noel Chiappa)
Date: Thu, 10 Jan 2013 09:37:30 -0500 (EST)

> From: Geoff Huston <[email-masked]>

    > 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

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 11 Jan 2013 06:35:04 +0100

> have their cake here, and eat it too.)

In section "3. Rationale and Intent" in the draft there is this part:

     The EID Block will be used only at configuration level, it is
     recommended not to hard-code in any way the IPv6 EID Block in the
     router hardware.  "

I understood it that it will never be put directly into code, just in
the configuration. That's why I suggested to change this from
    "recommanded not to hard-code in any way"
to
    "MUST NOT be hard-coded in any way"

Still your argument are valid, it's hard to change it later on but it's doable.

-- 

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