Implementations/suggestions for Multihoming IPv6 for DSL sites
owen at delong.com
Mon Apr 11 08:37:41 CDT 2011
On Apr 11, 2011, at 6:30 AM, Luigi Iannone wrote:
> On 11, Apr, 2011, at 15:17 , Owen DeLong wrote:
>>>> Doing IPv4 LISP on any kind of scale requires significant additional prefixes which at this time doesn't seem so practical to me.
>>> This is not accurate IMO. To inject prefixes in the BGP is needed only to make non-LISP sites talk to LISP sites. Even there you can aggressively aggregate, as explained in draft-ietf-lisp-interworking.
>>> As long as the LISP deployment progress you can even withdraw some prefixes from the BGP infrastructure and advertise only a larger aggregate in order for legacy site to reach the new LISP site.
>> Who said anything about BGP? I was talking about the amount of additional IP space needed vs. the
>> amount of IPv4 free space remaining.
> Sorry. I misunderstood.
> But can you explain better? Why should LISP require more IP space than normal IPv4 deployment?
> If you are a new site, you ask for an IP block. This is independent from whether or not you will use LISP.
Sure, but, if you also need locators, don't you need additional IP space to use for locators?
> If you are an existing site and you want to switch to LISP why you need more space? you can re-use what you have?
Perhaps I misunderstand LISP, but, I though you needed space to use for locators and space
to use for IDs if you are an independently routed multi-homed site.
If you are not an independently routed multi-homed site, then, don't you need a set of host IDs
to go with each of your upstream locators?
As I understand LISP, it's basically a dynamic tunneling system where you have two discrete,
but non-overlapping address spaces, one inside the tunnels and one outside.
If that's the case, then, I believe it leads to at least some amount of duplicate consumption of
> Or I missed the point again?
Or perhaps the complexity of LISP in the details still confuses me, despite people's insistence
that it is not complex.
More information about the NANOG