Subject: [lisp] draft-ietf-lisp-eid-block-03.txt back in workgroup

From: Terry Manderson <[email-masked]>
Date: Mon, 7 Jan 2013 22:03:45 -0800

Workgroup and others,

Donning the brightly coloured LISP Chair hat.

The document draft-ietf-lisp-eid-block-03.txt was handed back to the
Workgroup and the document editors following the IETF last call. The LC
prompted interesting feedback and highlighted some issues.

The Responsible AD and the LISP chairs have discussed the future of this
document. We believe that the future of this document could be best served
by splitting it in two (one that allocates/justifies the prefix, and one
that describes the LISP specific allocation mechanism) and also altering
text to address the concerns raised during the IETF LC.

However, before the WG starts to rework the document, I would first like to
canvass the LISP WG as to your opinions.

1) Should we, as a WG, continue to work on this item? Is it necessary/useful
for LISP? 

2) If so, what direction should the WG take this document so that the LISP
experiment is best served?

I'd also like to call on those folks (as Brian did) who offered review of
this document (CC'd here) during the IETF last call to participate on the
LISP mailing list as to its future.

Cheers
Terry

---

From: Sander Steffann <[email-masked]>
Date: Tue, 8 Jan 2013 09:23:33 +0100

Hi,

> 1) Should we, as a WG, continue to work on this item? Is it necessary/useful

Yes, I think it can be very useful for LISP.

> experiment is best served?

What I was missing from the text was:
- justification for the size of the prefix
- allocation mechanism (AFAICT unaggregated /48 per end-site was intended)
- description on how to use this prefix
- short-term routing strategy / impact on routing table
- long-term routing strategy / impact on routing table
- migration path between them

I think that allocating a prefix without describing how it is going to be used is a bad idea for something as important as LISP. I'm not sure if that should be documented in one, two or more documents...

> LISP mailing list as to its future.

Of course! :-)
Sander

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 8 Jan 2013 11:22:55 +0100

> text to address the concerns raised during the IETF LC.

May I dare to ask why? 
Doesn't make more sense to have everything in one single document? 
Is not that I am against, is just that I want to understand what is the specific gain the WG will have by splitting the document.

> 1) Should we, as a WG, continue to work on this item? Is it necessary/useful

I still think that having a reserved prefix can be useful.

> experiment is best served?

If the WG provide consensus on working on the document the main task IMO is to document the allocation mechanism.

Luigi

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

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 8 Jan 2013 11:29:32 +0100

> Yes, I think it can be very useful for LISP.

+1

> - allocation mechanism

Agreed.

> (AFAICT unaggregated /48 per end-site was intended)

Not that I remember...

> - description on how to use this prefix

Can be improved… I agree.

> - long-term routing strategy / impact on routing table

I think that "routing strategy" is something falling in the "how to use the prefix".

Impact on the routing table … depends on "how to use the prefix" ;-)

> - migration path between them

Good point.

> I think that allocating a prefix without describing how it is going to be used is a bad idea for something as important as LISP. I'm not sure if that should be documented in one, two or more documents…
> 

I still prefer having a single document to read.

ciao

Luigi

---

From: SM <[email-masked]>
Date: Tue, 08 Jan 2013 02:34:57 -0800

Hi Terry,
>1) Should we, as a WG, continue to work on this item? Is it necessary/useful

The work item seems useful.

>experiment is best served?

The problem is justifying the IP address space allocation and 
explaining how it will be managed.

My guess is that the working group took an ORCHID approach (copy and 
paste :-)).  I suggest dropping the idea of calling it a very 
large-scale experiment.  The unstated problem is about politics.  I 
suggest taking a look at draft-lear-lisp-nerd-09.  It contains a good 
discussion of operational models and the trade-offs.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jan 2013 13:30:14 +0000

> I think that "routing strategy" is something falling in the "how to use the prefix".

Maybe, but it is a major sub-section. This is the area that got me worried
enough to comment on the draft - especially, why non-participants in the
LISP experiment would propagate the prefix. At least, before arguments such
as "This is the only way to reach Facebook" can be used.

>> - migration path between them

Essential point, I'd say: how does this prefix behave around the tipping
point between "a few sites use LISP" and "most sites use LISP"?

    Brian

---

From: Geoff Huston <[email-masked]>
Date: Wed, 9 Jan 2013 06:21:04 +1100

On 08/01/2013, at 9:34 PM, SM <[email-masked]> wrote:

> The problem is justifying the IP address space allocation and explaining how it will be managed.
> 
> My guess is that the working group took an ORCHID approach (copy and paste :-)).  I suggest dropping the idea of calling it a very large-scale experiment.  The unstated problem is about politics.  I suggest taking a look at draft-lear-lisp-nerd-09.  It contains a good discussion of operational models and the trade-offs.
> 

I was on the IAB at the time that ORCHID was being considered - the issue there was to find a balance between enough bits for acceptable crypto and basic conservatism in the absolute size of the request - at the time a /28 appeared to be a suitable compromise considering that this was an experiment.

Given that this is an experiment and that the transition from experiment to widespread deployment may well entail renumbering (as was the case with the 6bone) then one approach may well be to use a modest prefix that has a limited capacity that would force renumbering in the shift from experiment to widespread adoption, if such occurs in the future.

Geoff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Jan 2013 19:22:17 -0500

Commenting just on this one piece, the reason for suggesting separating 
the two pieces has two components, as I understand the situation.
1) There is a belief that it would be helpful to get the prefix soon.
2) working out, ad then clearly documen, the plan for LISP EID 
assignment / delegation still needs significant work, and is not likely 
to complete quickly.

If these two observations are both accurate, then separating the 
problems seems the only path that meets the goals.  If we do not need to 
get the prefix allocated quickly, then I would tend to strongly favor 
working out the rest of the system, delegation, allocation, and usage so 
that we know how all the parts work.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Jan 2013 16:43:41 -0800

I recently visited University of Minnesota where I met David (copied on this email). He said, from an RIR perspective, he would help us revise this draft.

Luigi meet David. David meet Luigi. David can comment but he felt we could get a coarse prefix if we just justified how it would be used and would help us write text.

Dino

---

From: George Michaelson <[email-masked]>
Date: Wed, 9 Jan 2013 11:16:45 +1000

> 1) Should we, as a WG, continue to work on this item? Is it necessary/useful

EID might not be addresses in LISP terms, but you are using IPv6 addresses, which come with expectations over the management and behaviour.

I think that its appropriate for LISP to identify address management requirements and expectations. I think it goes to question 2)

	are these EID intended to be individually routed in global-unicast BGP view, or only visible as an aggregated prefix?

	how many EID do people need? do EID have to aggregate, is there any benefit in EID being more than just unique (ie, unique and growable, or unique and large/medium/small)

for instance.

> experiment is best served?

If you are explicitly addressing this as an EXPERIMENT then you should objectively address the experimental allocation criteria, which are that you justify why it cannot fit inside a /32, and recognise that its a time limited allocation, subject to some kind of renewal.

	How many participants in the EXPERIMENT are you trying to cope with?

	How large an EID does each participant need? whats the scaling?

If you are attempting to address larger deployment scaling which go beyond the experiment life, the issues around what KIND of allocation policy applies need to be explored:

	what objective criteria are expected to be applied, to allocate EID to entities? 

	is the sole property uniqueness?

