Start accepting longer prefixes as IPv4 depletes?

Wed Dec 8 22:01:38 UTC 2010

> Date: Wed, 08 Dec 2010 15:34:47 -0600
> From: Jack Bates <jbates at brightok.net>
> 
> On 12/8/2010 3:12 PM, David Conrad wrote:
> > Cameron,
> >
> > On Dec 8, 2010, at 12:01 PM, Cameron Byrne wrote:
> >> I believe a lot of folks think the routing paths should be tightly
> >> coupled with the physical topology.
> >
> > The downside, of course, being that if you change your location
> > within the physical topology, you have to renumber.  Enterprises have
> > already voted with their feet that this isn't acceptable with IPv4
> > and they'll no doubt do the same with IPv6.
> >
> >> In a mature IPv6 world, that is sane, i am not sure what the real
> >> value of LISP is.
> >
> > Sanity is in the eye of the beholder.  The advantage a LISP(-like)
> > scheme provides is a way of separating location from identity,
> > allowing for arbitrary topology change (and complexity in the form of
> > multi-homing) without affecting the identities of the systems on the
> > network. Changing providers or multi-homing would thus not result in
> > a renumbering event or pushing yet another prefix into the DFZ.
> >
> 
> I think the issue, and correct me if I'm wrong, is that LISP does not 
> address issues of traffic engineering? A lot of the additional routes in 
> DFZ are there specifically to handle traffic engineering.

Yes. Locator-ID separation means that you would no longer have to add
prefixes to the DFZ for traffic engineering. That would be in the
province of the locator part of the operation. I see nothing preventing
this from being done in LISP and being done in a much more manageable
manner. This does, of course, increase the number of locators in the
FIB, but the number of locators would be tiny compared to the current
FIB, so I don't see an issue.

> The flow of traffic is usually based on ASN from a human standpoint, but 
> dividing networks up and changing priorities on a per network basis is 
> the mechanism BGP allows for determining that flow of traffic.

> Another large increase in DFZ was due to constraints. Even with 
> engineering, I might divide a /16 into 4 /18 networks and be able to 
> obtain the metrics I need. ARIN, over the years gave me a lot of /20 
> networks. It has been hopeful (and policy is still evolving with ARIN to 
> accomplish this for our region) that IPv6 would not suffer from having 
> to receive multiple small allocations which do not align with our 
> traffic engineering needs but just add additional routes.

So use locator to do the job right instead of twisting things with
machinations in routing that the protocols were not designed for.

I am simply amazed that, in this day and age, people still seem to not
understand the value of locator-ID separation! Almost all early network
protocols other than IP did this. IP, for good reason, became dominant
and, in the process, the concept was largely forgotten. There was a
contingent of folks who tried to get it into IPv6 as a base part of the
standard, but they lost. (Yes, I understand the prevailing arguments,
but it was till a HUGE mistake, IMHO.)

It certainly would have been much better if locator-ID separation was
built into the protocol (IPv6) rather than being shoe-horned in after
the fact, but I really think we still need it. Note, LISP has some real
corner case issues and may not be implementable on a general basis. I
want locator-ID separation, but that does not necessarily mean LISP.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751