Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt

From: "Jmh.direct" <[email-masked]>
Date: Sat, 02 Mar 2013 12:57:47 -0500

Some of those questions are ones we very much need to answer in defining the policies.  That's what I would like to see on the document.  I would guess tgat reverse DNS will not be needed, but I could wrll be mistaken.

Yours,
Joel

Sent from my Samsung smartphone on AT&T

-------- Original message --------
Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt 
From: Arturo Servin <[email-masked]> 
To: "Joel M. Halpern" <[email-masked]> 
CC: lisp <[email-masked]> 

On Sat, Mar 2, 2013 at 6:38 AM, Joel M. Halpern <[email-masked]> wrote:
(Speaking personally, and interested in more data or perspectives.)

As far as I can tell, EID space is not Internet routable IPv6 Unicast space.

Yes, that is ok, but does it have the same constraints of registration and conservation?

Is anybody able to use the whole /16

a piece of it, a /20, /32, /48?

It has to be unique?

Do we need to register it?

If so, do we need a whois/restwhois?

reverse dns?

who is going to operate those services? 
 
And the coordination requirements appear to me to be quite different from those for IPv6 routable unicast addressing.
As are the constraints which drive allocation.

which are?

Which is why I want to spell out the requirements, rather than writing in who will fill those requirements.

I am ok with it. I was on the assumption that the WG have a clear idea of those requirements already.

Yours,
Joel

Regards
as

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 Feb 2013 00:48:45 +0000

Sender: [email-masked]
On-Behalf-Of: [email-masked]
Subject: Re: [lisp] Fwd: I-D Action:	draft-iannone-lisp-eid-block-mgmnt-01.txt
Message-Id: <[email-masked]>
Recipient: [email-masked]

Subject: Re: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt
From: "Joel M. Halpern" <[email-masked]>
To: Terry Manderson <[email-masked]>
Cc: Roger Jørgensen <[email-masked]>, "[email-masked] list list" <[email-masked]>
Date: Tue, 26 Feb 2013 19:46:35 -0500
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>

As a participant, I have an even stronger pinion on the RIR references 
than terry.

I think that the block management needs to define
o who the root is
o what policy we require for allocating blocks to allocators (the root 
is not an allocator
o What the behavioral requirements are for an allocator
o are there any special requirements for re-delegating to another allocator?
o What policies allocators should respect for end site allocation

Once we have this defined, then organizations that wish to participate 
can do so.  If the RIRs want to come play, they may.  If not, then they 
don't.

(Repeated for clarity, the above is a personal opinion, not a WG chair 
position, nor associated with any other hats I may have.)

Yours,
Joel

On 2/26/2013 7:26 PM, Terry Manderson wrote:
> Speaking just as a WG participant.
>
> I would rather a document like this focus purely on the allocation
> criteria that needs to be applied to:
> 	1) An experimental EID block
> 	2) ongoing LISP allocations beyond the life of the experiment
>
> Given the expected (numbering) requirements of a LISP site.
>
> Simply, while it is temping to use the RIRs, and name them, it is not
> appropriate in my opinion to assign work to the RIRs. That is the job of
> their membership.
>
> Similarly, what policies the RIRs have now are all subject to change
> within their own policy development processes. Please don't re-codify them
> here. I would also prefer to see this document take the approach of
> defining what is best for LISP, not how can we use the RIRs as an
> allocation framework. The concern I have is that if LISP ends up requiring
> something very different to how the RIRs do it - we would be doing a
> disservice to both LISP and the RIRs by pushing it that way.
>
> The definition of terms is well stated elsewhere, perhaps you can point to
> those locations?
>
> Cheers
> Terry
>
> On 26/02/13 7:59 AM, "Luigi Iannone" <[email-masked]> wrote:
>
>>
>>
>>
>> FYI a new version is available.
>>
>>
>> Comments still welcome ;-)
>>
>>
>> L.
>>
>> Begin forwarded message:
>>
>>
>> From:
>> [email-masked]
>>
>> Subject:
>> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt
>>
>> Date:
>> 25 February 2013 21:47:29 GMT+01:00
>>
>> To:
>> [email-masked]
>>
>> Reply-To:
>> [email-masked]
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title           : LISP EID Block Management Guidelines
>> Author(s)       : Luigi Iannone
>>                          Roger Jorgensen
>> Filename        : draft-iannone-lisp-eid-block-mgmnt-01.txt
>> Pages           : 9
>> Date            : 2013-02-25
>>
>> Abstract:
>>   This document proposes an allocation framework for the management of
>>   the LISP EID address prefix (requested in a separate document).  Such
>>   framework relies on hierarchical distribution of the address space to
>>   RIRs (Regional Internet Registries), who will allocate on a temporary
>>   basis sub-prefixes to requesting organizations.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> lisp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: John Curran <[email-masked]>
Date: Tue, 12 Mar 2013 08:11:02 -0400

>   basis sub-prefixes to requesting organizations.

It is fairly important to recognize that although this draft (and [I-D.ietf-lisp-eid-block]) 
both indicate that these are temporary assignments out of an experimental block, the
reality (based on the text at the end of section 3 of the draft and discussion on this list) 
is that we also seem to be planning for a successful experiment, which requires that the
EID management guidelines specified in this document should be fairly complete and 
robust, providing a suitable framework and requirements for EID management for the
foreseeable future.  Trying to do both of these tasks at the same time (establishing a
more robust _but still experimental_ EID management framework, as well as defining
the long-term optimum EID management framework) may be irreconcilable.   As just
a single example, the draft indicates "the requester of the experimental prefix has to
provide a short description of the intended use or experiment that will be carried out.";
this is a perfectly reasonable requirement when making experimental assignments,
but not (per se) something that we'd want to have in a long-term framework for EID 
management.