> LISP mailing list as to its future.

Noted.

-G

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 9 Jan 2013 12:57:33 +0100

On 9 Jan. 2013, at 01:22 , Joel M. Halpern <[email-masked]> wrote:

> Commenting just on this one piece, the reason for suggesting separating the two pieces has two components, as I understand the situation.
> 2) working out, ad then clearly documen, the plan for LISP EID assignment / delegation still needs significant work, and is not likely to complete quickly.

Hi Joel,

don't we risk to have the first document blocked until the second is finished?

Most concerns during LC were about "why to allocate a prefix if we do not know how to use it?". 

From my understanding even having the prefix today it will not be possible to use it until document 2 is out as well. 

What am I missing?

Luigi

> 
> If these two observations are both accurate, then separating the problems seems the only path that meets the goals.  If we do not need to get the prefix allocated quickly, then I would tend to strongly favor working out the rest of the system, delegation, allocation, and usage so that we know how all the parts work.
> 
> Yours,
> Joel
>

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 9 Jan 2013 13:02:01 +0100

Hi Geoff,

> Given that this is an experiment and that the transition from experiment to widespread deployment may well entail renumbering (as was the case with the 6bone) then one approach may well be to use a…

I may be mistake but I do not see the renumbering need in the LISP case.
The prefix request was written in such a way to reduce renumbering, rather making the prefix "bigger" so to accommodate the growth. This would also be an easy change, rather then adding different prefix blocks just change the length of the existing prefix.

I think this is something to keep in the future document(s).

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 9 Jan 2013 13:04:18 +0100

Hi,

On 8 Jan. 2013, at 11:34 , SM <[email-masked]> wrote:

> My guess is that the working group took an ORCHID approach (copy and paste :-)).

Not really, truth is that it was suggested to look at ORCHID, hence we tried to provide the same elements (or equivalent) that the ORCHID document provided.

>  I suggest dropping the idea of calling it a very large-scale experiment.  The unstated problem is about politics.  I suggest taking a look at draft-lear-lisp-nerd-09.  It contains a good discussion of operational models and the trade-offs.
> 

Thanks a lot, will do.

ciao

Luigi

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Jan 2013 14:00:05 +0000

Hi,

> On 8 Jan. 2013, at 11:34 , SM <[email-masked]> wrote:

...
>>  I suggest dropping the idea of calling it a very large-scale experiment.  The unstated problem is about politics.  I suggest taking a look at draft-lear-lisp-nerd-09.  It contains a good discussi…

However, it isn't (even) a LISP WG Experimental document.

I think the interesting operational questions are those raised or
implied by http://tools.ietf.org/html/draft-ietf-lisp-interworking-06#section-5

> Thanks a lot, will do.

What I would like to see discussed in -eid-block is how the use
of the proposed prefix interacts with the scaling properties and
routing policies associated with Proxy ITRs. The above citation includes:

   1.  The Proxy-ITR's aggregate routes might be selectively announced,
       giving a coarse way to control the quantity of traffic attracted
       by that Proxy-ITR.  For example, some of the routes being
       announced might be tagged with a BGP community and their scope of
       announcement limited by the routing policy of the provider.

   2.  The same address might be announced by multiple Proxy-ITRs in
       order to share the traffic using IP Anycast.  The asymmetric
       nature of traffic flows through the Proxy-ITR means that
       operationally, deploying a set of Proxy-ITRs would be very
       similar to existing Anycasted services like DNS caches.

Will having a reserved EID prefix change these "might bes"? Will it
change the incentives for BGP ASes to do the right thing? As was said
earlier, we have *bad* experience on this point with 2002::/16, where
the evidence is that operators simply didn't do what the deployment
model called for. Just to be clear, here is the paragraph from RFC 3056
that operators failed on:

   3. A relay router MUST advertise a route to 2002::/16 into the native
   IPv6 exterior routing domain.  It is a matter of routing policy how
   far this routing advertisement of 2002::/16 is propagated in the
   native IPv6 routing system.  Since there will in general be multiple
   relay routers advertising it, network operators will require to
   filter it in a managed way.  Incorrect policy in this area will lead
   to potential unreachability or to perverse traffic patterns.

You could pretty much use that paragraph for LISP ITRs. Why will it work
any better than it did for 6to4?

To be clear - we aren't talking about operators of ITRs. We're talking
about BGP speakers many hops away from the ITRs.

   Brian

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 09 Jan 2013 09:55:29 -0500

As I understood it, if we say explicitly that allocation and policy will 
be dealt with in a separate document, folks thought that would fly.  It 
might not.
But if it won't, then there is no way we can do this quickly.

Which brings us back to Terry's key question to the WG:  Is this 
something iportant for us o produce now.  If so, why?

Yours,
Joel

---

From: Geoff Huston <[email-masked]>
Date: Thu, 10 Jan 2013 07:57:01 +1100

> I may be mistake but I do not see the renumbering need in the LISP case.

It all depends on the philosophy behind experimental allocations. If we were to assume that each and every single experiment in IPv6, including all forms of cryptographically generated addresses, all forms of transitional mechanisms, all forms of address plans and all forms of routing experiments were each to request an experimental allocation that was "once and forever" and assumed at the outset that the experiment would result in comprehensive deployment over a network many many times larger than today's then I hope you can appreciate that we'd not have enough space to accommodate each and every experiment's requirements in the IPv6 space.

So the conventional philosophy behind experimental allocations is to use enough space to allow the experiment to operate and to gain experience with the technology. If this proves to be useful and taken up by the industry (and of course this process involves is by no means an assured outcome - quite the opposite in fact) then its again conventional to look at how to support the technology within the existing token distribution framework, or whether its appropriate to make changes to the token distribution framework. Now obviously some proponents of every experiment see universal adoption of their particular technology as a given, including some LISP proponents no doubt. So of course we see many (most?) experiment proponents proudly proclaim that they are uniquely different and obviously their particular experiment will naturally result in universal deployment, so why not assume that happy outcome at the outset of the experiment and allocate resources at a scale commensurate with their no doubt certain universal deployment in the not-so-distant future? But wishing it, no matter how enthusiastic you may be personally, does not make it so. A prudent approach in a space that has seen, and is likely to see, many experiments proposed, is generally to provision resources to conduct the experiment at the scale of the experiment and if the experiment leads to someplace positive then look at what is required if the technology is to head to larger levels of deployment.

> The prefix request was written in such a way to reduce renumbering, rather making the prefix "bigger" so to accommodate the growth. This would also be an easy change, rather then adding different p…

I am continually confused by the assumptions behind this assertion, and I've heard this assumption a number of times in the course of the consideration of this draft. If LISP is so fragile that it requires a very particular deployed address structure in order to operate, then frankly we could do precisely the same in BGP and achieve better results because of avoidance of tunnelling. I find it somewhat strange to see this adamant view that LISP absolutely requires a uniquely structured address plan in order to achieve any useful outcome in terms of scalable routing, at a cost of increased latency and exposure to vagaries of tunnel behaviour, while at the same time ignoring the simple observation that if one were to do the same surgery on the address plan in BGP the outcomes would likely to be just as good if not better, without the negative factors of map-resolution-related latency and tunnelling.

