Subject: [lisp] WG Last Call on draft-ietf-lisp-eid-block-mgmnt-02

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 08 Oct 2014 09:14:16 -0400

All,

The work on the draft-ietf-lisp-eid-block-mgmnt-02 seems done and the 
authors requested a work group last call.

This email starts a 14 day WG last call, to end CoB PDT October 22, 2014.

You will find the document here:
http://www.ietf.org/id/draft-ietf-lisp-eid-block-mgmnt-02.txt

Please review this WG document.  Let the working group know if you agree 
that it is ready for handing to the AD, or if you see issues with it. 
If you see issues, please be as specific as possible about the problems, 
and if possible suggest text to resolve them.

Yours,
Joel

---

From: Terry Manderson <[email-masked]>
Date: Wed, 8 Oct 2014 23:42:34 +1000

I have read the draft, and in my reading I could not see any text that I object to, nor any aspect that needed correction nor fixing.

I suspect the IANA Considerations section will end up having some work done on it - but right now I'm not sure in what direction that may take.

I think it is well constructed and ready to hand to the AD.

Cheers
Terry

On 8 Oct 2014, at 11:14 pm, Joel M. Halpern <[email-masked]> wrote:

> All,
> 
> The work on the draft-ietf-lisp-eid-block-mgmnt-02 seems done and the authors requested a work group last call.
> 
> Please review this WG document.  Let the working group know if you agree that it is ready for handing to the AD, or if you see issues with it. If you see issues, please be as specific as possible about the problems, and if possible suggest text to resolve them.
> 
> Yours,
> Joel
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 8 Oct 2014 10:15:57 -0700

I too read the draft and only have a couple of comments. But first a question, can you remind me why this effort is separated out into 2 documents?

Comments:

> The allocation of EID prefixes MUST be done under the following
>    policies:

Can you make it clear that this is for both IPv4 and IPv6 prefixes? That is, if you believe that is true. Or if there won't be enough IPv4 prefixes, then you may want to say most of these address policies are applicable to IPv6 prefixes.

>  6.  When an allocation is freed because of non-renewal or the
>        termination of an experiment, the address space is returned to
>        the global pool of free EID prefixes.  This freed allocation MUST
>        NOT be announced through registration on Map Servers in the LISP
>        mapping system for at least 72 hours to ensure expiration of all
>        cached map entries in the global LISP infrastructure.

I think you should also say these prefixes need to be deconfigured from the Map-Servers. Otherwise, what will be returned to Map-Resolvers using the LISP-DDT will be "configured-but-not-registered" (MS_NOT_REGISTERED) return codes in Map-Referrals. That will mislead operators that the EID-prefix is valid but just not currently registered. You want Map-Resolvers to return to ITRs/PITRs/RTRs "native-forward" since the reuse of the prefix could be used normally with a BGP advertisement associated with it.

Dino

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 8 Oct 2014 11:15:26 -0700

Hello Joel, authors and lisp list,

while I think the document is overall reasonably written it has one problem: 
it's bound to an proposed EID address block that has no guaranteed end of 
life.

If this experiment would clearly terminate after 3+3 years then I would say 
it's good to go. It's not the way the RIRs have written their documents but I 
think that's okay for a experiment and a 6 year time frame. But the proposals 
allow the requested /32 EID block to be turned into something permanently. 
For a permanent EID block it's reasonable to assume the RIRs deal with the 
allocation/assignment work ([1]) and then the document would need more 
alignment with RIR policy documents. A simple example would be the language, 
"allocation" is used throughout while "assignment" is only mentioned in the 
Introduction. I checked both ARIN and RIPE and it's clearly defined there. 
It's also going too far in telling IANA to not have a regional policy.

So in short (and in all honesty): not feeling comfortable with the document 
in the context of a potential permanent impact of the document.

Regards, Marc

[1]: if the proposal is to have finally an additional authority beside the 
RIRs for address allocation then I would reject the proposal. 