In order to understand which of these two goals (experimental or production) should 
take precedence in the drafting of the EID management guidelines,  it would be good 
to know some more information about the present EID situation:

1. Is the current LISP Beta network mechanisms for EID block assignment 
    insufficient for the task at hand (or expected to be insufficient in the near 
    future)?  Knowing whether we've got a handful of months versus a few years 
    to  work on the EID management requirements may be important in deciding
    what can be reasonably included in the scope (and aspirations) of the 
    requirements.

2. Is it actually acceptable to setup a _truly_ temporary EID management
    framework (i.e. with the potential that the assignments would actually be 
    revoked some number of years from now), or is it true that the EID 
    management framework being specified effectively "must succeed" in
    some form or another, and hence we are really detailing the long-term
    architecture and not just an experiment?  If this truly is an experiment, 
    and we will have the freedom to cast it aside and replace it with something
    better 10 years from now, that would put the requirements in an entirely 
    new perspective.

Any thoughts or comments on the above two questions would be helpful... :-)

Thanks!
/John

Disclaimers:  My views alone.  This email is composed of 100% recycled electrons.

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 12 Mar 2013 11:42:37 -0400 (EDT)

> From: John Curran <[email-masked]>

    > the reality .. is that we also seem to be planning for a successful
    > experiment, which requires that the EID management guidelines specified
    > in this document should be fairly complete and robust .. Trying to do
    > both of these tasks at the same time (establishing a more robust _but
    > still experimental_ EID management framework, as well as defining the
    > long-term optimum EID management framework) may be irreconcilable.

I was going to make a related, but different comment, which is that a lot of
the discussion in this thread, towards the end of it, relates to issues and
mechanisms related to EIDs _in general_, not just this specific experimental
IPv6 EID-only block.

(E.g. the discussion about who's going to run the mapping services, and how
they're going to be paid for, etc.)

While I agree that these general topics really are very important, and worthy
of detailed consideration/discussion, let's just keep carefully in mind that
these general issues will exist _whether or not_ this IPv6-only EID block is
allocated, so they are, to a fairly complete degree, orthogonal to the
discussion of whether to allocate that block, how to manage its allocation,
etc, etc.

	Noel

PS: I'm mostly offline due to travel this week, so don't expect quick
replies!

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 12 Mar 2013 11:56:41 -0400 (EDT)

> O[n]e reason I like the registry/registrar architectural model fo[r]
    > EID allocation is that it avoids end-site lockin with someone who might
    > raise their annual maintenance fees.

This is another one of those issues that exist whether or not that EID-only
IPv6 block is allocated.

The real issue here is the way DDT (or, probably, any similar system) works.
If you're allocated (whether from the special EID-only block, or just regular
PI space, whatever) a block of EIDs, then for the mapping system, you're kind
of stuck using whoever it is who provides the mappings for that branch of the
delegation hierarchy.

This is similar to DNS, where you can buy .com names from a large number of
_registrars_, but if you don't like the way the _registry_ is handling
lookups, you're stuck.

You and I had discussed (offline) a way of allowing competing _registries_
in DDT (basically, all providers of node N have to share their mapping
databases), so it it _possible_ to have competing 'registries' in LISP,
but this has not yet been explored in detail.

I wrote 'registries' since, in general, the EID namespaces in LISP are
provided/controlled by _other_ entities - e.g., for IPv4, IANA and the RIRs.

So it's not a 'registry' service in the terms used in DNS - their 'registry'
service includes _both_ i) allocation, and ii) lookup, whereas DDT (and
whatever entites provide DDT service) only provides the latter.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 12 Mar 2013 19:43:32 -0400 (EDT)

> The choice of going with a single registry with neither competition or
    > nor elected oversight may also work, but places enormous faith in the
    > enduring best intentions of the enlightened and benevolent overseers,
    > particularly once there is significant usage and a complete lack of
    > viable alternatives.

How well does having a single registry for .COM work - can IANA (or ICANN, I
guess, actually) pull their contract if they start performing either the
allocation or server aspects poorly? Because even though there's only one
registry for .COM, everything seems to work pretty well, and has for quite
a while.

(Actually, there are three functions here: i) interacting with the public,
which is 'registrars', ii) uniquely allocating the namespace, and iii)
running the servers which provide public access to the authoritative
database. For DNS, the latter two are both in the same monopoly. I think that
in a system which splits out iii), that does not have to be a monopoly; ii)
pretty much has to be a monopoly - although for 'flat' namespaces, you could
do a two-level allocation, which would allow competition there too.)

But I agree with the whole 'build it organically as we need it' concept -
I think a lot of this could be put off for now, although it might be worth
discussing it _briefly_ in the document.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 13 Mar 2013 20:00:10 -0400 (EDT)

> From: Sander Steffann <[email-masked]>

    > My primary concern is about the reliability of those PITRs. ... As I am
    > already running a production LISP setup this alone would make the
    > EID-only block unusable for me/my customers.

So, don't use it! Use a block you got through one of the existing channels.
(Which you're going to have to use _anyway_ to get address space, right?)

Also, if you use your own address block, you can control which PITRs advertise
it, and only pick 'good' ones (perhaps ones you have a business relationship
with).

    > So, if these are the only things that this block buys us then I think
    > we should just abandon the idea..

It's an _experiment_. Nobody _has_ to use it. I see no reason not to let the
people who want to play with it, do so. Caveat haquur.

    > From: Dino Farinacci <[email-masked]>

    >> I don't think you are confused.

    > Noel is definitely not confused.

Well, some days, I'm not sure I agree... :-)

	Noel