> I think this is something to keep in the future document(s).

And I strongly disagree with your opinion. If we did this for every experiment that we encounter that proposes some unique address plan that is intended to improve security, routing scaleability, auto-configuration, pre-provisioning, network virtualization, software programability, etc etc, then once more we are going to find ourselves contemplating address exhaustion in IPv6 far sooner than anyone would've rationally anticipated.

Geoff

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 9 Jan 2013 22:02:21 +0100

I'll remove myself from the cc since I'm on lisp@ :-)

I have tried to write down one way to get this done in a way that
handle most aspect. First a summary  since this is a very long email.
The size of the address blocks are a suggestion from my side.

* we reserve a /12
* LISP EID block are marked as EXPERIMENTAL with a time limit, let's
say 7year, until 10.October 2020 (not random picked, but 10.10.2020
seems nice).
* set aside one /16 for each RIR
* out of this /16 _only_ upto /26 split into /32 (64 for each RIR
region) can be can be handed out and announced into the global routing
table. If someone need something more than /32 they should really come
up with a very good reasons now or just ask for regular RIR space
* before 1.January 2019 IETF will have to decide if the EXPERIMENTAL
was a success or a failure.
** If failure the entire address block are taken back before 31.Nov
2020, filtering etc like 6bone.
** If a success, we remove the 64 /32 (/26) limit and each RIR can
hand out LISP EID space from the above /12 in their region, much like
regular space.
* in the EXPERIMENTAL phase (until 31.November 2020)  one RIR/entity
keep track of the above /32 and a LISP-EID-wg decide and make up the
procedures for how this should be used.

now some more text why I've come up with this suggestion:

On Tue, Jan 8, 2013 at 7:03 AM, Terry Manderson
<[email-masked]> wrote:
<snip>
> text to address the concerns raised during the IETF LC.

Keep it as one document for the moment...

> 1) Should we, as a WG, continue to work on this item? Is it necessary/useful

yes it is useful...

> LISP mailing list as to its future.

The key word here is EXPERIMENT as I see it _now_.
I found this post a while back
http://www.ietf.org/mail-archive/web/lisp/current/msg04000.html

<start copy>
    From: Luigi Iannone <ggx at gigix.net>
    To: Roger Jørgensen <rogerj at gmail.com>
    Cc: ietf at ietf.org, lisp at ietf.org
    Date: Thu, 15 Nov 2012 14:22:50 +0100
<snip>
> I have to ask, who can request an netblock from this address space and
> from where?

Who: whoever is willing to deploy LISP.

Where: your RIR?

> I might be blind but I couldn't find it mentioned anywhere.
>

The purpose of the document is not to create a new way to distribute
prefixes with its own policies, rather to use the existing "process"
but just creating a code point specific for LISP.

<end of copy>

The problem here isn't so much WHO, it's more WHERE to get it. If we
involve the RIR we end up in a complicated process.
Complication don't always go well with EXPERIMENTAL processes.
The other important thing that hasn't been mention that much is HOW it
should be routed in the global routing table. This partly involve WHO
but more about this later. First WHERE.

When I read section "3. Rationale and Intent" in the draft I
understand that the purpose is to reserve a large block so you can
easier handle LISP EID space different than "regular" IP space on the
configuration level.

     The EID Block will be used only at configuration level, it is
     recommended not to hard-code in any way the IPv6 EID Block in the
     router hardware.  "

Combine this with the keyword "experimental" I would say this give us
a situation very alike to 6bone for those that remember that. Easy
addresses to get but you _knew_ you might had to change your prefix
and configuration at some point in the future. It's an EXPERIMENT.

First of all, let's change the "recommanded not to" into "MUST NOT be
hard-coded" or similar. Vendors are free to provide examples but it
must be possible to change it.

Then we add another section into the draft that mention this is a
_time limited_ experiment, let's say around 7 years or so
Reason for this follow
1.) 1/2 to 3 years to get LISP support from more vendors
2.) 1/2 to 2 years to plan, design and implement a setup using LISP EID space
3.) 1-3 years to get more deployment of it so we can learn and see how
it works out
4.) we'll first see the real result of this in 2-5years time...

I know it's not possible for me to get a larger none-test LISP
deployment in place before in 1-2years time.

With the above mention update we now have a clearly defined experiment
with a time frame.
This make it easier to solve the WHERE.

If we could get one RIR or some other entity to take on the job free
of charge to keep track of this LISP space, they should
* provide whois service and documentation on who has valid LISP EID space
* provide a framework for asking for LISP EID space
* handle registry service for this space according to some guidelines
given by LISP-EID wg (1*)

This entity should probably not decide who can get, and who can not
get LISP EID space, that's upto LISP-EID wg (1*).
I would suggest RIPE or someone else with enough manpower and active
people involved in LISP work.

The last problem with WHERE is the management body (1*), LISP-EID-wg.
I would suggest this work sort of similiar to how 6bone worked. I say
LISP-EID-wg and not LISP wg since the latter are more involved in the
development of it. Many of the same people but different focus. Their
lifetime are anyway given by above time frame.

This bring us onto WHO and more important HOW -

Someone will have to announce something in the global routing table.
We can think back to how well 2002::/16 worked as other also has
mention. I think the lesson learned from 2002::/16 was that we can not
have one huge net block many ASN's are announcing.
I suggest we split the reserved /12 into some smaller blocks, set
aside a given size for each RIR region (one /26) and for each RIR
region the above LISP-EID-wg can give out /32 space until it's empty.
I would say the experiment are a success IF most regions run out of
space within the first 5 year really. At that time we just decleare it
a success, remove the EXPERIMENTAL including the artificial /26 limit
and let each RIR handle LISP-EID space almost as regular space...  :-)

About WHO, anyone being a LIR can ask for a LISP-EID space directly.
The reason are that the net-block has to be announced into the global
routing table. Everyone else will have to ask one of the few having
space for a connection...
I realize this open up a monopolistic situation really...  anyhow, if
we run out of space in the EXPERIMENTAL pool isn't that a success when
more than 64 ASN in one or more region are using LISP EID space ?:-)

About HOW. ASN holders can request it through above mention system,
LISP-EID-wg will have to decide what is the best for the overall
EXPERIMENT, that mean quite alot of ISPs might get a no on their
request. That should be well understood. This is not regular IPv6
address space.
This space is also limited and it will be reachable in the global
routing table. The overall impact on the rest of Internet are
marginal.
Another question, should we consider, or have an opinion regarding how
it's exchanged between participants?

Again, since this is a EXPERIMENT, I would suggest we kindly ask each
and every /32 holder of the LISP-EID space to peer wherever possible
with everyone without any discussion at every peering/connection point
they are at. LISP-EID-wg are free to request this kind of things to
make the experiment a success.
... not sure how well that are going down the throat of ISPs out there
but isn't this an EXPERIMENT on the LISP protocol?

I do support the idea behind the original LISP-EID-block request, but
as the LastCall showed, there where to many unknown to let it move
forward in that state.

now I will sit back and let my suggestion be torn to pieces and see
what we can end up with in the end :-)

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Jan 2013 16:37:10 -0500

And this gets to the reason why specifying the allocation policy will 
take a lot longer.
 From what I understand of LISP, and speaking only as an individual 
