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

[Marc Binderberger <[e-mail]>]

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:
> 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
> 
> 
> 
> On 08 Oct 2014, at 22:40, Marc Binderberger <[e-mail]> wrote:
> 
>> 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 
>>> alleviate your concern?
>> 
>> 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
>> 
>> 
>> 
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 10/8/14, 2:49 PM, Marc Binderberger wrote:
>>>> Hello Joel,
>>>> 
>>>>> 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.
>>>> 
>>>> 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
>>>> 
>>>> 
>>>> 
>>>>> On 10/8/14, 2:15 PM, Marc Binderberger wrote:
>>>>>> 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:
>>>>>>> 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
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> lisp mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>