Date: Wed, 08 Dec 2010 15:34:47 -0600 From: 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.
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@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751