participant, it is not at all obvious tome that the RIRs have an 
inherent role in LISP EID allocation.  LISP EIDs are not regional in any 
meaningful sense.

Note: Assuming we do create some mechanism for allocation, with multiple 
players, and assuming the thier members wanted them to, there is no 
reason that the RIRs could not choose to have a role.  I have no desire 
or ability to prevent them.  I just seen no reason to wire it in.

Yours,
Joel

---

From: Geoff Huston <[email-masked]>
Date: Thu, 10 Jan 2013 09:49:02 +1100

On the other hand Joel it could be said that you are reading a lot into white spaces without clear rationale. The regionality in the RIR structure has nothing to do with the regionality or, more relevantly, the lack thereof, in routing BGP, LISP or HELLO for that matter. So, for me, your comment does not appear to make much sense in this context.

Mine,
Geoff

On 10/01/2013, at 8:37 AM, Joel M. Halpern <[email-masked]> wrote:

> And this gets to the reason why specifying the allocation policy will take a lot longer.
> From what I understand of LISP, and speaking only as an individual participant, it is not at all obvious tome that the RIRs have an inherent role in LISP EID allocation.  LISP EIDs are not regional in any meaningful sense.
> 
> Note: Assuming we do create some mechanism for allocation, with multiple players, and assuming the thier members wanted them to, there is no reason that the RIRs could not choose to have a role.  I have no desire or ability to prevent them.  I just seen no reason to wire it in.
> 
> Yours,
> Joel
> 

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: SM <[email-masked]>
Date: Thu, 10 Jan 2013 00:17:13 -0800

>The size of the address blocks are a suggestion from my side.

I'll make the counter-arguments.

>procedures for how this should be used.

This would be a long-lived experiment.  It rarely 
works well in practice as the people who set it 
up might not be there to clean up the mess.  It's 
not a huge problem to ask for some IP address 
space to reserved.  I am ignoring a few details 
which might point to that being a problem.

The "if someone needs more space" makes it a IP 
address allocation problem.  Someone will have to 
deal with that request.  The IETF does not do 
that.  I pointed to "operational models" in an 
unrelated draft so that people can have at least 
a little information about the options and decide 
which option they prefer.  I prefer to avoid a 
6to4 scenario as making anything historic is a 
recipe for debate.  I don't like legacy space 
because I am creating a problem for someone else to sort out.

At 13:37 09-01-2013, Joel M. Halpern wrote:
>And this gets to the reason why specifying the 
>allocation policy will take a lot longer.

Not really.  It's only agreement that takes longer.

> From what I understand of LISP, and speaking 
> only as an individual participant, it is not at 
> all obvious tome that the RIRs have an inherent 
> role in LISP EID allocation.  LISP EIDs are not 
> regional in any meaningful sense.

The reality is that RIRs are currently managing 
IPv6 address allocations.  It does not bother me 
if IETF participants decide to give some other 
entity the responsibility to do the work as long 
as there is a clear explanation.

It is a lot of work to do an analysis of the 
various alternatives and figure out the better 
alternative.  The proposal made by Roger 
Jørgensen is a step forward.  Geoff Huston 
explained some stuff.  I think that his comments 
may have been misunderstood.  Brian Carpenter 
pointed to some interesting operational questions 
that have been raised or implied.  I may be 
missing them as I don't have a clear sense of how 
the working group wants LISP to work.

At 04:04 09-01-2013, Luigi Iannone wrote:
>Not really, truth is that it was suggested to 
>look at ORCHID, hence we tried to provide the 
>same elements (or equivalent) that the ORCHID document provided.

Although there may be some elements in common the 
problem is different.  The considerations were 
different and the environment was different when ORCHID was approved as a RFC.

Regards,
-sm

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 10 Jan 2013 16:06:00 +0100

[snip]
> Although there may be some elements in common the problem is different.  The considerations were different and the environment was different when ORCHID was approved as a RFC.
> 

That's why I put "(or equivalent)" ;-)

As a general comment I would say that whether choosing ORCHID as example was a good or bad idea does not really matter now. 

Gather ideas and comments to go forward is the important point (and this thread is a of great help ;-)).

ciao

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 10 Jan 2013 16:29:51 +0100

Hi Geoff,

thanks for your feedback, few comments inline.

On 9 Jan. 2013, at 21:57 , Geoff Huston <[email-masked]> wrote:

[snip]

> It all depends on the philosophy behind experimental allocations. If we were to assume that each and every single experiment in IPv6, including all forms of cryptographically generated addresses, a…

Very true and I understands the concerns. 
But
- here you have made the assumption that all "experiments" are equal. 
- we are not asking to blindly handout prefixes (otherwise we wouldn't have this discussion in first place)

> So the conventional philosophy behind experimental allocations is to use enough space to allow the experiment to operate and to gain experience with the technology. If this proves to be useful and taken up by the industry (and of course this process involves is by no means an assured outcome - quite the opposite in fact) then its again conventional to look at how to support the technology within the existing token distribution framework, or whether its appropriate to make changes to the token distribution framework.

Agreed.

> Now obviously some proponents of every experiment see universal adoption of their particular technology as a given, including some LISP proponents no doubt. So of course we see many (most?) experiment proponents proudly proclaim that they are uniquely different and obviously their particular experiment will naturally result in universal deployment, so why not assume that happy outcome at the outset of the experiment and allocate resources at a scale commensurate with their no doubt certain universal deployment in the not-so-distant future?

I am now curious: how many people promoting an experiment in which they do not believe and do not see wide deployment did you encounter?

What I want to say is that is natural that people pushing for new technology tend to aim high (human nature?).

> But wishing it, no matter how enthusiastic you may be personally, does not make it so. A prudent approach in a space that has seen, and is likely to see, many experiments proposed, is generally to provision resources to conduct the experiment at the scale of the experiment and if the experiment leads to someplace positive then look at what is required if the technology is to head to larger levels of deployment.
> 

Agreed.

> I am continually confused by the assumptions behind this assertion, and I've heard this assumption a number of times in the course of the consideration of this draft. If LISP is so fragile that it…

May be (or most probably) I am missing something, but if this was true this discussion would not take place.
BGP would evolve with the growth of the Internet and RFCs 4984 and 6115 wouldn't exist.

> And I strongly disagree with your opinion. If we did this for every experiment that we encounter that proposes some unique address plan that is intended to improve security, routing scaleability, a…

Yes, as other suggested we can reserve the prefix for a certain number of years and then ask the IETF again what to do. 

ciao

Luigi

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 11 Jan 2013 06:46:41 +0100

> I'll make the counter-arguments.

excellent!:-)

> This would be a long-lived experiment.  It rarely works well in practice as
> the people who set it up might not be there to clean up the mess.  It's not
> a huge problem to ask for some IP address space to reserved.  I am ignoring
> a few details which might point to that being a problem.

I agree, in practice this happen too often, which is why I suggest
this feature should be labeled EXPERIMENTAL but stable, or something
similiar and explain why.
That can also hurt deployment so we have to be very very clear on what
we mean with EXPERIMENTAL here.

> The "if someone needs more space" makes it a IP address allocation problem.
> Someone will have to deal with that request.  The IETF does not do that.  I
> pointed to "operational models" in an unrelated draft so that people can
> have at least a little information about the options and decide which option
> they prefer.  I prefer to avoid a 6to4 scenario as making anything historic
> is a recipe for debate.  I don't like legacy space because I am creating a
> problem for someone else to sort out.

