On Tue, Jul 26, 2011 at 1:02 AM, Dino Farinacci <[email protected]> wrote:
> No, no, no. I don't know where to start to reply to this. I can't actually > because I don't understand the sequence and believe it contradicts itself. I'll start over and skip the first case, and trying to simplify my questions/concerns in parts. Let me first describe the environment to check that I have understood LISP correctly. We are in the future and LISP has been deployed. There are residences that have IPv6 in their local networks but the DFZ is still only using IPv4, then there is one content site (providing IPv6 based services) that the residences are reaching by using LISP. The packet flow goes as following (jump in where I get lost): The ITR at the residence (hereafter called rITR) receives a packet from the local network, there is no entry in the cache for the destination and thus it consults the MS. The rITR receives a reply from MS, creates the cache entry and adds the LISP header to the packet and the encapsulated packet is routed to the ETR of the content site (cETR). The cETR removes the LISP header and the packet is routed to the server of the content site. Since this is a valid connection, the server replies and the packet is routed to the ITR of the content site (cITR), No cache entry exists, thus the cITR is consulting the MS, a reply is received, a cache entry is created at the cITR and the returning packet gets encapsulated and routed over DFZ to the ETR taking care of the residence (rETR). The rETR removes the LISP header and the session is established. If I got it so far right, we can proceed to the next step - if not, stop reading There is an event - there are about 200 000 residences behind rITRs (no residence shares an rITR) that want to buy a ticket from the content site at a certain day and time. Thus these residences logs into the server at the content site slightly before the ticket sale begins. For DNS and rITR lookup at MS there are no issues, the distributed DNS cache architecture prevents that authoritative DNS server doesn't get all requests - and I guess that is similar for the MS. No issues exists at the cETR either. But for the returning packets at the cITR I have _questions_. For returning packets there is no need to do DNS lookups but if I have understood LISP correctly the cITR needs to do MS lookups so that returning packets gets routed back to the residences. If the cITR uses only one MS server there will be intensive traffic between the cITR and the MS server - and I think the cache mechanism used in DNS can not be applied here, right?? Also the MS server and cITR aren't necessary located in the same premises, the round trip delay between cITR and MS most likely will have an impact on the time it takes to build 200 000 new cache entries. And if the MS provider has installed a bad performing MS server then that will further have an impact on how fast the cITR's cache is built. The status of my forwarding plane is no longer solely in my hands. The major difference with today's architecture is that there is no need to do a lookup in DNS for returning traffic, thus we cannot completely compare DNS and MS scalability - I think there is a new pattern in MS that doesn't exist in DNS, but I might have it wrong. If the cITR cache doesn't scale enough and I would prefer to add a second cITR (instead of using the PITR) to deal locally with my cache issues. How do I ensure that the returning packets are routed to the correct cITRs? No changes is applied on the server stack and thus there is a 0/0 route at the server pointing to one next-hop. Should I install a server load balancer in front of the two cITRs to fix this? Patrick _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
