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

From: [email-masked] (Noel Chiappa)
Date: Wed, 21 Nov 2012 12:58:36 -0500 (EST)

> From: "George, Wes" <[email-masked]>

    > I don't think that expecting code to handle two blocks (the
    > experimental one and the permanent one) is asking too much

We disagree. For me, it's extra code/complexity, and it buys you absolutely
nothing at all.

    > If a single permanent allocation that never changes is truly necessary

Allocation != reservation. Nobody is asking for the entire chunk to be
_allocated_ (i.e. given out), just that it be _reserved_ for this use.

	Noel

---

From: Sander Steffann <[email-masked]>
Date: Wed, 21 Nov 2012 21:03:04 +0100

Hi Noel,

> We disagree. For me, it's extra code/complexity, and it buys you absolutely

I don't agree. See below.

> _allocated_ (i.e. given out), just that it be _reserved_ for this use.

But if I understand correctly it's going to be hard-coded somewhere. That will mean that everything that is reserved now will be unusable for anything else ever. I'm not *that* worried about wasting IPv6 addresses, but I do worry about any hard-coding of prefixes. What for example if LISP is such a success that the block is too small?

Wouldn't it be better to have a bootstrap method that is more flexible? The DDT root servers know which prefixes are delegated, so we might extend the DDT protocol to return that list of prefixes. I write code myself, so I know it's a lot more work to implement something like that properly. I'm worried about the consequences of making this hard-coded though. We can't foresee all the possibilities at this point in time (if ever).

Another benefit of making this flexible is that multiple models of LISP deployment can be used. It doesn't matter anymore if IANA reserves a special block, RIRs assign from separate blocks, or even if ISPs offer LISP based solutions to their customers (which happens to be what I am doing).

You get all that, but yes: it does make the code more complex. On the other hand: LISP implementations know how to talk to DDT servers and probably also have prefix-list-matching code already, so it shouldn't be too difficult to get a list of prefixes and match against it.

- Sander

---

From: "George, Wes" <[email-masked]>
Date: Wed, 21 Nov 2012 15:25:12 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Noel Chiappa
>

[WEG] You're hairsplitting on semantics in a way that is mostly unhelpful to the discussion at hand. Reserving the block for LISP means that it cannot be used for anything else. Whether that's an IANA reservation or an RIR allocation is really immaterial to the point I was making, which is that if you truly believe we have to identify a block once and for all for LISP that is the correct size to be used permanently and indefinitely, you need a better justification than you've given, and using "experimental" as a justification for not having the details worked out isn't going to be acceptable.

Regards,

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Nov 2012 14:01:14 -0800

Make it an allocation for EIDs and ILNP can use it too.

Dino

On Nov 21, 2012, at 12:25 PM, "George, Wes" <[email-masked]> wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 22 Nov 2012 10:04:43 +0100

> Make it an allocation for EIDs and ILNP can use it too.

Somehow I hear a voice in the back of my head asking if we're talking
about starting to use another big IPv6 block than 2000::/3 for the two
above mention usage?

2000::/3 for our current model of Internet with our current style of
allocation/assignment of address space to ISP/end users
xxxx::/3 for future modells, LISP/EID, ILNP and others?

-- 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Nov 2012 09:44:39 +0000

Hi Roger,

> xxxx::/3 for future modells, LISP/EID, ILNP and others?

I've been relatively relaxed for many years about allocation policy
in 2000::/3, precisely because that leaves most of the total address
space free in case we turn 2000::/3 into a swamp.

I would be a bit nervous about dedicating another /3 for unproven
use. There's a risk of it ending up unusable like Class E. So
if we are going to do this, doing it inside 2000::/3 seems a
bit safer to me.

    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Nov 2012 12:56:17 -0800

> if we are going to do this, doing it inside 2000::/3 seems a

So what if we could say the use is simply to assign addresses out of this block that stay relatively permanent to a device that sources packets from this address. 

The address has no dependency on the topology the device connects to, the number of interfaces the device has  connected to the network, or even if the device is connected at all to the network. 

So this proposal doesn't have to be associated with LISP or any other mechanism being used. This block could be used today as simply a PI block if no new mechanism is deployed.  And if a sub-block of this prefix is used for LISP purposes, then so be it. 

And I don't think we have to jump in with 2 feet and allocate a very coarse prefix for this. 

Dino