In the beggining only a limited piece of that reserved /12 will be
used, if we divide it into regions or not that's no big deal, point
being it's limited affect on the _global_ routing table since those
/32 will have to be announced there. I mention RIR regions to get some
geographical diversity in the experiment, not being EU/US region
alone.

And about handing out those /32, there will be a set of guidelines
telling the RIR/entinty managing this in practice on how they should
deal with it, in all practical matter the LISP-EID-wg will have to
decide on which ISP should be let into the experiment now in the
begging to make sure we actual get an experiment.

Also - only a limited part of the /12 will be used, if that space are
empty within lets say 5 years I will claim this being a success and at
which point LISP-EID-wg/LISP-wg need to a discussion and decide,
should the restriction being removed or should we call this experiment
a failure. In the end it's IETF that will have to "approve" it.

<snip>
>> participant, it is not at all obvious tome that the RIRs have an inherent
>> role in LISP EID allocation.  LISP EIDs are not regional in any meaningful
>> sense.
>
>
> The reality is that RIRs are currently managing IPv6 address allocations.
> It does not bother me if IETF participants decide to give some other entity
> the responsibility to do the work as long as there is a clear explanation.

I think we should use the RIRs as long as it's possible, but of
course, this space LISP work in general do question how the future
should be. BUT that's an ENTIRELY different discussion.
Right now we're using the tools and functions available out there and
it would be stupid to not relay on and reuse the experience and
knowledge sitting within the RIR community.

> It is a lot of work to do an analysis of the various alternatives and figure
> out the better alternative.  The proposal made by Roger Jørgensen is a step
> forward.  Geoff Huston explained some stuff.  I think that his comments may
> have been misunderstood.  Brian Carpenter pointed to some interesting
> operational questions that have been raised or implied.  I may be missing
> them as I don't have a clear sense of how the working group wants LISP to
> work.

That's a excellent point, how do we want LISP to work... I think I
understand it but I have no problem to see that it's unclear. I guess
that's a direct request to this WG, make sure that part is
communicated better. However, it's still in the early phase of the
protocol so understandable that it's unclear to.

--

---

From: SM <[email-masked]>
Date: Fri, 11 Jan 2013 01:58:40 -0800

Hi Roger,
>we mean with EXPERIMENTAL here.

There was an provider in the Far East leaking out 
IPv4 shared address space and there was a 
provider in the Far West who did not follow the 
guidance in the specification.  My guess is that 
the label will be ignored.  In the IETF even if 
you are very very clear on what you mean someone 
will find a way around that.  :-)

>begging to make sure we actual get an experiment.

As a side note, I asked for somebody to point me 
to the IANA policy mentioned in the draft (or 
during previous discussions).  Nobody did 
that.   A long time ago this would be a matter of 
"please reserve a /12" without any hassle.  Let's 
say LISP is successful.  There will be a time 
when that /12 is not enough.  Then what?

I don't think that it is a good idea for the IETF 
to get into RIR policy in a draft.  The only 
reason to call all this an experiment (even 
though it is actually an experiment) is to get 
the IPv6 address space for free.  I don't think 
that there would be many hurdles in getting that 
if someone puts effort into it.  A simple path is to say so and ask nicely. :-)

Regards,
-sm

P.S. The LISP WG did ask nicely.  Maybe there 
wasn't a thorough discussion of the issues.

---

From: "George, Wes" <[email-masked]>
Date: Fri, 11 Jan 2013 12:01:47 -0500

> From: Roger Jørgensen [mailto:[email-masked]]>
>
> * we reserve a /12
> * LISP EID block are marked as EXPERIMENTAL with a time limit, let's say
> 7year, until 10.October 2020 (not random picked, but 10.10.2020 seems
> nice).
> * before 1.January 2019 IETF will have to decide if the EXPERIMENTAL was
> a success or a failure.
> ** If a success, we remove the 64 /32 (/26) limit and each RIR can hand
> out LISP EID space from the above /12 in their region, much like regular
> space.

[WEG] This would address my concerns with the requested reservation and allocation. The one thing I might add is support for a smaller initial reservation and subtending allocation(s) that were reserved and allocated in such a way that they could be grown by simply changing the bitmask if that ends up being necessary. I would think that the size of block(s) needed would be something that could be much more effectively evaluated as the experiment moves forward and we have a better sense for how the space gets used, and at the conclusion of the experiment, if there is success, there will be a clear justification for whatever block is deemed necessary.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: [email-masked]
Date: Fri, 11 Jan 2013 18:00:08 -0500 (EST)

Well spoken.

Heiner 

-----Ursprüngliche Mitteilung----- 
Von: Geoff Huston <[email-masked]>
An: Luigi Iannone <[email-masked]>
Cc: LISP mailing list list <[email-masked]>
Verschickt: Mi, 9 Jan 2013 9:57 pm
Betreff: Re: [lisp] draft-ietf-lisp-eid-block-03.txt back in workgroup

On 09/01/2013, at 11:02 PM, Luigi Iannone <[email-masked]> wrote:

>>> My guess is that the working group took an ORCHID approach (copy and paste 
:-)).  I suggest dropping the idea of calling it a very large-scale experiment.  
The unstated problem is about politics.  I suggest taking a look at 
draft-lear-lisp-nerd-09.  It contains a good discussion of operational models 
and the trade-offs.
>>> 
>> 
>> I was on the IAB at the time that ORCHID was being considered - the issue 
there was to find a balance between enough bits for acceptable crypto and basic 
conservatism in the absolute size of the request - at the time a /28 appeared to 
be a suitable compromise considering that this was an experiment.
>> 
>> Given that this is an experiment and that the transition from experiment to 
widespread deployment may well entail renumbering (as was the case with the 
6bone) then one approach may well be to use a modest prefix that has a limited 
capacity that would force renumbering in the shift from experiment to widespread 
adoption, if such occurs in the future.
> I may be mistake but I do not see the renumbering need in the LISP case.

It all depends on the philosophy behind experimental allocations. If we were to 
assume that each and every single experiment in IPv6, including all forms of 
cryptographically generated addresses, all forms of transitional mechanisms, all 
forms of address plans and all forms of routing experiments were each to request 
an experimental allocation that was "once and forever" and assumed at the outset 
that the experiment would result in comprehensive deployment over a network many 
many times larger than today's then I hope you can appreciate that we'd not have 
enough space to accommodate each and every experiment's requirements in the IPv6 
space.

So the conventional philosophy behind experimental allocations is to use enough 
space to allow the experiment to operate and to gain experience with the 
technology. If this proves to be useful and taken up by the industry (and of 
course this process involves is by no means an assured outcome - quite the 
opposite in fact) then its again conventional to look at how to support the 
technology within the existing token distribution framework, or whether its 
appropriate to make changes to the token distribution framework. Now obviously 
some proponents of every experiment see universal adoption of their particular 
technology as a given, including some LISP proponents no doubt. So of course we 
see many (most?) experiment proponents proudly proclaim that they are uniquely 
different and obviously their particular experiment will naturally result in 
universal deployment, so why not assume that happy outcome at the outset of the 
experiment and allocate resources at a scale commensurate w
 ith their no doubt certain universal deployment in the not-so-distant future? 