On Wed, 08 Oct 2014 09:14:16 -0400, Joel M. Halpern wrote:
> that it is ready for handing to the AD, or if you see issues with it. If 
> you see issues, please be as specific as possible about the problems, and 
> if possible suggest text to resolve them.
> 
> Yours,
> Joel
>

---

From: Brian Haberman <[email-masked]>
Date: Wed, 08 Oct 2014 14:28:07 -0400

Hi Marc,

> in the context of a potential permanent impact of the document.

The eid-block draft (section 6,
https://tools.ietf.org/html/draft-ietf-lisp-eid-block-09#section-6)
discusses the transition to a degree if the allocation were to become
permanent.

The brief discussions I have had with RIR folks is that they would
expect allocations out of this address block to be managed by RIRs if it
were to become permanent.

Regards,
Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 08 Oct 2014 14:29:22 -0400

The document is very clear that any potential transition to permanent 
allocation would have to be discussed and coordianted with multiple 
parties, including the RIRs.

Equally, until such time as a permanent allocation is made, the document 
is not declaring the RIRs to be "the " allocation authority.  If the 
RIRs can and wish to engage in LISP EID allocation in accordance with 
the policy, they can.  But the document does not promise the role to them.

It may, or may not, make sesen if and when we do a permanent allocation 
to specify a role for the RIRs.  That however will be negotiated then.

Yours,
Joel

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 8 Oct 2014 11:49:23 -0700

Hello Joel,

> parties, including the RIRs.

Correct, the document is saying this. Maybe I have a different idea of "very 
clear" though, all it says there must be a discussion.
I would prefer a clear statement that these policies are ending either when 
the EID block experiment ends (obvious) or when the EID block turns into 
something permanent.

> Equally, until such time as a permanent allocation is made, the document is 
> not declaring the RIRs to be "the " allocation authority.

Agree - and I'm not making such a statement.

> If the RIRs can 
> and wish to engage in LISP EID allocation in accordance with the policy, 
> they can.  But the document does not promise the role to them.

If the document deviates from how RIRs operate then the document should not 
be valid at the point any LISP EID blocks becomes permanent. My opinion.

> It may, or may not, make sesen if and when we do a permanent allocation to 
> specify a role for the RIRs.  That however will be negotiated then.

This "may or may not" is the vagueness I mentioned and why I express my lack 
of comfort with the document.

Let me word it differently: the EID block as a sandbox for a large-scale, 
real-life experiment to learn how LISP becomes (or is already) 
production-ready for the Internet - great idea. Beyond that I don't see a 
need for anything special or different for LISP and we have working 
procedures how to allocate/assign address space. This is also the promise, 
that LISP is blending in.

Regards, Marc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 08 Oct 2014 14:51:54 -0400

It would seem to me to be rather odd to spend time working out an 
agreement for what we want to do with a permanent allocation.  We are 
defining the rules for the experimental allocation.

Is there a specific text change that would make that clear enough to 
alleviate your concern?

Yours,
Joel

---

From: Geoff Huston <[email-masked]>
Date: Thu, 9 Oct 2014 06:38:54 +1100

Hi,

I thought that after the last round of discussion on this topic we had come to the
point where the WG specified the technical characteristics of the registry
that would be appropriate for support of this experiment, and the IESG and IAB
would direct the IANA as appropriate to operate a registry that was consistent
with this.

I had also thought that in this dialogue between the IESG, IAB and the IANA, the 
RIRs may well be in a position to provide registry support that would be entirely
consistent with the technical requirements to support this experiment.

So from that perspective I had thought that this draft was clear in intent
and suitable to support the experiment. 

regards,

   Geoff

On 9 Oct 2014, at 5:51 am, Joel M. Halpern <[email-masked]> wrote:

> It would seem to me to be rather odd to spend time working out an agreement for what we want to do with a permanent allocation.  We are defining the rules for the experimental allocation.
> 
> Is there a specific text change that would make that clear enough to alleviate your concern?
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 08 Oct 2014 15:52:12 -0400

Your description matches my understanding, what I was trying to say, and 
what I think the draft does.

Yours,
Joel

---

From: David Conrad <[email-masked]>
Date: Wed, 8 Oct 2014 13:12:03 -0700

Marc,

On Oct 8, 2014, at 11:49 AM, Marc Binderberger <[email-masked]> wrote:
> production-ready for the Internet - great idea.

Sure.

> Beyond that I don't see a 

IP addresses allocated by the RIRs assume hierarchy to facilitate the scalability of the routing system.  LISP EIDs do not have any requirement for hierarchy. The policies and processes appropriate for the allocation of IP addresses do not appear to me to necessarily be applicable to the allocation of LISP EIDs.  If LISP is successful, whether the RIRs choose to become LISP EID allocators is likely a business decision they’ll need to make.  I personally do not think it appropriate to assume they will make that decision.

Regards,
-drc

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 8 Oct 2014 13:40:17 -0700

Hello Joel,

> It would seem to me to be rather odd to spend time working out an agreement 
> for what we want to do with a permanent allocation.  We are defining the 
> rules for the experimental allocation.

Good we have the same understanding on this topic :-)

