Re: Start accepting longer prefixes as IPv4 depletes?

[Jack Bates <jbates () 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.

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.

The policy currently being discussed on PPML supports assigning networks 
larger than the currently utilized one if necessary and not requiring a 
renumber (which effectively triples your allocated space or more but 
only adds a single additional route to DFZ).


Jack