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

From: John Curran <[email-masked]>
Date: Tue, 12 Mar 2013 14:07:10 -0400

On Tue, 05 Mar 2013 12:40:43 -0800, Joel M. Halpern wrote:

> Is there a way to structure things with unified, automated, assignment now, but the ability to split along this and other dimensions later? (We don't even need to spell out the split, just be confident we can do it if we want to.

This particular approach looks to be the worst of all worlds, in that you'll have 
a deployed solution which requires significant effort and coordination to handle 
the split, and no clear reason to actually make the changes since everyone is
just fine with interim state (hmm...kinda like the first 15 years of IPng ;-)

If the requirements for doing this call for a registry/registrar split, and it's likely
that whatever we're about deploy will end up in permanent use, why wouldn't we 
specify it correctly up-front?  (i.e.  back to my earlier question: is there some 
imminent failure of the present LISP Beta solution for issuing EID prefixes that 
precludes taking the time to do this right?)

/John

Disclaimers: My views alone. No parameter fields were harmed in the making
                   of this email.

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Mar 2013 15:52:41 -0700

> just fine with interim state (hmm...kinda like the first 15 years of IPng ;-)

I personally continue to believe that doing a registry/registrar split for EIDs at this point of time would be making things _way_ too complicated for the level of deployment LISP has enjoyed to date.  It's sort of like trying to jump from RFC 883 DNS to ICANN without going through the RFC 1034/1035 (et al.) and SRI-NIC->DDN NIC->GSI->NetSol->VeriSign->IAHC->White/Green Paper->NewCo steps first.

I also feel even going down the RIR route is far too heavyweight, even ignoring the implications of regionalization.  Saddling LISP EID allocation with unnecessary bureaucracy, complexity, and regional politics will simply discourage/delay experimentation and/or adoption.

At this stage of the game, I believe a simple, unified and centralized registry with a straightforward non-discriminatory allocation policy is quite sufficient. If folks are uncomfortable with the scalability of that model, adding text that describes an evolutionary plan (that could include a registry/registrar split) should the centralized registry be unable to cope with demand might make sense, but I don't think we need to do much more that document the plan.

Regards,
-drc

---

From: John Curran <[email-masked]>
Date: Tue, 12 Mar 2013 19:21:37 -0400

> At this stage of the game, I believe a simple, unified and centralized registry with a straightforward non-discriminatory allocation policy is quite sufficient. If folks are uncomfortable with the…

I haven't heard the registry/registrar approach discussed for "scalability" but as 
a protection against arbitrary/non-representative fees increases. This is avoided 
with the RIRs by being membership organizations with elected boards; another way 
is the registry/registrar model where the ability to switch registrars provides 
a form of protection via market incentives.

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. 

FYI,
/John

Disclaimers:  My views alone.  Concepts may be larger than they appear.

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Mar 2013 16:36:04 -0700

John,

On Mar 12, 2013, at 4:21 PM, John Curran <[email-masked]> wrote:
> a protection against arbitrary/non-representative fees increases.

The registry/registrar split allows for a partitioning of services in addition to providing competition that can tend to reduce fees and allow for people to vote with their feet (something the existing RIR system does not permit of course).

> This is avoided with the RIRs by being membership organizations with elected boards;

Not really (particularly given the RIR memberships don't set fees), but this is the wrong venue to go down this rathole.

> usage and a complete lack of viable alternatives. 

I dunno -- IANA seems to have done pretty well with the 1000+ protocol parameter registries they manage with lightweight oversight by the IETF/IESG.

Regards,
-drc

---

From: John Curran <[email-masked]>
Date: Tue, 12 Mar 2013 19:47:39 -0400

> I dunno -- IANA seems to have done pretty well with the 1000+ protocol parameter registries they manage with lightweight oversight by the IETF/IESG.

Indeed.  While I don't believe any of the parameter registries are as 
widespread and pervasive as what is intended with EIDs, there is no 
reason to believe such scale isn't achievable.  I was only noting that
the reasons expressed on the list for having a registry/registrar split
included more than just "scalability".

FYI,
/John

Disclaimers: My views alone. This email sold by conceptual weight not volume.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Mar 2013 17:05:19 -0700

Okay, we need to reset this thread. A little history:

(1) I originally suggested to request IANA for a well known /12 prefix that was known to be an EID prefix where you could be guaranteed to have xTRs deployed at the site.

(2) I requested this so when a packet hits an xTR at a LISP site with a destination address not in the /12, AND a configuration knob was set, the packet could be routed natively to the non-LISP destination site.

That is all I wanted out of the /12. It was a way to make LISP to non-LISP communication avoid a mapping database lookup that would yield an answer of "destination is not LISP", which the well-known prefix would tell us right away (yes, by hard coding it).

The thread has wandered into:

(1) How will registries allocate and how will sites get EID-prefixes. 

(2) How can LISP succeed without such coordination EID allocation.

(3) If this is experimental versus production.

Where in fact, any address today can be used as an EID-prefix by simply allowing an xTR to look it up (the configuration knob above is not set) to determine if there are xTRs at the site. This is why I keep saying there is no requirement for RIRs to allocate EID-prefixes.

Dino

On Mar 12, 2013, at 4:47 PM, John Curran <[email-masked]> wrote:

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

---

From: John Curran <[email-masked]>
Date: Tue, 12 Mar 2013 20:29:29 -0400

> Where in fact, any address today can be used as an EID-prefix by simply allowing an xTR to look it up (the configuration knob above is not set) to determine if there are xTRs at the site. This is w…

Dino - 
 
  Presuming the EID block were issued, would the "EIDs are in f00/12" knob 
  be a site-local setting or would it be the default for EID architecture?
  One of interesting aspects of EID space is its overlap with IPv6 space, 
  and hence I was wondering if the long-term plans are for formally disjoint 
  spaces?  (Absent that, issuance of EID prefixes implies issuance of IPv6 
  space, which has some policy implications for the existing address 
  registry system, and is probably why several folks on the list keep 
  noting the need to liaison with the ISP community via the RIRs...)

/John

Disclaimers: My views alone.  Headers are not to be removed 
             except by final consumer.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Mar 2013 17:47:21 -0700

>  be a site-local setting or would it be the default for EID architecture?

Per ITR yes. 

>  and hence I was wondering if the long-term plans are for formally disjoint 

So here is my definition of the separate spaces, which I think is technically correct:

If a prefix is advertised by a site into BGP (versus injected into BGP by a PITR), the prefix is a RLOC prefix. 

Else, if the prefix is registered to the mapping database system, then the prefix is an EID-prefix. 

Else, the prefix is either unallocated or allocated and not used. 

This is for a IPv4 and IPv6 prefixes. For MAC addresses or any multi-Tue extended EID, there are other rules. 

>  noting the need to liaison with the ISP community via the RIRs...)

So an RIR allocated prefix can follow the above rules. 

And an IANA allocated prefix can follow the above rules. 

And within a closed network, a private address can follow the above rules. 

Dino

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Mar 2013 17:55:00 -0700

John,

On Mar 12, 2013, at 5:29 PM, John Curran <[email-masked]> wrote:
> (Absent that, issuance of EID prefixes implies issuance of IPv6 

I believe that according to RFC 2860, the IETF is responsible for the allocation of blocks of addresses (IPv4 or IPv6) used for experimental purposes, not the RIRs.

I also suspect that a number of ISPs might object to the idea that the way to liaison with them would be through the RIRs.

Regards,
-drc

---

From: John Curran <[email-masked]>
Date: Tue, 12 Mar 2013 21:10:01 -0400

> I believe that according to RFC 2860, the IETF is responsible for the allocation of blocks of addresses (IPv4 or IPv6) used for experimental purposes, not the RIRs.

Definitely the case, although it would probably be best to confirm the 
same understanding of "experimental purposes" (i.e. it is very hard to 
tell if a 10 year project doing assignments which has the potential to
become permanent would qualify; it likely doesn't even conform to the 
IETF's own best practices on experimental assignments in RFC 3692.)

In any case, one of the important parts of ICANN's mission is coordination, 
and it would be hard to fulfill that particular role while issuing IPv6 
prefixes at large without some degree of consultation with the greater 
community.

FYI,
/John

Disclaimers: My views alone.  Not for use as an ice-cream topping.

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Mar 2013 18:58:23 -0700

John,

On Mar 12, 2013, at 6:10 PM, John Curran <[email-masked]> wrote:
> same understanding of "experimental purposes"

Agreed.

> prefixes at large without some degree of consultation with the greater 

Again, my understanding of RFC 2860 is that it is the IETF's role to specify address blocks that are to be used for experimentation purposes and ICANN, in its role as the IANA Functions Operator, would be obliged to allocate/register the block and ensure it isn't re-allocated before the experiment terminates. Do you have a different interpretation of ICANN's role in these sorts of situations?

More to the point, what further coordination by ICANN (or the RIRs) do you believe is necessary/beneficial for a block of IPv6 addresses to be used for EIDs in LISP protocol experiments?

Thanks,
-drc

---

From: John Curran <[email-masked]>
Date: Tue, 12 Mar 2013 22:17:13 -0400

> More to the point, what further coordination by ICANN (or the RIRs) do you believe is necessary/beneficial for a block of IPv6 addresses to be used for EIDs in LISP protocol experiments?

If the EID assignments have potential to impact the ISPs currently using IPv6
(e.g. if such assignments might also end up being used as provider-independent
IPv6 blocks by their recipients and show up in the IPv6 routing table), then 
discussing this with the community in advance is probably a good thing.  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.  I frankly have 
no idea of whether there would be any real issues or not, but do think that 
writing up what is intended in enough detail so it can be considered is very
important.

One tiny example: to minimize long-term growth in IPv6 routing table size, 
issuance via "sparse-mode" has been done in most cases, whereby space is 
reserved for future adjacent growth.  Lots of discussion took place about
this, and it is now a fairly common practice.  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?  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.

That's what I mean by saying "coordination"...

/John

Disclaimer: My views alone. Yeah, with nobody else.

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Mar 2013 20:29:15 -0700

John,

On Mar 12, 2013, at 7:17 PM, John Curran <[email-masked]> wrote:
> discussing this with the community in advance is probably a good thing.  

My impression (others will correct me if I'm mistaken) is that as part of a transition phase, it would be helpful (required?) if EIDs were routed to enable end sites which have not yet deployed LISP to be able to communicate with sites that have deployed LISP.

Maybe(?) something like NPT could be used to ensure that prefixes from the EID experiment block don't cause folks' IPv6 routing tables to overflow, but I'm not sure pushing NPT to get around RIR politics is the best idea.

> Each
> 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?

> this, and it is now a fairly common practice.  

I'd hope so since the IPv6 /12 allocations to the RIRs by IANA were made with the assurance from the RIRs that they'd be allocating that space via "sparse-mode" (but I digress).

> If EID prefixes are allocated
> 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 have no idea, but definitely want to make sure that the

To be honest, it sounds like you mean "veto" instead of "consider". 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... :)

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.

Regards,
-drc

---

From: John Curran <[email-masked]>
Date: Wed, 13 Mar 2013 05:43:33 -0400

> 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.

> 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.

> 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.

---

From: Terry Manderson <[email-masked]>
Date: Wed, 13 Mar 2013 05:47:15 -0700

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" <[email-masked]> wrote:

>> 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?
>
>> 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?
>
>> 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... :)
>
>> 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.
>

---

From: John Curran <[email-masked]>
Date: Wed, 13 Mar 2013 09:59:17 -0400

> technical specification of 'how'.

Acknowledged, and this approach makes perfect sense.

The question on the table is "how" to manage the EID prefix proposed in 
[I-D.ietf-lisp-eid-block].  I posed two questions yesterday that would
help clarify the scope of this task, and I believe (based on the rambling
discussion on the list) that some progress has been made on both of them,
but obviously would like to hear from others on their views:

> 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.

I believe that Dino clarified that it is not, per se, aspects of the
current EID management that creates a need for the EID prefix, but a
potentially significant architectural benefit of being able to create
a knob which could avoid numerous mapping lookups for non-LISP Internet
destinations.  No one has otherwise indicated that we're facing some
form of collapse in the current EID management, which would imply that
there is enough time for a thorough considerations of the requirements.
(if this is incorrect, someone should speak up on this point.)

> 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.

This question remains open and is fairly important to resolve before 
proceeding.  The degree of rigor put into "how" we manage the proposed
EID block is likely going to vary widely depending on whether the 
"experiment" actually can be shutdown after years of deployment.  If
folks have decided not to use LISP, then its fairly simply, but should
LISP be as successful as hoped 10 years from now, then this "experiment"
will be the production approach to managing the EID block.  Add in 
consideration of 10 years worth of sites setting the "outside /12
is traditional Internet" mapping flag, and it's clear that deploying
LISP using some other space (e.g. via traditional IPv6 prefixes) will 
not even be an option.  It is also quite uncertain how or whether any
operational services provided by the "experimental" EID registry could 
safely transitioned to a new management model without endangering 
existing EID users in the process.

In light of that outcome, if there is any reason not to take the time to 
fully plan out the management approach as the initial _production_ solution 
(not experimental), then it has not been expressed on the mailing list. 
The last time we set to do something so fundamental and left major pieces 
as future work was with IPv6 and its transition plan [RFC 1752] (and I 
very much doubt we want to repeat that particular success.)  Since we are 
actually establishing the management approach for the identifier space 
of the future Internet, the task should be scoped accordingly and the 
"how" should be fully considered and spec'd as the long-term solution.

FYI,
/John

Disclaimers: My views alone. Steep precipice ahead - look down with care.