Implementations/suggestions for Multihoming IPv6 for DSL sites
Hello all, I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ? In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach." This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic. Thanks, Daniel
why would you do that for? ----- Original Message ---- From: Daniel STICKNEY <dstickney@optilian.com> To: nanog@nanog.org Sent: Thu, April 7, 2011 10:27:01 AM Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites Hello all, I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ? In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach." This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic. Thanks, Daniel
how many ip addresses do you have ? ----- Original Message ---- From: Daniel STICKNEY <dstickney@optilian.com> To: nanog@nanog.org Sent: Thu, April 7, 2011 10:27:01 AM Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites Hello all, I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ? In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach." This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic. Thanks, Daniel
have you thought about taking a Cisco training course? ----- Original Message ---- From: Daniel STICKNEY <dstickney@optilian.com> To: nanog@nanog.org Sent: Thu, April 7, 2011 10:27:01 AM Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites Hello all, I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ? In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach." This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic. Thanks, Daniel
Hi Daniel, all IPv6 multihoming ideas are very theoretical today. None of them is ready to use. Shim6 looks very good, but it requires support on both a client and a server side. As you can guess, there is only experimental support for some operating systems. Microsoft and Apple doesn't support it. A one possible solution I have found is based on a network prefix translation (NPTv6 http://tools.ietf.org/html/draft-mrw-nat66-12). Using NPTv6 you can do multihoming that is very similar to multihoming based on IPv4 NAT. I haven't found any commercial product that supports it, but you can use an implementation for Linux (map66 http://sourceforge.net/projects/map66/). Assembling map66 with some other scripts (to detect link failure) you can have what are you looking for. On 4/7/11 11:58 AM, isabel dias wrote:
have you thought about taking a Cisco training course?
I wonder if that kind of knowledge can be learned in any Cisco course today. I don't think so. Tomas
----- Original Message ---- From: Daniel STICKNEY <dstickney@optilian.com> To: nanog@nanog.org Sent: Thu, April 7, 2011 10:27:01 AM Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites
Hello all,
I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ?
In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach."
This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic.
Thanks, Daniel
On Apr 7, 2011, at 6:51 AM, Tomas Podermanski wrote:
Hi Daniel, all IPv6 multihoming ideas are very theoretical today. None of them is ready to use. Shim6 looks very good, but it requires support on both a client and a server side. As you can guess, there is only experimental support for some operating systems. Microsoft and Apple doesn't support it.
Well, BGP multihoming works today quite well. It's no different from IPv4 and is a perfectly viable technology.
A one possible solution I have found is based on a network prefix translation (NPTv6 http://tools.ietf.org/html/draft-mrw-nat66-12). Using NPTv6 you can do multihoming that is very similar to multihoming based on IPv4 NAT.
You can also use thumb cuffs to suspend yourself from a rafter, but, I don't recommend it unless you are into pain. Owen
On 4/7/11 7:04 AM, Owen DeLong wrote:
On Apr 7, 2011, at 6:51 AM, Tomas Podermanski wrote:
Hi Daniel, all IPv6 multihoming ideas are very theoretical today. None of them is ready to use. Shim6 looks very good, but it requires support on both a client and a server side. As you can guess, there is only experimental support for some operating systems. Microsoft and Apple doesn't support it.
Well, BGP multihoming works today quite well. It's no different from IPv4 and is a perfectly viable technology.
to reiterate, if you are multihoming in ipv4, you likely have a pi assigned prefix or one that you have permission to advertise from an upstream. If you obtain a pi v6 prefix via the same channel you obtained the v4 one it is likely that you simply advertise to 1 or more upstreams and you are done. I have done this too good effect in three different organizations that I've had the privilege of working with so far. I'd go so far as to say that the experience was exactly the same.
A one possible solution I have found is based on a network prefix translation (NPTv6 http://tools.ietf.org/html/draft-mrw-nat66-12). Using NPTv6 you can do multihoming that is very similar to multihoming based on IPv4 NAT.
You can also use thumb cuffs to suspend yourself from a rafter, but, I don't recommend it unless you are into pain.
Owen
On 4/7/2011 02:27, Daniel STICKNEY wrote:
Hello all,
I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ?
In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach."
This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic.
It doesn't exist in practice; real world is BGP multihoming. Everything else is still just an academic exercise. ~Seth
On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY <dstickney@optilian.com> wrote:
I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ?
When you talking about "two DSL lines", I assume this is mainly for office / residential environment to have redundancy and/or increase uplink availability. In this environment, BGP exchanges with uplink ISPs for multihoming usually is not an option. One reason maybe cost, another reason maybe ISP doesn't like to setup BGP with a DSL customer. At least in my case, reason #2 always prevent my customers to setup BGP with uplink ISPs. As Seth pointed out SHIM6 is still an academic exercise, my experiences to resolve this needs at this moment is leveraging NAT66, as what we did in IPv4 world. I use FreeBSD+PF and Juniper NetScreen/SSG to do NAT66 in several different locations, and they all works as expected so far. Some people don't like NAT especially NAT66, but to be realistic that does work, and works well in terms of providing redundancy over two DSL lines for office / residential needs. -- Michel~
Michel de Nostredame wrote on 07/04/2011 22:30:
On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY<dstickney@optilian.com> wrote:
I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ?
When you talking about "two DSL lines", I assume this is mainly for office / residential environment to have redundancy and/or increase uplink availability.
In this environment, BGP exchanges with uplink ISPs for multihoming usually is not an option. One reason maybe cost, another reason maybe ISP doesn't like to setup BGP with a DSL customer. At least in my case, reason #2 always prevent my customers to setup BGP with uplink ISPs.
As Seth pointed out SHIM6 is still an academic exercise, my experiences to resolve this needs at this moment is leveraging NAT66, as what we did in IPv4 world. I use FreeBSD+PF and Juniper NetScreen/SSG to do NAT66 in several different locations, and they all works as expected so far.
Some people don't like NAT especially NAT66, but to be realistic that does work, and works well in terms of providing redundancy over two DSL lines for office / residential needs.
-- Michel~
Although i generally hate NAT, multihoming must be the only (or at least the most important) reason why NAT66 has to be standardized. Otherwise some kind of routing must be implemented on hosts. -- Tassos
In message <4D9E27A5.3040108@forthnet.gr>, Tassos Chatzithomaoglou writes:
Michel de Nostredame wrote on 07/04/2011 22:30:
On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY<dstickney@optilian.com> wr ote:
I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ?
When you talking about "two DSL lines", I assume this is mainly for office / residential environment to have redundancy and/or increase uplink availability.
In this environment, BGP exchanges with uplink ISPs for multihoming usually is not an option. One reason maybe cost, another reason maybe ISP doesn't like to setup BGP with a DSL customer. At least in my case, reason #2 always prevent my customers to setup BGP with uplink ISPs.
As Seth pointed out SHIM6 is still an academic exercise, my experiences to resolve this needs at this moment is leveraging NAT66, as what we did in IPv4 world. I use FreeBSD+PF and Juniper NetScreen/SSG to do NAT66 in several different locations, and they all works as expected so far.
Some people don't like NAT especially NAT66, but to be realistic that does work, and works well in terms of providing redundancy over two DSL lines for office / residential needs.
-- Michel~
Although i generally hate NAT, multihoming must be the only (or at least the most important) reason why NAT66 has to be standardized. Otherwise some kind of routing must be implemented on hosts.
And what's wrong with routing on hosts? If a router advertises a prefix it should know where to send traffic that originates from that prefix. You just choose the next hop by looking at which routers are advertising the prefix for the source address for this packet and choosing between them. It's a touch more state to be kept with every address. It would also be useful for filtering out rouge RAs. You look at the address you learnt the prefix from then filter out that router / prefix.
-- Tassos
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 4/7/11 8:30 PM, Randy Bush wrote:
Otherwise some kind of routing must be implemented on hosts. Some kind of routing is already implemented on hosts. honto??? your mobile phone is multihomed, as is this laptop I'm typing on.
routing != multihomed
it's not an autonomous system it's embedded inside one or more of them... it most definitely makes a forwarding decision which in this case also requires address selection.
try rfc 1812
A router connects to two or more logical interfaces, represented by IP subnets or unnumbered point to point lines (discussed in section [2.2.7]). Thus, it has at least one physical interface. Forwarding an IP datagram generally requires the router to choose the address and relevant interface of the next-hop router or (for the final hop) the destination host. This choice, called relaying or forwarding depends upon a route database within the router. The route database is also called a routing table or forwarding table. The term "router" derives from the process of building this route database; routing protocols and configuration interact in a process called routing.
randy
On Apr 7, 2011, at 8:30 PM, Randy Bush wrote:
Otherwise some kind of routing must be implemented on hosts. Some kind of routing is already implemented on hosts. honto??? your mobile phone is multihomed, as is this laptop I'm typing on.
routing != multihomed
try rfc 1812
randy
Many of my hosts have more than one interface and will forward packets received on one to hosts connected on others. That's routing. Next? Owen
Sent from my iPad On Apr 7, 2011, at 2:07 PM, Tassos Chatzithomaoglou <achatz@forthnet.gr> wrote:
Michel de Nostredame wrote on 07/04/2011 22:30:
On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY<dstickney@optilian.com> wrote:
I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ?
When you talking about "two DSL lines", I assume this is mainly for office / residential environment to have redundancy and/or increase uplink availability.
In this environment, BGP exchanges with uplink ISPs for multihoming usually is not an option. One reason maybe cost, another reason maybe ISP doesn't like to setup BGP with a DSL customer. At least in my case, reason #2 always prevent my customers to setup BGP with uplink ISPs.
As Seth pointed out SHIM6 is still an academic exercise, my experiences to resolve this needs at this moment is leveraging NAT66, as what we did in IPv4 world. I use FreeBSD+PF and Juniper NetScreen/SSG to do NAT66 in several different locations, and they all works as expected so far.
Some people don't like NAT especially NAT66, but to be realistic that does work, and works well in terms of providing redundancy over two DSL lines for office / residential needs.
-- Michel~
Although i generally hate NAT, multihoming must be the only (or at least the most important) reason why NAT66 has to be standardized. Otherwise some kind of routing must be implemented on hosts.
There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler. Owen
-- Tassos
On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong <owen@delong.com> wrote:
There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler.
I know a lot of small businesses with one FiOS link and one Comcast link and I don't think they're going to be able to do BGP. Their providers won't do it and their prem equipment doesn't support it and the local IT person doesn't have the know-how to do it. I know that the typical NANOG member isn't in this category, but this is a use-case that is very common and outnumbers NANOG members. Tom -- Sign up for my new class "Advanced Time Mgmt: Team Efficiency" at PICC! April 29-30, New Jersey, LOPSA PICC: www.picconf.org "Call for papers and talk proposals" open at LISA! Write your paper today! Dec 4-9, Boston, Usenix LISA, www.usenix.org/event/lisa11
On 4/7/11 8:13 PM, Tom Limoncelli wrote:
On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong <owen@delong.com> wrote:
There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler.
I know a lot of small businesses with one FiOS link and one Comcast link and I don't think they're going to be able to do BGP. Their providers won't do it and their prem equipment doesn't support it and the local IT person doesn't have the know-how to do it. I know that the typical NANOG member isn't in this category, but this is a use-case that is very common and outnumbers NANOG members.
building a cpe that can do something useful with two ip addresses and two default routes to two consumer isps isn't really that hard, had a cisco 2500 circa 1995 that did dial on demand for backup... heck, today you can get a cradlepoint with 3 x 3g/4g wireless cards attached.
Tom
On Apr 7, 2011, at 8:13 PM, Tom Limoncelli wrote:
On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong <owen@delong.com> wrote:
There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler.
I know a lot of small businesses with one FiOS link and one Comcast link and I don't think they're going to be able to do BGP. Their providers won't do it and their prem equipment doesn't support it and the local IT person doesn't have the know-how to do it. I know that the typical NANOG member isn't in this category, but this is a use-case that is very common and outnumbers NANOG members.
I have one DSL and one Cable. Neither the DSL provider nor Comcast will do BGP. I do BGP just fine without them doing BGP. Owen
Owen DeLong wrote:
On Apr 7, 2011, at 8:13 PM, Tom Limoncelli wrote:
On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong<owen@delong.com> wrote:
There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler.
I know a lot of small businesses with one FiOS link and one Comcast link and I don't think they're going to be able to do BGP. Their providers won't do it and their prem equipment doesn't support it and the local IT person doesn't have the know-how to do it. I know that the typical NANOG member isn't in this category, but this is a use-case that is very common and outnumbers NANOG members.
I have one DSL and one Cable. Neither the DSL provider nor Comcast will do BGP. I do BGP just fine without them doing BGP.
Owen
Your use case requires at minimum a triangle, ideally a rectangle. Along for the ride comes encapsulation, overhead, additional bottlenecks and failure scenarios. The payoff has to be worth it and that usually means something more than the elimination of napt on outbound internet access, such as inbound access to bring-your-own-ip. For anyone to do this requires beyond basic know-how and a willing 3rd point. I'll do it for a customer, but it is by no means readily available, or even ideal, so lets stop hyping it. Joe
On Apr 8, 2011, at 6:54 AM, Joe Maimon wrote:
Owen DeLong wrote:
On Apr 7, 2011, at 8:13 PM, Tom Limoncelli wrote:
On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong<owen@delong.com> wrote:
There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler.
I know a lot of small businesses with one FiOS link and one Comcast link and I don't think they're going to be able to do BGP. Their providers won't do it and their prem equipment doesn't support it and the local IT person doesn't have the know-how to do it. I know that the typical NANOG member isn't in this category, but this is a use-case that is very common and outnumbers NANOG members.
I have one DSL and one Cable. Neither the DSL provider nor Comcast will do BGP. I do BGP just fine without them doing BGP.
Owen
Your use case requires at minimum a triangle, ideally a rectangle.
I'm not sure what you mean by traingle/rectangle other than the same thing that would be required for any actual multi-homing scenario.
Along for the ride comes encapsulation, overhead, additional bottlenecks and failure scenarios. The payoff has to be worth it and that usually means something more than the elimination of napt on outbound internet access, such as inbound access to bring-your-own-ip.
The encapsulation and overhead is small. In general, all of the failures experienced to date have been the result of the underlying DSL or Cable provider. I guess the value of eliminating the damage caused by NAT/NAPT/PAT/whatever you want to call the abysmal hack so many people choose to live with because they perceive a lack of options is a value each organization has to determine in their environment. In my environment, this is a very low overhead and very low cost way to solve the issue and get reliable multihoming with portable accessible addresses and avoid having to involve silly third parties in things like making a VNC connection back to one of my hosts from the road.
For anyone to do this requires beyond basic know-how and a willing 3rd point. I'll do it for a customer, but it is by no means readily available, or even ideal, so lets stop hyping it.
We can agree to disagree. I think it is readily available and I think it is a significantly better solution than NAT. Ideal? no. Ideal would be when access providers start offering cost-effective services that include dynamic routing. However, until that happens, this is the next best thing. Owen
Dear Michel, On 7 Apr 2011, at 21:30, Michel de Nostredame wrote:
On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY <dstickney@optilian.com> wrote:
I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ?
In this environment, BGP exchanges with uplink ISPs for multihoming usually is not an option. One reason maybe cost, another reason maybe ISP doesn't like to setup BGP with a DSL customer. At least in my case, reason #2 always prevent my customers to setup BGP with uplink ISPs.
Agreed. Very common situation.
As Seth pointed out SHIM6 is still an academic exercise
Another Locator / ID separator protocol is LISP. The advantage is that you don't need to change the host but only the CPE. I've been using it to multi-home my house and it works fine. I'm multihoming my IPv6 /48 over a v6-only DSL and a v4-only FTTH connection. More information about LISP be found here: http://www.lisp4.net/ Kind regards, Job Snijders
On 4/8/11 8:31 AM, Job Snijders wrote:
As Seth pointed out SHIM6 is still an academic exercise
Another Locator / ID separator protocol is LISP. The advantage is that you don't need to change the host but only the CPE. I've been using it to multi-home my house and it works fine. I'm multihoming my IPv6 /48 over a v6-only DSL and a v4-only FTTH connection.
More information about LISP be found here: http://www.lisp4.net/
Ah, I completely forgot about LISP, which reminds me, I'd wanted to set it up for fun and learning. ~Seth
On Apr 8, 2011, at 9:30 AM, Seth Mattinen wrote:
On 4/8/11 8:31 AM, Job Snijders wrote:
As Seth pointed out SHIM6 is still an academic exercise
Another Locator / ID separator protocol is LISP. The advantage is that you don't need to change the host but only the CPE. I've been using it to multi-home my house and it works fine. I'm multihoming my IPv6 /48 over a v6-only DSL and a v4-only FTTH connection.
More information about LISP be found here: http://www.lisp4.net/
Ah, I completely forgot about LISP, which reminds me, I'd wanted to set it up for fun and learning.
~Seth
LISP can also be a good option. Comes with slightly more overhead in terms of encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality for IPv4 (which GRE supports nicely). Owen
On 04/08/2011 06:39 PM, Owen DeLong wrote:
On Apr 8, 2011, at 9:30 AM, Seth Mattinen wrote:
On 4/8/11 8:31 AM, Job Snijders wrote:
As Seth pointed out SHIM6 is still an academic exercise Another Locator / ID separator protocol is LISP. The advantage is that you don't need to change the host but only the CPE. I've been using it to multi-home my house and it works fine. I'm multihoming my IPv6 /48 over a v6-only DSL and a v4-only FTTH connection.
More information about LISP be found here: http://www.lisp4.net/
Ah, I completely forgot about LISP, which reminds me, I'd wanted to set it up for fun and learning.
~Seth LISP can also be a good option. Comes with slightly more overhead in terms of encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality for IPv4 (which GRE supports nicely).
Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP. Regards, -Lori Jakab
Owen
Dear All, On 8 Apr 2011, at 19:34, Lori Jakab wrote:
On 04/08/2011 06:39 PM, Owen DeLong wrote:
LISP can also be a good option. Comes with slightly more overhead in terms of encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality for IPv4 (which GRE supports nicely).
Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP.
Comparing GRE with LISP is like comparing /etc/hosts with the global DNS system. ;-) I don't understand the comments about LISP and IPv4. IPv4 works just excellent with LISP. I have a IPv4 block at home which I multi-home over my IPv6-only DSL and IPv4-only FTTH line. LISP is pretty address family agnostic: IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4, IPv6 over IPv6, all work without problems. Kind regards, Job
Sent from my iPad On Apr 9, 2011, at 4:31 AM, Job Snijders <job@instituut.net> wrote:
Dear All,
On 8 Apr 2011, at 19:34, Lori Jakab wrote:
On 04/08/2011 06:39 PM, Owen DeLong wrote:
LISP can also be a good option. Comes with slightly more overhead in terms of encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality for IPv4 (which GRE supports nicely).
Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP.
Comparing GRE with LISP is like comparing /etc/hosts with the global DNS system. ;-)
I don't understand the comments about LISP and IPv4. IPv4 works just excellent with LISP. I have a IPv4 block at home which I multi-home over my IPv6-only DSL and IPv4-only FTTH line.
LISP is pretty address family agnostic: IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4, IPv6 over IPv6, all work without problems.
Kind regards,
Job
Doing IPv4 LISP on any kind of scale requires significant additional prefixes which at this time doesn't seem so practical to me. Owen
On 9, Apr, 2011, at 16:00 , Owen DeLong wrote:
Sent from my iPad
On Apr 9, 2011, at 4:31 AM, Job Snijders <job@instituut.net> wrote:
Dear All,
On 8 Apr 2011, at 19:34, Lori Jakab wrote:
On 04/08/2011 06:39 PM, Owen DeLong wrote:
LISP can also be a good option. Comes with slightly more overhead in terms of encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality for IPv4 (which GRE supports nicely).
Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP.
Comparing GRE with LISP is like comparing /etc/hosts with the global DNS system. ;-)
I don't understand the comments about LISP and IPv4. IPv4 works just excellent with LISP. I have a IPv4 block at home which I multi-home over my IPv6-only DSL and IPv4-only FTTH line.
LISP is pretty address family agnostic: IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4, IPv6 over IPv6, all work without problems.
Kind regards,
Job
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. Luigi
Owen
On Apr 11, 2011, at 5:12 AM, Luigi Iannone wrote:
On 9, Apr, 2011, at 16:00 , Owen DeLong wrote:
Sent from my iPad
On Apr 9, 2011, at 4:31 AM, Job Snijders <job@instituut.net> wrote:
Dear All,
On 8 Apr 2011, at 19:34, Lori Jakab wrote:
On 04/08/2011 06:39 PM, Owen DeLong wrote:
LISP can also be a good option. Comes with slightly more overhead in terms of encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality for IPv4 (which GRE supports nicely).
Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP.
Comparing GRE with LISP is like comparing /etc/hosts with the global DNS system. ;-)
I don't understand the comments about LISP and IPv4. IPv4 works just excellent with LISP. I have a IPv4 block at home which I multi-home over my IPv6-only DSL and IPv4-only FTTH line.
LISP is pretty address family agnostic: IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4, IPv6 over IPv6, all work without problems.
Kind regards,
Job
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.
Luigi
Who said anything about BGP? I was talking about the amount of additional IP space needed vs. the amount of IPv4 free space remaining. Owen
On 11, Apr, 2011, at 15:17 , Owen DeLong wrote: [snip]
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.
Luigi
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. 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? Or I missed the point again? thanks Luigi
Owen
On Apr 11, 2011, at 6:30 AM, Luigi Iannone wrote:
On 11, Apr, 2011, at 15:17 , Owen DeLong wrote:
[snip]
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.
Luigi
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 IP numbers.
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. Owen
thanks
Luigi
Owen
On 11, Apr, 2011, at 15:37 , Owen DeLong wrote:
On Apr 11, 2011, at 6:30 AM, Luigi Iannone wrote:
On 11, Apr, 2011, at 15:17 , Owen DeLong wrote:
[snip]
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.
Luigi
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?
No, those are the IP address that you provider gives to your border router.
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.
Not exactly. You do not need more space. You re-use what you have.
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 IP numbers.
No true. I ask for a PI block that I will use as EID-Prefix, then the locators are part of the address space of my providers. There is no duplication.
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.
IMHO it is very simple. As any new technology there is just a learning curve to follow, but for LISP it is not steep ;-) Luigi
Owen
thanks
Luigi
Owen
On Apr 11, 2011, at 8:15 AM, Luigi Iannone wrote:
On 11, Apr, 2011, at 15:37 , Owen DeLong wrote:
On Apr 11, 2011, at 6:30 AM, Luigi Iannone wrote:
On 11, Apr, 2011, at 15:17 , Owen DeLong wrote:
[snip]
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.
Luigi
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?
No, those are the IP address that you provider gives to your border router.
Right... In addition to my provider independent addresses... That's more address space than is required if I am not using LISP.
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.
Not exactly. You do not need more space. You re-use what you have.
Still confused, then. This seems antithetical to what you said above and below...
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 IP numbers.
No true. I ask for a PI block that I will use as EID-Prefix, then the locators are part of the address space of my providers. There is no duplication.
Right... Ordinarily, without LISP, I get a PI block and use that for EID and the routing is based on the EID prefix. With LISP, the EID prefix is PI and I use additional PA resources to do the routing locators. That's what I meant by duplication. There are additional PA resources required on top of the PI in order to make LISP work.
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.
IMHO it is very simple. As any new technology there is just a learning curve to follow, but for LISP it is not steep ;-)
I'd agree with you if it weren't for the fact I keep thinking I just about understand LISP and then get told that my understanding is incorrect (repeatedly). Owen
Luigi
Owen
thanks
Luigi
Owen
On Mon, Apr 11, 2011 at 11:26 AM, Owen DeLong <owen@delong.com> wrote:
I'd agree with you if it weren't for the fact I keep thinking I just about understand LISP and then get told that my understanding is incorrect (repeatedly).
I agree it is not simple. At a conceptual level, we can think of existing multi-homing practices as falling into one of three broad categories: 1) more state in DFZ -- end-site injects a route into BGP 2) triangular routing -- tunnel/circuits/etc to one or more upstream routers while not injecting anything to DFZ 3) added work/complexity on end-host -- SCTP and friends LISP is a compromise of all these things, except #3 happens on a router which does tunneling, not the end-host. Whether you think it's "the best of both [three?] worlds," or the worst of them, is up to you. I personally believe LISP is a horrible idea that will have trouble scaling up, because a large table of LISP mappings is not any easier to store in FIB than a larger DFZ. The "solution" the LISP folks think works for this is a side-chain mapping service which the router can query to setup encapsulation next-hops on-demand, which means if your FIB isn't big enough to hold every mapping entry, you are essentially doing flow-based routing, but with "flows" defined as being toward a remotely-defined end-site rather than toward an individual IP address (so not quite as bad as "flow-based routing" of the past, but still bad.) Maybe I also don't understand LISP and need to RTFM more, but my current understanding is that it is a dead-end technology without the ability to dramatically scale up the number of multi-homed end-sites in a cheaper manner than what is done today with BGP. I think we would be better off with more work on things like SCTP. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Mon, Apr 11, 2011 at 9:19 AM, Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Mon, Apr 11, 2011 at 11:26 AM, Owen DeLong <owen@delong.com> wrote:
I'd agree with you if it weren't for the fact I keep thinking I just about understand LISP and then get told that my understanding is incorrect (repeatedly).
I agree it is not simple.
At a conceptual level, we can think of existing multi-homing practices as falling into one of three broad categories: 1) more state in DFZ -- end-site injects a route into BGP
2) triangular routing -- tunnel/circuits/etc to one or more upstream routers while not injecting anything to DFZ
3) added work/complexity on end-host -- SCTP and friends
LISP is a compromise of all these things, except #3 happens on a router which does tunneling, not the end-host. Whether you think it's "the best of both [three?] worlds," or the worst of them, is up to you.
I personally believe LISP is a horrible idea that will have trouble
Yep.
scaling up, because a large table of LISP mappings is not any easier to store in FIB than a larger DFZ. The "solution" the LISP folks think works for this is a side-chain mapping service which the router can query to setup encapsulation next-hops on-demand, which means if your FIB isn't big enough to hold every mapping entry, you are essentially doing flow-based routing, but with "flows" defined as being toward a remotely-defined end-site rather than toward an individual IP address (so not quite as bad as "flow-based routing" of the past, but still bad.)
Maybe I also don't understand LISP and need to RTFM more, but my current understanding is that it is a dead-end technology without the ability to dramatically scale up the number of multi-homed end-sites in a cheaper manner than what is done today with BGP.
I think we would be better off with more work on things like SCTP.
+1 SCTP and IPv6, then ILNP.
-- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Apr 11, 2011, at 9:19 AM, Jeff Wheeler wrote:
On Mon, Apr 11, 2011 at 11:26 AM, Owen DeLong <owen@delong.com> wrote:
I'd agree with you if it weren't for the fact I keep thinking I just about understand LISP and then get told that my understanding is incorrect (repeatedly).
I agree it is not simple.
At a conceptual level, we can think of existing multi-homing practices as falling into one of three broad categories: 1) more state in DFZ -- end-site injects a route into BGP
Yep... This is clearly the best currently available mechanism.
2) triangular routing -- tunnel/circuits/etc to one or more upstream routers while not injecting anything to DFZ
I think what I am currently doing is a form of 1.5 for lack of a better term. I have multiple tunnels to multiple providers over multiple other connections.
3) added work/complexity on end-host -- SCTP and friends
Ah, yes, I think SHIM6 shows up here, too, no?
LISP is a compromise of all these things, except #3 happens on a router which does tunneling, not the end-host. Whether you think it's "the best of both [three?] worlds," or the worst of them, is up to you.
I'm not convinced one way or the other yet since I haven't been able to wrap my (admittedly perhaps limited) brain around LISP well enough to become convinced I understand it enough to make said call. I do tend to think that any technology sufficiently confusing that I cannot understand it well after reasonable effort is of questionable value for wide deployment.
I personally believe LISP is a horrible idea that will have trouble scaling up, because a large table of LISP mappings is not any easier to store in FIB than a larger DFZ. The "solution" the LISP folks think works for this is a side-chain mapping service which the router can query to setup encapsulation next-hops on-demand, which means if your FIB isn't big enough to hold every mapping entry, you are essentially doing flow-based routing, but with "flows" defined as being toward a remotely-defined end-site rather than toward an individual IP address (so not quite as bad as "flow-based routing" of the past, but still bad.)
This is one of the few parts of LISP I do understand and I'm not entirely convinced that it is all that bad because you don't have to do this on core routers, you can push it out pretty close to the customer edge, possibly even on the customer side of said edge.
Maybe I also don't understand LISP and need to RTFM more, but my current understanding is that it is a dead-end technology without the ability to dramatically scale up the number of multi-homed end-sites in a cheaper manner than what is done today with BGP.
I'm not 100% convinced of that.
I think we would be better off with more work on things like SCTP.
I'm not a fan of SCTP, and I think getting enough application level support for it is going to be a bigger uphill battle between chickens and eggs than the IPv6 deployment efforts of the last 5 years. Owen
On Mon, Apr 11, 2011 at 2:03 PM, Owen DeLong <owen@delong.com> wrote:
I do tend to think that any technology sufficiently confusing that I cannot understand it well after reasonable effort is of questionable value for wide deployment.
The secret is to ignore all the crazy acronyms and boil it down to this -- LISP sets up tunnels to remote end-points based on what it learns from a mapping server, and these tunnels may be used by one or more end-to-end flows.
I personally believe LISP is a horrible idea that will have trouble scaling up, because a large table of LISP mappings is not any easier to store in FIB than a larger DFZ. The "solution" the LISP folks This is one of the few parts of LISP I do understand and I'm not entirely convinced that it is all that bad because you don't have to do this on core routers, you can push it out pretty close to the customer edge, possibly even on the customer side of said edge.
We already have this in the core today, thanks to MPLS. The problem with LISP is the router that does encapsulation, which you can think of as conceptually identical to a PE router, must have a large enough FIB for all simultaneous flows out of the customers behind that PE router. This may be a very large number for an end-user PE router with a bunch of subscribers behind it running P2P file sharing, and may also be very large for a hosting shop with end-users from all over the globe downloading content. In the case of a CDN, one distributed CDN node may have far fewer active flows (installed in FIB) than the size of the DFZ, since the CDN would intend to direct end-users to a geographically-local CDN node. As you know, I like to think of what happens when you receive a DDoS. In the case of LISP, if there are a huge number of source addresses sending just one packet to you that generates some kind of reply, your PE router will query its mapping server, install a new tunnel/next-hop, and transmit the reply packet. If the FIB is not large enough to install every flow, it will churn, creating a DoS condition essentially identical to what we saw with older flow-cache based routers when they were subjected to traffic to/from a very large number of hosts. Like you, I am not 100% sure of my position on LISP, but I do think I understand it has a very serious design limit that probably doesn't make things look any better than "polluting" the DFZ from the perspective of content providers or end-user ISPs. It does have benefits from the carrier perspective because, as you say, it can move the "PE router" into the customer's network and move state information from the carrier to the edge; but I think this comes at a high complexity cost and might result in overall more work/cost for everyone. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On 11, Apr, 2011, at 23:53 , Jeff Wheeler wrote:
On Mon, Apr 11, 2011 at 2:03 PM, Owen DeLong <owen@delong.com> wrote:
I do tend to think that any technology sufficiently confusing that I cannot understand it well after reasonable effort is of questionable value for wide deployment.
The secret is to ignore all the crazy acronyms and boil it down to this -- LISP sets up tunnels to remote end-points based on what it learns from a mapping server, and these tunnels may be used by one or more end-to-end flows.
I personally believe LISP is a horrible idea that will have trouble scaling up, because a large table of LISP mappings is not any easier to store in FIB than a larger DFZ. The "solution" the LISP folks This is one of the few parts of LISP I do understand and I'm not entirely convinced that it is all that bad because you don't have to do this on core routers, you can push it out pretty close to the customer edge, possibly even on the customer side of said edge.
We already have this in the core today, thanks to MPLS. The problem with LISP is the router that does encapsulation, which you can think of as conceptually identical to a PE router, must have a large enough FIB for all simultaneous flows out of the customers behind that PE router. This may be a very large number for an end-user PE router with a bunch of subscribers behind it running P2P file sharing, and may also be very large for a hosting shop with end-users from all over the globe downloading content.
This is not true. There are several works out there showing that the FIB will not grow as you are saying. Luigi
In the case of a CDN, one distributed CDN node may have far fewer active flows (installed in FIB) than the size of the DFZ, since the CDN would intend to direct end-users to a geographically-local CDN node.
As you know, I like to think of what happens when you receive a DDoS. In the case of LISP, if there are a huge number of source addresses sending just one packet to you that generates some kind of reply, your PE router will query its mapping server, install a new tunnel/next-hop, and transmit the reply packet. If the FIB is not large enough to install every flow, it will churn, creating a DoS condition essentially identical to what we saw with older flow-cache based routers when they were subjected to traffic to/from a very large number of hosts.
Like you, I am not 100% sure of my position on LISP, but I do think I understand it has a very serious design limit that probably doesn't make things look any better than "polluting" the DFZ from the perspective of content providers or end-user ISPs. It does have benefits from the carrier perspective because, as you say, it can move the "PE router" into the customer's network and move state information from the carrier to the edge; but I think this comes at a high complexity cost and might result in overall more work/cost for everyone.
-- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Tue, Apr 12, 2011 at 4:59 AM, Luigi Iannone <luigi@net.t-labs.tu-berlin.de> wrote:
This is not true. There are several works out there showing that the FIB will not grow as you are saying.
Having taken some time to discuss this off-list with Luigi. I'd already read the paper he had in mind, which does not address DoS or prefix growth as the number of multi-homed sites, or single-homed sites with "PI blocks," increases. In effect, that paper and other works on this subject fail to consider what happens when one of LISP's goals actually becomes true: more wide-spread adoption of its technology to enable branch offices and other end-users to become multi-homed, or avoid renumbering. Plain and simple, it does not scale up any better than injecting more routes into the DFZ, unless you 1) accept macro-flow-based routing; or 2) scale up the size of your FIB along with the much larger number of prefixes which would be introduced by lowering the barrier-to-entry for multi-homing and provider-independent addressing. However, LISP does have non-Internet applications which are interesting. You can potentially have multi-homed connectivity between your own branch offices, using one or more public Internet connections at each branch, and your own private mapping servers which know the state of reachability from one branch to the others. In effect, it can become "poor man's L3VPN." Beyond non-Internet applications such as this, I think LISP is useful largely as a case study for what happens when a bunch of engineers get together and "solve" some problems they do not understand -- DFZ size/growth being chief among them. Like others, I still leave room for the possibility that I am wrong about this. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On 4/13/11 12:13 PM, Jeff Wheeler wrote:
However, LISP does have non-Internet applications which are interesting. You can potentially have multi-homed connectivity between your own branch offices, using one or more public Internet connections at each branch, and your own private mapping servers which know the state of reachability from one branch to the others. In effect, it can become "poor man's L3VPN."
Beyond non-Internet applications such as this, I think LISP is useful largely as a case study for what happens when a bunch of engineers get together and "solve" some problems they do not understand -- DFZ size/growth being chief among them.
They moved the problem along, that's what indirection does. to borrow from david wheeler: "All problems in computer science can be solved by another level of indirection... Except for the problem of too many layers of indirection." It could be that ultimately what passes for end-system/network multihoming moved up the stack to application layer overlays that already incur the overhead associated with building such a topology.
Like others, I still leave room for the possibility that I am wrong about this.
On 2011-04-13 21:13, Jeff Wheeler wrote:
Plain and simple, it does not scale up any better than injecting more routes into the DFZ, unless you 1) accept macro-flow-based routing; or 2) scale up the size of your FIB along with the much larger number of prefixes which would be introduced by lowering the barrier-to-entry for multi-homing and provider-independent addressing.
LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants do drag around the world and advertise in a number of places, specially with IPv6. And that's exactly what LISP had in mind - to prevent massive explosion of FIB for IPv6. For IPv4 the battle was lost somewhat already - and even for that, with LISP you can actually reverse the trend, by moving back with the allocations. As the control plane of the whole system is moved off the edge routers into potentially very capable servers, you also have the extra potential of actually shaping the policies for traffic engineering dynamically without affecting routing nodes. We may of course argue that the current routers are pretty capable in terms of processing power for control-plane, but the convergence times for exchanging and calculating prefixes for VPNs in a large (1-2-3-5M+) L3VPN deployments are counted in tens of minutes, not in seconds. Calculating them offsite and just dumping per-router-calculated table would be more efficient and faster.
However, LISP does have non-Internet applications which are interesting. You can potentially have multi-homed connectivity between your own branch offices.
If the LISP is deployed by commercial entities, just as Google and Facebook are experimenting right now, LISP would also mean multihoming, load-balancing and trafic engineering options that are today not available with BGP or highly limited in the accuracy.
Beyond non-Internet applications such as this, I think LISP is useful largely as a case study for what happens when a bunch of engineers get together and "solve" some problems they do not understand -- DFZ size/growth being chief among them.
Can't comment on that. I personally find Vince Fuller, Dino Farinacci, Dave Meyer and Darrel Lewis quite knowledgeable in routing and proficient in explaining why the LISP was created in the first place, but you of course may know better. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net
2011/4/18 Lukasz Bromirski <lukasz@bromirski.net>:
LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants
I strongly disagree with the assumption that the number of locations/sites would remain static. This is the basic issue that many folks gloss over: dramatically decreasing the barrier-to-entry for multi-homing or provider-independent addressing will, without question, dramatically increase the number of multi-homed or provider-independent sites. LISP "solves" this problem by using the router's FIB as a macro-flow-cache. That's good except that a site with a large number of outgoing macro-flows (either because it's a busy site, responding to an external DoS attack, or actually originating a DoS attack from a compromised host) will cripple that site's ITR. In addition, the current negative mapping cache scheme is far from ideal. I've written a couple of folks with a provably superior scheme (compared to existing work), and have received zero feedback. This is not good.
We may of course argue that the current routers are pretty capable in terms of processing power for control-plane, but
We agree that the ability to move tasks from the router to an external control plane is good. BGP may get better at this as time goes on, too. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On 2011-04-18 21:18, Jeff Wheeler wrote:
I strongly disagree with the assumption that the number of locations/sites would remain static.
It would grow, nobody said it would remain static. But still - it will grow slower than the number of new "full" allocations - covering both location *and* id.
LISP "solves" this problem by using the router's FIB as a macro-flow-cache. That's good except that a site with a large number of outgoing macro-flows (either because it's a busy site, responding to an external DoS attack, or actually originating a DoS attack from a compromised host) will cripple that site's ITR.
Scalability is one of the points traditionally left for the end, but that's hardly different from any protocol that was designed and then put into mainstream use. Second - you actually don't know that for sure - the mix of "from LISP" and "from normal IP" traffic would change in time, and the natural grow of the capabilities with the higher adoption would propably also affect ITR/ETR scalability numbers.
In addition, the current negative mapping cache scheme is far from ideal. I've written a couple of folks with a provably superior scheme (compared to existing work), and have received zero feedback. This is not good.
You mean LISP authors? -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net
On Apr 18, 2011, at 12:18 PM, Jeff Wheeler wrote:
2011/4/18 Lukasz Bromirski <lukasz@bromirski.net>:
LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants
I strongly disagree with the assumption that the number of locations/sites would remain static. This is the basic issue that many folks gloss over: dramatically decreasing the barrier-to-entry for multi-homing or provider-independent addressing will, without question, dramatically increase the number of multi-homed or provider-independent sites.
Done properly, a multi-homed end-site does not need to have its own locator ID, but, could, instead, use the locator IDs of all directly proximate Transit ASNs. I don't know if LISP particularly facilitates this, but, I think it would be possible generically in a Locator/ID based system.
LISP "solves" this problem by using the router's FIB as a macro-flow-cache. That's good except that a site with a large number of outgoing macro-flows (either because it's a busy site, responding to an external DoS attack, or actually originating a DoS attack from a compromised host) will cripple that site's ITR.
The closer you move the ITRs to the edge, the less of an issue this becomes.
Owen
On Apr 18, 2011, at 10:09 PM, Owen DeLong wrote:
On Apr 18, 2011, at 12:18 PM, Jeff Wheeler wrote:
2011/4/18 Lukasz Bromirski <lukasz@bromirski.net>:
LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants
I strongly disagree with the assumption that the number of locations/sites would remain static. This is the basic issue that many folks gloss over: dramatically decreasing the barrier-to-entry for multi-homing or provider-independent addressing will, without question, dramatically increase the number of multi-homed or provider-independent sites.
Done properly, a multi-homed end-site does not need to have its own locator ID, but, could, instead, use the locator IDs of all directly proximate Transit ASNs.
This is exactly what LISP suggests. Your locators are provided by your provider. Luigi
I don't know if LISP particularly facilitates this, but, I think it would be possible generically in a Locator/ID based system.
LISP "solves" this problem by using the router's FIB as a macro-flow-cache. That's good except that a site with a large number of outgoing macro-flows (either because it's a busy site, responding to an external DoS attack, or actually originating a DoS attack from a compromised host) will cripple that site's ITR.
The closer you move the ITRs to the edge, the less of an issue this becomes.
Owen
In a message written on Mon, Apr 18, 2011 at 08:44:03PM +0200, Lukasz Bromirski wrote:
LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants do drag around the world and advertise in a number of places, specially with IPv6. And that's exactly what LISP had in mind - to prevent massive explosion of FIB for IPv6.
I would agree with this statement if and only if you qualified it with "for the default free zone (DFZ)". LISP reduces the number of routes in the DFZ by making each route represent a "location". However, like the proverbal balloon, when squeezed on one end the other side gets larger. LISP does this by introducing an entirely new infrastructure, the mapping servers. These must now scale to meet the demands that will be placed on them. LISP also does this by making the edge box responsible for looking up and caching information on the flows going through it. In this way LISP, on a worldwide basis, very closely resembles a Cisco 7500 Chassis circa 1996 with "flow caching". The mapping servers are the RP, the DFZ is the backplane, and the edge boxes are the linecards. In both designs when the first packet comes in a lookup is made to the central authority, and a cache entry is placed down at the entry processor. The backplane is dumb and fast. Anyone familar with then enviornments where a 7500 performed poorly should be able to immediately detect where a LISP architecture will perform poorly. Any events which invalidate the cache will result in a period of extremely high usage on the mapping servers likely with extremely high packet loss until all entries are resolved. Any edges which talk to a significant number of other networks will have to cache a significant portion of the Internet, which will actually lead to edge boxes having to be larger than they are now. It is the last point I find most interesting about LISP. Today someone who wants to route their own address space at 10G can buy any number of cheap L3 devices with enough RAM and CPU to hold the internal routes and a default pointed at their provider. The provider's boxes keep the full table and move the packets to where they need to go. In a LISP world that edge box would be set up to do map/encap, and thus would need to keep cache entries for all active addresses, which for a busy site is potentially the entire table. The service provider box now no longer needs to know about all destinations, and thus can have a smaller table or be upgraded less often. [Note, while I describe the edge here as customer owned, it's entirely possible it may be ISP owned and managed for the customer, a cost of which I'm sure they would fully pass on.] To my mind then, LISP moves these tables from a few thousand DFZ routers managed (generally) by well staffed engineering teams to tens or hundreds of thousands of edge boxes, in many cases managed by the clueless. Many edge proponents will say it's easier to upgrade the edge than the core, so this is a win. Vendors may like the idea of 100,000 boxes needing the resources to hold most of a table, rather than 1,000. If the Internet had started out with a LISP design from scratch I'm not sure it would be any better, or worse than our current configuration. Back to the balloon, it trades cost and complexity in one area for cost and complexity in another area. In that sense I am neither against it nor for it, it's just 'different'. The problem is we don't live in a LISP world. To go there now would be a wholesale conversion from what we are doing. Granted, the LISP folks have designed something that is relatively easy to convert to, so they are making an effort. Still, to justify a conversion and the engineering time and business risk it would have to be significantly better. Like 2x-4x better, and preferably an order of magnitude. That's where I'm just not seeing it with LISP, yet. I hope the LISP guys keep working on this, they are at the moment the only credible alternative I've seen to our current system in my lifetime. It's just not good enough to justify a switch based on the current world conditions and state of the solution; at least to me. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 2011-04-18 21:50, Leo Bicknell wrote:
To my mind then, LISP moves these tables from a few thousand DFZ routers managed (generally) by well staffed engineering teams to tens or hundreds of thousands of edge boxes, in many cases managed by the clueless.
This is something out of practical world that would have to be considered obviously. OTOH it is the prefix originating site that controls who and how will see the prefixes, not the traffic source site. Having control over what and to whom you advertise, you have the capability to "not being announced" to the "clueless".
The problem is we don't live in a LISP world. To go there now would be a wholesale conversion from what we are doing. Granted, the LISP folks have designed something that is relatively easy to convert to, so they are making an effort.
The LISP adventure is not as simple as "go from A to Z" - it may end up today if the test network decides to disband with no hurt to anyone. It may decide to go on and convert only the sites willing, which is actually what happens right now - giving benefits to users, and normal service for anyone else. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net
On Apr 18, 2011, at 9:50 PM, Leo Bicknell wrote:
Any edges which talk to a significant number of other networks will have to cache a significant portion of the Internet, which will actually lead to edge boxes having to be larger than they are now.
This is not accurate. For networks with more than 20K users you can have a lisp cache as small as 15K entries. (http://www.net.t-labs.tu-berlin.de/research/publications/Publi//KIF-LMDDILCW...) Luigi
On 11, Apr, 2011, at 17:26 , Owen DeLong wrote:
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?
No, those are the IP address that you provider gives to your border router.
Right... In addition to my provider independent addresses... That's more address space than is required if I am not using LISP.
No, you just use the IP addresses of the interface to your upstream as "locators". Those addresses are there anyway, right? So using LISP is not adding anything.
No true. I ask for a PI block that I will use as EID-Prefix, then the locators are part of the address space of my providers. There is no duplication.
Right... Ordinarily, without LISP, I get a PI block and use that for EID and the routing is based on the EID prefix. With LISP, the EID prefix is PI and I use additional PA resources to do the routing locators. That's what I meant by duplication. There are additional PA resources required on top of the PI in order to make LISP work.
I still do not see this duplication (may be I need more coffee this morning..) You do not need to modify anything in the PA space of your provider. Those resources are there and are used to make your block reachable also without LISP. Luigi
participants (20)
-
Cameron Byrne -
Daniel STICKNEY -
isabel dias -
Jeff Wheeler -
Job Snijders -
Joe Abley -
Joe Maimon -
Joel Jaeggli -
Leo Bicknell -
Lori Jakab -
Luigi Iannone -
Lukasz Bromirski -
Mark Andrews -
Michel de Nostredame -
Owen DeLong -
Randy Bush -
Seth Mattinen -
Tassos Chatzithomaoglou -
Tom Limoncelli -
Tomas Podermanski