> Is there a specific text change that would make that clear enough to 

Re-reading the document I think it's the mix of exact and more general 
statements in section 6 point 3 and section 7 that triggered my email. May I 
propose having simplified statements, a single place for the dates plus the 
reference to draft-ietf-lisp-eid-block-09, section 6 ?  E.g.:

   3.  EID Prefix Request (Mandatory)

       (a)  Prefix Size

       (b)  Prefix Size Rationale

       (c)  Lease Period

            +  Start Date

            +  End Date

            Note that the allocation lease period MUST end and allocations 
MUST
            be handed back (to IANA?) when the policy of this document becomes
            invalid. See section 7 for the timelines.

7.  Policy Validity Period

   Policy outlined in the present document is tight to the existence of
   the experimental LISP EID block requested in
   [I-D.ietf-lisp-eid-block] and valid until 31 December 2018.

   If the IETF decides to transform the block in a permanent allocation,
   the LISP EID block allocation policy in this document will be valid until
   31 December 2021.

   See also [I-D.ietf-lisp-eid-block], section 6, for more background.

(Btw, the dates in the existing document need an adjustment by +1 year. It 
talks about 31-December 2017 in a few places but the eid-block document talks 
about 31-December 2018)

More a cleanup than a change. No need to mention the discussions for the +3 
period; policies are either valid or not. The rules above also allow for a 
clean sheet after 31-Dec-2018 or 31-Dec-2021, with discretion to IANA/RIRs to 
re-assign or continue.

Another minor change could be in Section "2. Introduction" : it uses a few 
times the wording "allocation and assignment" but does not specify later on 
what it means with "assignment". For RIR the assignment is used address space 
while the allocation is just the range from which assignments are done. I'm 
fine if we simply remove "assignment" from this document.

Regards, Marc

>>> is

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 13 Oct 2014 12:53:20 +0200

Hi Marc,

thanks for your review.

May I summarise your the discussion as: the document should be cleaned up in a few points (listed below).

If I am correct, would it be OK to submit a new document (to be checked by the assigned shepherd) before moving to the IESG (if it passes the LC obviously)?

Will this collect your support for this document?

ciao

Luigi

---

From: Geoff Huston <[email-masked]>
Date: Tue, 14 Oct 2014 00:09:11 +1100

[cc's trimmed - they are all on the LISP WG mailing list in any case I'd guess]

Now that this box has been opened, and if we are discussing tuning these words, then
there is more that could be said. ...

If one of the objectives of this draft is to talk about the requirements of an EID registry,
using RFC5226 is an appropriate guide here.

with that in mind I have the following comments...

1. Avoid the use of "allocation" and "assignment" completely
----

So let me start with the easy one first. In the unicast address space we've managed to 
cloud the concepts of "assignment" and "allocation" with so much overloaded foo that
both terms are best avoided because of their confused and overloaded semantics.

So why not just avoid the use of such terms?

