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

[Terry Manderson <[e-mail]>]

With my WG chair (wizards) hat on.

I would like to remind the entire LISP list that the focus of these
particular documents is to be wholly about the technical 'how', not the
who.

This working group (as also confirmed with a offline discussion with the
responsible AD) does not have the latitude to discuss or define "who".

I'm sure all of you have opinions on the latter, however I have not yet
seen any tangible document outcomes based on this discussion to improve
our universal understanding on 'how'. Diving into these (dare I say)
rat-holes at this stage is not conducive to productive outcomes.

To restate - "who" is not open for discussion. Please keep to the
technical specification of 'how'.

Thanks
Terry

On 13/03/13 7:43 PM, "John Curran" <[e-mail]> wrote:

>On Mar 12, 2013, at 11:29 PM, David Conrad <[e-mail]> wrote:
>> 
>>> Each
>>> region has its own approach and policies regarding
>>>provider-independent IPv6
>>> space, and issuance of IPv6 space (particularly on a flat-basis) via a
>>>new 
>>> process is likely to raise questions which need discussion.
>> 
>> And this regionalization is part of the issue: what would happen if the
>>outcome of that "discussion" is that an RIR refuses (for whatever
>>reason) to allow LISP experiments?
>
>Indeterminate at this time.
>
>By RFC 2860, the IAB has final say in these matters (e.g. is the EID
>prefix
>an experimental assignment, etc.), and the IANA shall follow its
>direction. 
>
>By ICANN's mission and core values in coordination of IP addresses, it may
>come down to a judgement call of whether affected parties have had
>adequate 
>opportunity to participate in the decision making in accordance with
>their 
>policy role, and whether the results would be in the "public interest"...
>(and there are also some related obligations on ICANN due to both the USG
>NTIA IANA Function contract and the ASO MOU signed with each of the RIRs.)
>
>In any case, irreconcilable disagreement between IAB/IETF and ICANN on
>such
>a matter "would be bad" (major understatement) for the Internet ecosystem.
>
>The good news is that we rarely end up in such situations... it's not much
>different than when AD's on the IESG have a disagreement, or when a global
>address policy being discussed at the RIRs has different text; in all
>cases,
>the result is more engagement and discussion to gain better understanding
>of everyone's concerns, with the goal of addressing them where possible
>and fully understanding them but deciding otherwise when not possible.
>
>In fact, there's actually a very good track record here between the folks
>in the IETF working groups and folks in the RIR communities; some
>examples 
>include RFC 3849, RFC 6598, etc.
>
>>> If EID prefixes are allocated
>>> on a simple flat basis, and might be used also as IPv6 blocks, then
>>>they do
>>> not have the same property if expansion is needed for their IPv6
>>>usage. Is
>>> this a problem?
>> 
>> Wouldn't this concern be trivially addressed by having the EID
>>allocator hand out EIDs using the same "sparse-mode" algorithm the RIRs
>>are using?
>
>I imagine so, but presently there's no way to know if that being proposed
>or
>not...  Similarly, there is work in areas such as reverse DNS/DNSSEC,
>RPKI,
>whois/crisp/weirds being done (protocols at the IETF, and implementation
>by
>the RIRs and the IANA team at ICANN) for which an additional set of
>end-user 
>IPv6 assignments (via the EID prefixes) could have implications. I doubt
>there 
>are any real problems here, but the need for coordination is quite real.
>
>>> I have no idea, but definitely want to make sure that the
>>> ISPs who felt it was important in the various regional discussions
>>>have a 
>>> chance to consider this new potential with any EID prefix assignment
>>>plan.
>> 
>> To be honest, it sounds like you mean "veto" instead of "consider".
>
>Read above... "coordination" is probably the most appropriate term.
>
>> This would be distressing since one of the long term promises of LISP
>>would be routing system scalability. Of course, from an ISP's (that is,
>>the folks you claim to a "liaison" for) perspective, LISP has the
>>downside that it facilitates end site provider independence so there
>>would be good reason to try to veto LISP experimentation.  Not that I'm
>>actually so cynical to think that's the reason for your concerns... :)
>
>Personally, I am a huge advocate of exploring new approaches to managing
>routing system growth - our indirect approach of relying primarily on
>provider-based hierarchical address assignments as a control knob on
>routing table size has performed adequately in the past, but we have no
>assurance that it is up to the job going forward.  I'll also note that
>regional policy has generally tended towards more access to provider-
>independent IPv6 assignments, but there are variations in the regions
>and suddenly having them universally available in traditional IPv6
>routing without some other feedback system on routing table growth is
>not without risks.
>
>LISP's loc/eid separation provides a rational way to segment the routing
>problem and thus has allowed real focus on the scalable mapping problem.
>(I speak firsthand, as I have been advocating for eid/loc split since
>back 
>in 1992 with draft-curran-tune-00, and as well looking at alternatives
>for 
>EID mapping back in LISP's early days with draft-curran-lisp-emacs-00...)
>
>However, despite LISP's wonderful end-state and all of our advocacy for
>it, we also have to make sure that the deployment of EID prefixes does
>not cause problems for the existing operators, many of who have worked
>diligently through the RIRs to adopt specific policies for how IPv6
>prefixes are issued. I do not claim to know how EID prefixes (which
>may also be used as IPv6 prefixes in the traditional routing system)
>will impact these folks, but do believe that they have a right to be
>told what is being proposed so that there is an ability to ponder the
>implications and have their input considered in the discussion.
>
>> More seriously, I agree that the experiment needs to be documented
>>along with its potential implications and termination conditions and I'm
>>more than happy to contribute.
>
>While committing such information to paper does take a bit of effort,
>it both allows for informed consultation with the greater community and
>therefore is very important in avoiding surprises for existing operators.
>
>FYI,
>/John
>
>Disclaimers: My views alone.  Relations in this email are complex with
>             no user-serviceable parts inside - open with caution.
>_______________________________________________
>lisp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/lisp