But wishing it, no matter how enthusiastic you may be personally, does not make 
it so. A prudent approach in a space that has seen, and is likely to see, many 
experiments proposed, is generally to provision resources to conduct the 
experiment at the scale of the experiment and if the experiment leads to 
someplace positive then look at what is required if the technology is to head to 
larger levels of deployment.

> The prefix request was written in such a way to reduce renumbering, rather 
making the prefix "bigger" so to accommodate the growth. This would also be an 
easy change, rather then adding different prefix blocks just change the length 
of the existing prefix.

I am continually confused by the assumptions behind this assertion, and I've 
heard this assumption a number of times in the course of the consideration of 
this draft. If LISP is so fragile that it requires a very particular deployed 
address structure in order to operate, then frankly we could do precisely the 
same in BGP and achieve better results because of avoidance of tunnelling. I 
find it somewhat strange to see this adamant view that LISP absolutely requires 
a uniquely structured address plan in order to achieve any useful outcome in 
terms of scalable routing, at a cost of increased latency and exposure to 
vagaries of tunnel behaviour, while at the same time ignoring the simple 
observation that if one were to do the same surgery on the address plan in BGP 
the outcomes would likely to be just as good if not better, without the negative 
factors of map-resolution-related latency and tunnelling.

> I think this is something to keep in the future document(s).

And I strongly disagree with your opinion. If we did this for every experiment 
that we encounter that proposes some unique address plan that is intended to 
improve security, routing scaleability, auto-configuration, pre-provisioning, 
network virtualization, software programability, etc etc, then once more we are 
going to find ourselves contemplating address exhaustion in IPv6 far sooner than 
anyone would've rationally anticipated.

Geoff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 12 Jan 2013 00:42:50 -0500

I would note in passing that
A) There is no particular reason that EID registration / allocation 
needs to be done by the RIRs
A') There is no reason to prohibit the RIRs from providing this 
function, in competition with others, if they are interested
B) There is no particular indication that the RIRs are interested in 
running such a function, and I would hate to see us mandate that they 
help with an experiment unless they are interested in it.

Yours,
Joel

---

From: [email-masked]
Date: Sat, 12 Jan 2013 06:01:39 -0500 (EST)

Well spoken. Again, after the short late-night email, because:

1) There is a long list of deficiencies which LISP maintains and which are due to clinging to 
   paradigms like prefix building, DiffServ bottom line "no interest in knowing the traffic outside/beyond the packets' incoming waiting queues",etc.etc.
   (I don't want to repeat it here)

2) LISP specifics:
    a) Its structures are fixed though not even an idea is cast how to form and handle Multicast- and Anycast-Locators.
        Anycast services (nearest hospital, nearest rescuer, nearest parking lot, nearest gas station, etc.) aren't considered at all.
       Most of the anycast services have to be scoped (it makes no sense to disseminate "I am an empty parking lot in Munich." all over Germany/world)
       and I doubt that LISP-PULL fits in. Also: By dealing only with unicast, LISP does not provide and bits to differentiate between unicast, multicast,...
     
     b) GRE-tunnel nesting is a great bail out. A new concept however should try to avoid it as much as possible .LISP however prefers 
         LISP-header nesting rather than enlisting transits inside of ONE extended LISP-header.

3) LISP-DDT specific:
    It will kill IPv4 and I honestly think about writing to the IESG and explain to the IESG why, and why this is not just a  bug that can be repaired whithin 
    LISP-DDT. Here only this: At first I thought LISP-DDT is doomed to fail, but being the coffin nail for IPv4 is the alternate and even worse consequence.

Heiner 

-----Ursprüngliche Mitteilung----- 
Von: Geoff Huston <[email-masked]>
An: Luigi Iannone <[email-masked]>
Cc: LISP mailing list list <[email-masked]>
Verschickt: Mi, 9 Jan 2013 9:57 pm
Betreff: Re: [lisp] draft-ietf-lisp-eid-block-03.txt back in workgroup

Geoff

---

From: Sander Steffann <[email-masked]>
Date: Sat, 12 Jan 2013 15:07:18 +0100

Hi,

> A) There is no particular reason that EID registration / allocation needs to be done by the RIRs
> A') There is no reason to prohibit the RIRs from providing this function, in competition with others, if they are interested
> B) There is no particular indication that the RIRs are interested in running such a function, and I would hate to see us mandate that they help with an experiment unless they are interested in it.

I think it would be appropriate to ask the Address Policy working groups of the different RIRs. I think it's a good idea to approach the chairs of those working groups once there is a bit more clarity on the way the addresses are supposed to be used.

PS: There is more to it than just handing out the addresses: reverse DNS and RPKI might be appropriate for this address space. The RIRs do have the infrastructure in place to support them. There are other ways to delegate reverse DNS, and maybe we choose not to support RPKI for this address space, but we should keep those things in mind...

Cheers,
Sander

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 12 Jan 2013 10:59:35 -0500

Yes, Reverse DNS is appropriate for these Identifiers.  That is not 
normally an RIR issue, as I understand it.

Assuming that hte working group does indeed move to LISP DDT, as it has 
indicated, there is no intention to use RPKI within this space.

The question of how proxy advertisements, which go into the normal 
system, will interact with RPKI, and SIDR in general, is indeed an 
important and complicated question which needs further investigation. 
The correct answer to securing conventional advertisements by proxies is 
not obvious to me.
The current proposals on the table would allow a large number of 
different players to originate proxy advertisements for large blocks of 
EIDs.  that's fine if the question is "are you willing to deliver the 
traffic for these?" It is rather harder if the question is "Are you 
authorized to deliver traffic for these?" as there is not yet an 
authorization model for proxies.

Which brings us back to the point that if we need to resolve these sorts 
of questions before doing the allocation then we are not going to do the 
allocation quickly.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 12 Jan 2013 13:11:10 -0800

> Well spoken. Again, after the short late-night email, because:

Since you were subjective on your comments I will be direct and to the point in my responses. But only direct to your comments that are clear. 

>    paradigms like prefix building, DiffServ

Do you mean map-cache caching. I don't know what you mean by prefix building. EID-prefixes are assigned to LISP sites just like prefixes are assigned today. There is no operational difference. 

> bottom line "no interest in knowing the traffic outside/beyond the packets' incoming waiting queues",etc.etc.

Diffswev code points are copied to the outer header. And we have seen cases where carrier-in-carrier scenarios, it is a feature to hide such code points. 

>     a) Its structures are fixed though not even an idea is cast how to form and handle Multicast- and Anycast-Locators.

Not true. Both EID and Locator address formats are flexibly encoded. We have seen use-cases where EIDs could be used as Fedex tracking numbers or VIN numbers (Vehicle ID Numbers). And we have seen Locators encoded as multi-tuple addresses that include Geo-Coordinates. 

>         Anycast services (nearest hospital, nearest rescuer, nearest parking lot, nearest gas station, etc.) aren't considered at all.

An EID can be used as an anycast address where the database lookup can decide which locators to return. And Locators can be anycast addresses as well to encapsulate packets to the closest locator. Nothing needs to be designed in the protocol to make this happen. 
 
>        Most of the anycast services have to be scoped (it makes no sense to disseminate "I am an empty parking lot in Munich." all over Germany/world)