How about in the intro you say:

   The document [I-D.ietf-lisp-eid-block] requested an IPv6 address
   block reservation exclusively for the registration of
   EID prefixes for use in the LISP Experiment.  The rationale, intent, size, and usage of the EID
   address block are described in [I-D.ietf-lisp-eid-block].

   This document proposes a management framework for the registration of
   of EID prefixes from that block, allowing the requesting organisation
   exclusive use of those EID prefixes limited to the duration of the LISP experiment.

which attempts to completely avoid these two terms, and also attempts to use the
term "EID prefix" consistently in the place of various permutations of "EID"
"prefix" and "address"

Continuing with this there you could alter section 4 header to read:

"EID Prefix Registration Policy"

2. Avoid prescriptive registry policy in Section 4.
----

In reading through section 4, there are some words that appear to be overly specific
and overly prescription,. 

For example, you could strip out much of the motivational text in bullet 1 if you said"

1. EID Prefixes are available exclusively for use in the LISP experiment network, and
MUST NOT be separately announced as unicast prefixes outside the context of this 
routing scope of the LISP experimental network.

(i.e. place the onus of use on the party using the EID prefix, and don't try
and make the registry into a policy enforcement body, as that won't work.)

Similarly:

2. EID prefix registrations SHOULD be renewed on a regular basis to ensure their
       use by active participants in the experiment. The registration period is
       proposed to be 12 months. Registration renewal SHOULD NOT cause a change
       in the registered EID prefix. The conditions of registration renewal should
       no different to the conditions of registration.

Is the bullet about subdelegation really necessary? Really? This is a short term experiment. Try to keep the registry function as simple as possible if you want the experiment to succeed. Make it as complex as you can if you want to make the experiment as unattractive as possible. Omit 3.

section 4 and 5 contradict each other. You could simplify this by saying simply:

3. All registrations of EID prefixes cease at the time of the expiration of the experimental 
   LISP EID Block allocation. The further disposition of these prefixes and the associated
   registry entries is to be specified in the announcement of the cessation of this experimental
   allocation.

(ok I used the word "allocation" here - probably not good)

i.e define what we can define (what happens in the next 3 years, and what may happen in the
3 year renewal) but not try and specify what happens thereafter.

3. Avoid extraneous Registry policies in Section 4
----

Is item 6. REALLY a technical registry policy? Really? Or is is it an operational policy about the
way Map Servers interact with the EID prefix registry?

Similarly item 7.

Similarly item 8.

and remove 6, 7 and 8 and instead talk about a recycle time of no less than one week?

So the resultant Section 4 would, with a bit of reordering, look like:

4. EID Prefix Registration Policy

1. EID Prefixes are available exclusively for use in the LISP experiment network, and
   MUST NOT be separately announced as unicast prefixes outside the context of this 
   routing scope of the LISP experimental network.

2. EID prefix registrations SHOULD be renewed on a regular basis to ensure their
   use by active participants in the experiment. The registration period is
   proposed here to be 12 months. Registration renewal SHOULD NOT cause a change
   in the registered EID prefix. The conditions of registration renewal should
   no different to the conditions of the original EID prefix registration.

3. When a EID prefix registration is removed from the registry, then the reuse of the EID
   prefix in a subsequent registration on behalf of a different end user should be avoided
   where possible. If the considerations of overall usage of the EID block prefix requires
   reuse of a previously registered EID prefix, then a minimum delay of at least one week
   between removal and subsequent registration SHOULD be applied by the registry operator.

4. All registrations of EID prefixes cease at the time of the expiration of the experimental 
   LISP EID Block allocation. The further disposition of these prefixes and the associated
   registry entries is to be specified in the announcement of the cessation of this experimental
   allocation.

which is simpler, and I hope far clearer in intent.

4. Nits
---

I am sure that there are others, but this caught my attention:

"Policy outlined in the present document is tight to the existence of"

I think the authors meant "tied"

(Sections 5 and 6 have similar potential for simplification, but perhaps that's best
addressed in separate messages.)

thanks,

  Geoff

---

From: Geoff Huston <[email-masked]>
Date: Tue, 14 Oct 2014 00:27:00 +1100

As promised, here are some comments on Section 5

1. replace "Allocation" with "Registration"

As I noted in the last note, the terms "allocation" and "Assignment"
are hopelessly overloaded, and best avoided, as the distinction
is really irrelevant here,

    5.  EID Prefix Registration Requirements

2. are you talking about the registry or the registered end users?

reword the section as folllows:

   All EID prefix registrations should be made according to the
   following technical constraints:

   1.  All EID prefix registrations MUST use a globally unique EID prefix.

   2.  If there is more than one registry operator, all operators MUST use the
       same registry management policies and practices.

   3.  The EID Prefix registration information as specified in Section 6, MUST be collected upon initial registration and renewal, and made publicly
       available though interfaces allowing both retrieval of specific registration details (search)
       and enumeration of the entire registry contents.

(enumeration is a tricky topic - in an experimental context I think it helps with the experiment, but
your mileage may differ)

I suggest dropping 4 - it heads into over-specification, and this is not a services contract nor a SLA specification.

|   4.  The registration information service should be reasonably
|       reliable so to make such information readily available.  The
|       allocation service SHOULD be provided during regular business
|       hours in venue in which the allocation service is housed.

5 is ambiguous - do you want reverse or not? Lets say "yes"

   4.  The registry operator MUST permit the delegation of EID prefixes
       in the reverse DNS space to holders of registered EID prefixes.

6 is the "non-discrimination" clause isn't. Anyone can obtain a registration, on the understanding that the
prefix so registered is for the exclusive use in the LISP experimental network, and that their registration
details (as specified in section 6) are openly published in the EID prefix registry.

So why not say that?

    5. Anyone can obtain an entry in the EID prefix registry, on the understanding that the
       prefix so registered is for the exclusive use in the LISP experimental network, and 
       that their registration details (as specified in section 6) are openly published in the
       EID prefix registry.

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Tue, 14 Oct 2014 00:48:05 +1100

I also said that I had comments in section 6.

The comment relates to sections a and b of item 3 of the registration template - the prefix size.

The lack of guidance on specific prefix allocations in both the accompanying eid-block draft and this draft probably should be addressed. What we want is a balance between ease of access and the lack of imposition bureaucratic registry evaluation procedures and some statement of the expectation of restraint to allow all potential experimenters access to a registration in this block. 

One possible approach would be to state a default allocation size, and might I suggest that a /56 is an appropriate balance between utility and convenience and the considerations of the initial scale of this experiment. If the registrant is seeking a default size allocation (or smaller) then the template should note that no "rationale" would be necessary.

Another option (which I prefer) is to state that it is possible to request allocations of between a /64 to a /48, and that while the rationale would not be formally assessed by the registry, any allocation of larger than a /56 would require a rationale text, and this text would be part of the published registration. i.e. "no questions asked and no explanations given for a registration of a prefix of a /64 through to a /56, and an explanation would need to be provided for larger prefixes, and this explanation would be published (i.e. the justification becomes a justification to the other participants in the experiment as to why this particular participant believes that they require a larger prefix, rather than a justification to the registry operator) This would mean that the registry function is kept simple, presumably cheap (i.e. free) and accessible to experimenters of most shapes and sizes.

I'm not sure that the experiment details (section 4) are necessarily part of the registration process. 

here's an amended section 6 that incorporates these comments.

EID Prefix Registration template

Note that all details in this registration become part of the registry, and will be published in the LISP EID Prefix Registry

 1.  Organization (In case of individuals requesting an EID prefix
       this section can be left blank)

       (a)  Organization Name

       (b)  Organization Address

       (c)  Organization Phone

   2.  Contact Person (Mandatory)

       (a)  Name

       (b)  Address

       (c)  Phone

       (d)  Email

       (a)  Prefix Size

            Note that Prefixes from a /64 to a /48 may be registered.
            No rationale text is required for prefix sizes up to and including a
            /56. The rationale text will be part of the public registry of
            EID Prefixes.

            Note that the registration is for a 12 month duration, and must be
            renewed at the end of this period.
         
            Note that the registration will cease upon termination of the
            experimental LISP EID block allocation.. 
             
   4.  Reverse DNS Servers (Optional)

       (a)  Name server name:

       (b)  Name server address:

       (c)  Name server name:

       (d)  Name server address:

       (Repeat as necessary)

thanks,

  Geoff

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 13 Oct 2014 13:31:08 -0700

Hello David,

> for hierarchy. The policies and processes appropriate for the allocation of 
> IP addresses do not appear to me to necessarily be applicable to the 
> allocation of LISP EIDs.

That's interesting - where do you see a problem?
There is no aggregation today beyond the "RA allocation block". Assignments 
within the RA block do not have to follow any additional aggregation scheme 
(to be fair, depends on the internal routing setup details).

> scalability of the routing system.  LISP EIDs do not have any requirement 
> for hierarchy.

I actually think this statement in it's generic form is wrong.  This may be 
related to the impression I have that people on the list think they know in 
principle how LISP can solve the scale problem - at least from the published 
documents I think a lot of aspects have not been discussed at all.

> allocation of LISP EIDs.  If LISP is successful, whether the RIRs choose to 
> become LISP EID allocators is likely a business decision they’ll need to 
> make.  I personally do not think it appropriate to assume they will make 
> that decision.

If the goal is to run a separate LISP Internet then you may have a point. But 
I think officially we still aim at a LISP deployment that blends into the 
existing Internet.

To summarize my points again: as long as we talk about prefixes being 
announces in today's global BGP table I expect a definite end of the test and 
it's rules and a complete cleanup at the end of the test. Both is "somehow" 
written in the document but not as simple, clean & crisp as it could be, 
IMHO. Thus my proposal for some re-wording.

Regards, Marc

On Wed, 8 Oct 2014 13:12:03 -0700, David Conrad wrote:
> IP addresses allocated by the RIRs assume hierarchy to facilitate the 
> scalability of the routing system.  LISP EIDs do not have any requirement 
> for hierarchy. The policies and processes appropriate for the allocation of 
> IP addresses do not appear to me to necessarily be applicable to the 
> allocation of LISP EIDs.  If LISP is successful, whether the RIRs choose to 
> become LISP EID allocators is likely a business decision they’ll need to 
> make.  I personally do not think it appropriate to assume they will make 
> that decision.
> 
> Regards,
> -drc
>

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 15 Oct 2014 23:52:45 -0700

Hello Luigi,

my apology for the delayed reply.

Yes, I think the clean-up I propose and also Geoff is making some reasonable 
comments to avoid re-use of terms that may hit the nerve of people who work 
for or with RIR :-)

