ietf
[Top] [All Lists]

Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

2012-11-18 10:02:45
And:
LISP does neither describe how to cope with the address depletion issue nor 
prove that it is able to.


Imho, there is not even the slightest chance not to fail.


Heiner



-----Ursprüngliche Mitteilung----- 
Von: Geoff Huston <gih(_at_)apnic(_dot_)net>
An: Joel Halpern Direct <jmh(_dot_)direct(_at_)joelhalpern(_dot_)com>
Cc: ietf <ietf(_at_)ietf(_dot_)org>; lisp <lisp(_at_)ietf(_dot_)org>; Brian E 
Carpenter <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
Verschickt: So, 18 Nov 2012 7:22 am
Betreff: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID 
Block) to Informational RFC


But why request the reservation of a /12? Or even a /16 for that matter?

If the LISP experimental deployers have filled a /32 with /48 prefixes then 
should this imply that the experiment is all over over and its time to recast  
this not as an experiment but as an application which requires global unicast 
address allocations, and proceed along those grounds?

Indeed if the entire point of this experimental use allocation request is on 
the 
basis that at the time when deployment numbers are sufficiently large (orders 
of 
millions of end sites presumably) then this block allocation will have some 
beneficial effects. But thats NOT an experimental justification.

So what is this request? Experimental? Planning for large scale deployment?

If its the latter than I do not understand how this draft, calling for a 
allocation from the IANA special purpose address registry on the grounds of 
supporting an IETF experimental activity, can be supported by the existing 
processes. The IANA Special purpose address registry and RFC 4773 do not 
encompass the allocation of address blocks for use in a global unicast address 
context in the context of large scale deployment activities.

If its the former then the scale of the allocation is unwarranted. The broad 
characterisation of the experiment allocation is to test concepts, and if 
that's 
the case then once the "test" is over what are the plans to migrate OUT of the 
"test" allocation and support unicast global address allocations in the context 
of LISP under the general framework of RFC2860 and RFC 2050? What is the scale 
of this "test"? When would the "test" be completed?

I think this draft is not well thought through and the draft's proposals for 
address allocation from the IANA Special Purpose Address Registry  is 
inconsistent with the processes we use for management of addresses in the IETF. 
I do not support the publication of this draft.

regards,

   Geoff




On 17/11/2012, at 8:19 AM, Joel Halpern Direct 
<jmh(_dot_)direct(_at_)joelhalpern(_dot_)com> 
wrote:

Most of what you describe Sander sounds reasonable, and sounds aligned with 
what is i the deployment documents.

The WG debated the EID allocation extensively.  One could argue that there is 
no need for it, that we could merely request that PI allocations be granted for 
LISP EID usage individually.  The WG felt that if we could get all IPv6 LISP 
EID 
allocations from a single block that was not used for anything else, that would 
simplify avoiding lookups in the mapping system that were inevitably going to 
fail.  Thus the allocations request.

Yours,
Joel

On 11/16/2012 4:12 PM, Sander Steffann wrote:
Hi Joel,

Why does any operator have a reason to carr any routes other than their 
paying customers?  Because it provides connectivity for their customers.
If we get this block allocaed, then it results in 1 extra routing entry in 
the global routing table to support LISP inter-working.
An entry that some of their customers may use, whether the operator 
carrying 
it knows that or not.

In fact, it would take significant extra work for the operator to somehow 
block this aggregate.

If LISP fails, this is a small cost to find out.
If LISP succeeds, this results in significant reduction in core tabl sizes 
for everyone.

That still assumes the altruistic routing of the prefix. And I am afraid 
that 
if the usage of this block gets a bad reputation that all LISP usage will share 
that reputation. I really like LISP but I am still not convinced that it's a 
good idea. If we can find a way to get the EID prefix routed in a reliable way 
then I would love it!

I really care about LISP and I am afraid that: people see unreliable routing 
for EID /16 => assume LISP is unreliable. That is why I am pushing so hard to 
get this sorted out.

Hmmm. What about the following strategy:
- Start with the EID prefix being handed out like PI
  - Either through the RIRs if they are willing to take the responsibility
  - Or from a separate registry
- Some altruistic /16 PITRs might show up in the global BGP table
- A holders of a (assume) /48 from the EID prefix can arrange PITRs for 
their 
own space
  - And announce it as a separate route in the global BGP table (for now)
  - Keep the routing and reliability under their own control
- If the experiment is a success we advise ISPs to:
  - Install their own PITRs for the /16
  - Filter out the /48s at their border

The filtering of the more-specifics once they have their own PITRs will make 
sure that they use those PITRs and that they will use the most optimal path to 
the locators as soon as possible. It will also keep their routing table 
smaller. 
If enough big transit providers offer /16 PITRs to their customers then the 
more-specifics might be filtered on a larger scale.

So, summary:

The ways to reach a PITR would be
a) Run your own PITR (big networks, LISP users)
b) Use one from your transit(s) (smaller networks that don't have their own)
c) Use an altruistic one as last resort

As long as (a) and (b) aren't a reality the LISP users who don't want to 
rely 
on (c) can run/rent/etc a PITR for their own space. I think the routing 
community would really appreciate it if all those more-specific routes would be 
temporary until wide deployment of (a) and (b) make them unnecessary.

And if this doesn't become a success we have a bunch of /48 prefixes to the 
separate PITRs in the BGP table. It won't be much, otherwise we would have 
declared success. So the risk of messing the BGP table up is very limited. And 
when can tell people: if you are bothered by those more-specifics in your 
routing table you can always deploy your own PITRs and filter the 
more-specifics 
at your border. That might keep everyone happy.

What do you think?

Thanks,
Sander

_______________________________________________
lisp mailing list
lisp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/lisp

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
gih(_at_)apnic(_dot_)net




_______________________________________________
lisp mailing list
lisp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/lisp

 
<Prev in Thread] Current Thread [Next in Thread>