Jari, > Of course, I understand that pretty much any tunneling or translation > technique can be used for IPv6 deployment as well. I do not > mind if such > use case gets mentioned in a list of other potential uses of Lisp. > However, the main use case, deployment rationale, etc. needs > to stand on > its own and talk about routing scalability, traffic engineering, and > other things central to Lisp. Thanks for your note, I have a few comments that follow about the intended scope of LISP Interworking. I don't see a conflict with what you've written, but I want to try to clarify my position on LISP Interworking for the WG. A central design goal of LISP is that it be practical, that is, work within the existing, deployed, Internet. Today that Internet has a mixture of IPv4 only, dual stack, and IPv6 only hosts and networks. It also is comprised of a myriad of access technologies, security mechanisms, that LISP xTR must integrate with in order to be deployable. LISP attempts to solve the routing scalability problem for both IPv4 and IPv6, and therefore LISP sites must interwork with non-LISP sites of both IP protocols. A central benefit of network based Interworking is how it enables the benefits of LISP for the site which has deployed LISP: On ingress, using Proxy Ingress Tunnel Routers, this is primarily the enablement of LISP's Ingress Traffic Engineering features. One result of this is that LISP sites relying on Proxy Ingress Tunnel Routers will see all ingress traffic LISP encapsulated - and therefore see this benefit of LISP immediately. I might add, a second order benefit is that if the Proxy Ingress Tunnel Router's RLOCs are connected the a Dual Stack IPv4/IPv6 network, the connectivity from the Proxy Ingress Tunnel Router to the site's ETR does not have to be Dual Stack. Proxy Ingress Tunnel Routers also are a primary tool to encourage sites not to Inject EIDs into the Internet routing system. They in effect make EID's routable without direct injection (and inevitable degradation) of the EID space by individual sites. For a site using Proxy Egress Tunnel Routers on egress there are fewer LISP specific benefits. This is because LISP does not attempt to enhance Egress Traffic Engineering (instead utilizing the site's existing egress IP routing mechanics). The primary use cases for Proxy Egress Tunnel routers are actually only to address practical deployment concerns. These secondary issues include working around limitations to the installed access networks' implementation of BCP 38 filtering, and working around the lack of support found in access networks for dual stack IPv4 and IPv6. So this means that not every LISP-Site will need a Proxy Egress Tunnel Router, but we know from our experimentations to date that it will help some of LISP sites, and this instigated the ideas and proposed text found in this thread. Note that both of these network based approaches are not required if LISP-NAT (currently specified only for IPv4)is used. LISP NAT instead uses routable EIDs that fall within the Provider Assigned address space. But a LISP site using LISP-NAT misses out in the advantages of ingress TE above, and will obviously not be IPv6 capable. >I also understand that what we develop > technology X for may not be what it eventually gets used for; > we've been > surprised before. Lets see what happens with Lisp. But for > the RFCs that > come out of this working group, lets focus on the initial main reason > why Lisp was developed. > Understood, and I think we are. My opinion is that Proxy Egress Tunnel routers are an interesting option that I think will assist in LISP sites to communicate with non-LISP sites. -Darrel
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.