Since LISP uses a pull database, there is no dissemination in the mapping system. 

Anyone that wants to talk to the EID will need to cache the locators but only in those locations. 

>        and I doubt that LISP-PULL fits in. Also: By dealing only with unicast, LISP does not provide and bits to differentiate between unicast, multicast,...

Because the existing semantics are used. Class D encodings for IPv4 and first-byte 0xFF for IPv6. 

>          LISP-header nesting rather than enlisting transits inside of ONE extended LISP-header.

LISP does re-encapsulating tunnels as well. See definition of RTRs in the TE and NAT-traversal Internet Drafts. 

>     It will kill IPv4 and I honestly think about writing to the IESG and explain to the IESG why, and why this is not just a  bug that can be repaired whithin 

This makes no sense. Why would it kill IPv4 and not IPv6?

DDT uses the iterative lookup model that DNS uses. Those properties are well known and we have a lot of experience with them. 

>     LISP-DDT. Here only this: At first I thought LISP-DDT is doomed to fail, but being the coffin nail for IPv4 is the alternate and even worse consequence.

Can you back the claim up with some data and technical commentary. 

If you do, I would be glad to continue this thread. 

Dino

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 12 Jan 2013 23:17:38 +0100

> up with a very good reasons now or just ask for regular RIR space

I did not suggest that each and every RIR got another special space
they had to administrate in co-ordination with LISP-EIG-wg.
It was more a way to make sure we get a world-wide experiment so not a
few EU and US ISPs claim all the space. If you want to get space from
the APNIC range you have to be a LIR at APNIC, same for all the
others. Of course this open up a question on how to check this but we
get ASN, LIR/MNT names ++++, it's doable.

The next thing I suggested was that _one_ RIR _or_ entity took on the
job of administrating ths address space. That include handing out /32
from all of the above mention ranges, but also keep track of reverse
DNS etc.
It was not a question of tasking all RIR, or even one RIR with this
job, but ask if any of the RIR would volunteer for the job.

The reason for asking a RIR is that they already have the
infrastructure in place... and for those that read ALL of the text in
my original post, I suggested we asked RIPE :)

--- Roger J ---

--

---

From: Sander Steffann <[email-masked]>
Date: Sat, 12 Jan 2013 23:37:55 +0100

Hi Roger,

> my original post, I suggested we asked RIPE :)

Request noted :-)

If this WG chooses to ask RIPE: The RIPE NCC will need a RIPE policy to use when allocating/assigning address space. Once we have a clear document that describes the basics we can work on that in the RIPE Address Policy WG.

Thanks,
Sander

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 13 Jan 2013 15:51:56 +0100

On Sun, Jan 13, 2013 at 3:28 PM, Arturo Servin <[email-masked]> wrote:
> Roger,
>
>         Perhaps I am being naive, but why not just give the space to IANA and
> then they assign to RIRs?

No other reason than to keep it simple, try to avoid involving the RIR
policy part to get the experiment going. That's also why there would
be a wg @IETF that will hand out space, not the different RIRs.
They're only involvment would only be if one of them took on the task
of keeping track of the space.

That's also why Sander Steffann's earlier mail included one piece that
wasn't what I suggested:

<snip>
> If this WG chooses to ask RIPE: The RIPE NCC will need a RIPE policy to use when allocating/assigning address space. Once we have a clear document that describes the basics we can work on that in t…

RIPE policy would not be the one describing or deciding on how the
space should be given out, that would be upto LISP-EIB-wg@IETF/or
something else. RIPE's job in my above suggestion would be to keep
track of the space, providing RDNS and simliar..

... but what do all the other here think? Haven't had to many critical
questions regarding the idea, or other comment for that sake.

--

---

From: Sander Steffann <[email-masked]>
Date: Sun, 13 Jan 2013 16:32:23 +0100

Hi Roger,

> track of the space, providing RDNS and simliar..

In that case the question should go directly to the RIPE NCC and not to the RIPE community. If this is not going to be defined in RIPE policy then the RIPE NCC members and the RIPE NCC Executive Board have to decide if they want the RIPE NCC to do the job. After all: the members provide the funding for the RIPE NCC.

Cheers,
Sander

---

From: Arturo Servin <[email-masked]>
Date: Sun, 13 Jan 2013 12:28:28 -0200

Roger,

Regards,
as

---

From: Arturo Servin <[email-masked]>
Date: Sun, 13 Jan 2013 13:03:17 -0200

Roger,

> of keeping track of the space.

	I am not sure that any of the scenarios (to one RIR vs IANA) could be
said simpler than the other. It just looks to me "more correct" to
follow the chain that we followed with IPv4, v6 and ASNs: IETF -> IANA
-> RIRs.

	About the mechanisms, IANA also has them (rDNS, recording space, etc.)

> questions regarding the idea, or other comment for that sake.

Regards,
/as

---

From: [email-masked]
Date: Wed, 16 Jan 2013 15:21:00 -0500 (EST)

Dino,
As you can see, I have chosen a peaceful and neutral subject line. See below my comments.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Dino Farinacci <[email-masked]>
An: heinerhummel <[email-masked]>
Cc: gih <[email-masked]>; ggx <[email-masked]>; lisp <[email-masked]>
Verschickt: Sa, 12 Jan 2013 10:11 pm
Betreff: Re: [lisp] draft-ietf-lisp-eid-block-03.txt back in workgroup

HH: I mean using prefixes AT ALL   !!!:  I know this is state of art in classical internet routing. LISP-TARA (yes, TARA is a loc-id-split solution) would reduce it be the same degree by which TARA routers were deployed. After all, you can't use prefixes for multicast or anycast either. As far as I know IPv4- FIBs don't have any entries for multicast or anycast.
Do you know whether IPv6 has a multicast-FIB and/or an anycast-FIB ? My guess is NO. Instead I believe that this is another IETF-law that there is only 1 FIB :-(

HH: I am accusing the DiffServ philosophy, which was once a counter movement to IntServ where available bandwidth capacities played a major role.
The DiffServ philosophy prevented that ideas were cast  to make routers  aware of the traffic in the near surrounding and to deal with it - even without connections a la SVC or LSP.. 

2) LISP specifics:

HH: 
Does your database ask back "where are you, user, so that I can send you the right locator "?
By your description that database is an anycast server . 
Do you envision that the users are mobile and will repeat their query every now and then ? Don't you be afraid of  bottle necks ?
Note, one aspect of the scalability was the update churn. Your PULL solution will create  query churns to few (how few?) such databases. This will hamper the general
operability of the internet itself.
An anycast service typically needs  a scope (see mentioned examples above). The areas your databases are responsible for won't  comply with the area any particular anycast service is limited to. In short: it doesn't fit at all!

Because the existing semantics are used. Class D encodings for IPv4 and first-byte 0xFF for IPv6. 
HH:Why so shy? You have a brand new (LISP) header and can do what you want and should be interested in fast forwarding. There is unicast, multicast, anycast, mp2mp, mp2p and broadcast to be differentiated. That could be done better than by address range differentiation

LISP does re-encapsulating tunnels as well. See definition of RTRs in the TE and NAT-traversal Internet Drafts. 
HH: Sure, but there are cases (detours) where employing a list of transit nodes is simpler than multiple pairs of  ITR and ETR .