Plus the replies on this list made me more comfortable. I'm not against this 
experiment, quite the opposite, and thus are interested to have the documents 
and finally the experiment ready to go. I just wasn't sure about some of the 
wording and wanted to make sure this is understood as an experiment that has 
an end date and ends cleaned-up (from an Internet BGP point of view). You 
know, no "c'mon, it's just a couple of /48 in your table" :-)

(not being worried about the one /32 in the table)

Sorry when my feedback came late (my fault, I admit) and maybe a bit harsh. 
Looking forward!

Best regards,
Marc

On Mon, 13 Oct 2014 12:53:20 +0200, Luigi Iannone wrote:
> If I am correct, would it be OK to submit a new document (to be checked by 
> the assigned shepherd) before moving to the IESG (if it passes the LC 
> obviously)?
> 
>>> agreement 
>>>>> to
>>>>>> If this experiment would clearly terminate after 3+3 years then I 
>>>>>> would 
>>>>>> say
>>>>>> "allocation" is used throughout while "assignment" is only mentioned 
>>>>>> in 
>>>>>> the
>>>>>>> If

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 21 Oct 2014 12:41:25 +0200

Hi Geoff,

thanks for the thorough review (as usual from you ;-) ).

Due to comments from you and Marc the authors think would be better to stop the Last Call now. Update the document and restart it later.

The comments you both provided do not change the nature of the document, they are mostly wording. 
Yet, they are numerous, hence better to write them down before going any further otherwise confusion will reign.

Thanks

Luigi

> On 13 Oct 2014, at 15:48, Geoff Huston <[email-masked]> wrote:
>