3) LISP-DDT specific:

Dino

HH:
Dino, your original LISP envisioned several versions: LISP2.0 using DNS and others, one of  which then became the preferred one.
Many years have passed and we now encounter not only the scalability problem but also the ipv4 unicast address depletion problem.

The honorable intention of LISP was to support IPv4 rather than to pull over to IPv6. I am sure you agree.
(IPv6 has so much address space, enough to address fractions of any square inch of the globe, i.e. could esily encompass any locator info.  But, I think, neglecting ipv4 would be irresponsible. I am sure you agree again.) 

LOC-ID-SPLIT not only meant  "routing based on the locator to the egress-site" but also
to identify any host by the info-doublet {ID=ipv4 address ; LOC= locator} in a globally unique way, in case the iPv4 address by itself cannot be globally unique  anymore due to the ipv4 unicast address depletion problem.
Put in different words: the ipv4 address of any host must (only) be unique per that site which is indicated by the respective  locator.

(1)Provided that this is still a basic assumption of the LISP-group I conclude: LISP-DDT will fail for sure.
(2)Provided that LISP expects that there cannot be any further hosts with IPv4 addresses after all ipv4 unicast addresses are used up I conclude: LISP-DDT kills IPv4.

Why:
It is a MUST to get the info-doublet {ID=ipv4 address ; LOC= locator} by one single query !!! Period.!!!
Analogous example:
Imagine, you have to write a letter to Mr. Li (there are about 20 million people with this name), you only write this name on the envelope and ask the officer at your (ingress) post office to add the address of Mr. Li all by himself/herself (because  he/she might have a database  with all addresses of all persons in the world  - btw which of course is not true). Facit: That cannot work !!!

Hence:
The FQDN must be converted to {ID=ipv4 address ; LOC= locator} by one single query, i.e. must be done by the host itself, i.e. the host must prepend the LISP header ! Eventually the ingress router might intercept the DNS-query and act as a proxy, but even if so, the query must be sent to the DNS and to no other database !

Sorry Dino,  your defending DDT (how much better it is compared to LISP2.0 (DNS) couldn't convince me at all.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Geoff Huston <[email-masked]>
An: Luigi Iannone <[email-masked]>
Cc: LISP mailing list list <[email-masked]>
Verschickt: Mi, 9 Jan 2013 9:57 pm
Betreff: Re: [lisp] draft-ietf-lisp-eid-block-03.txt back in workgroup

Geoff

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 16 Jan 2013 21:31:51 -0800

> As you can see, I have chosen a peaceful and neutral subject line. See below my comments.

I thank you for the peace. 

> HH: I mean using prefixes AT ALL   !!!:  I know this is state of art in classical internet routing. LISP-TARA (yes, TARA is a loc-id-split solution) would reduce it be the same degree by which TARA routers were

LISP didn't have the goal to disrupt the current Internet. We wanted LISP sites to talk to non-LISP sites. We wanted the architecture to be incrementally deployable. 

> deployed. After all, you can't use prefixes for multicast or anycast either. As far as I know IPv4- FIBs don't have any entries for multicast or anycast.

IPv4 and IPv6 address usage is really identical. The real only difference is one is 4 times larger. 

> The DiffServ philosophy prevented that ideas were cast  to make routers  aware of the traffic in the near surrounding and to deal with it - even without connections a la SVC or LSP.. 

But you seem to conflate the two and hence my response. 

> Does your database ask back "where are you, user, so that I can send you the right locator "?

Yes it does. That is what Map-Notify messages do. 

> By your description that database is an anycast server . 

How is accessed can be with unique unicast locators or anycast locators assigned to the Map-Resolvers. 

> Do you envision that the users are mobile and will repeat their query every now and then ? Don't you be afraid of  bottle necks ?

They can but it is not required. When MNs get new locators they register them to the mapping database. 

ITRs are notified by the moving MN so they are informed to do a new lookup to get a newer set of locators. 

> Note, one aspect of the scalability was the update churn. Your PULL solution will create  query churns to few (how few?) such databases. This will hamper the general

It is a single update to the mapping system (in practice it is two Map-Servers) and updates to xTRs that are the top talking EIDs. 

> An anycast service typically needs  a scope (see mentioned examples above). The

This is not an anycast service. You just think it is. The architecture DOES NOT require the Map-Resolvers to have the SAME assigned address. 

> areas your databases are responsible for won't  comply with the area any particular anycast service is limited to. In short: it doesn't fit at all!
> 
>  
> 
> Dino, your original LISP envisioned several versions: LISP2.0 using DNS and others,

That was when LISP was in research mode in the RRG. Once we went into the IETF we made some decisions on how to make the mapping database system modular. 

This effort has been going for 6 years. So if one is in and out you may not see the final design. 

> one of  which then became the preferred one.

The intention was to support any type of EIDs. And if you look at the effort in the nvo3 working group shows that MAC addresses could be used as
EIDs where a layer-2 LISP is created (also known as VXLAN). 

> (IPv6 has so much address space, enough to address fractions of any square inch of the globe, i.e. could esily encompass any locator info.  But, I think, neglecting ipv4 would be irresponsible. I a…

We want to solve multi homing, VPNs, and mobility problems for all address
families. 

> to identify any host by the info-doublet {ID=ipv4 address ; LOC= locator} in a globally unique way, in case the iPv4 address by itself cannot be globally unique  anymore due to the ipv4 unicast add…

True - but Darrel and I can share our home's 192.168.1.0/24 space. So arguably we have a feature. If you solve the shortest path mobility problem you get VPN support for free. 

> Put in different words: the ipv4 address of any host must (only) be unique per that site which is indicated by the respective  locator.

Yes - that is right. But the Internet system requires that not LISP. 

> (1)Provided that this is still a basic assumption of the LISP-group I conclude: LISP-DDT will fail for sure.

I don't follow. 

> (2)Provided that LISP expects that there cannot be any further hosts with IPv4 addresses after all ipv4 unicast addresses are used up I conclude: LISP-DDT kills IPv4.

You are thinking that DDT Is so proactive to kill an address family. I
Wish we could have technology that could kill thinks but I'm afraid it
Isn't that simple. 

> It is a MUST to get the info-doublet {ID=ipv4 address ; LOC= locator} by one single query !!! Period.!!!

Read the specs. That is not true. 

> Imagine, you have to write a letter to Mr. Li (there are about 20 million people with this name), you only write this name on the envelope and ask the officer at your (ingress) post office to add t…

Address have to be unique within a VPN or an Internet. LISP did not put in this rule or restriction from your point of view. 

> The FQDN must be converted to {ID=ipv4 address ; LOC= locator} by one single query, i.e. must be done by the host itself, i.e. the host must prepend the LISP header ! Eventually the ingress router…

Dude - DNS can deal with this today when NATs are in use. You make it sound like LISP introduces this problem. 

> Sorry Dino,  your defending DDT (how much better it is compared to LISP2.0 (DNS) couldn't convince me at all.

Just sit back and watch Heiner. We never said DDT is DNS. We have said it uses the iterative lookup model like DNS. And the nodes are configured like a DNS hierarchy. So people can understand how the mapping database can be managed by multiple organizations and possibly the same TYPE if tools that are used for the DNS system. 

Dino