> I would defer to Dino and others on the list, but I do not believe that the > ETR does a reverse lookup on every packet. At least that is not the behavior > we observe. What we see happen is that the packet is decapsulated
Right Paul. We did not document an ETR doing reverse lookups to solve this problem. When I mentioned it, I said it is something that COULD be done. It comes at a cost but wouldn't come at a per-packet cost, not even close. And as you said if the inner source is changing but the mapping system covers those addresses with a coarse prefix (that is returned from a lookup), then that reduces the number of RPF lookups, in addition to rate-limiting the number you do. But I would suggest that implementations do what they are already doing. That is what you describe here: > and sent to the destination. If a valid destination host responds, then the > ITR does a map-request for the reply packet. There is not a 1:1 relationship > between the number of packets and the number of map-requests. The mapping system is no different in its load then the DNS system. We engineer and build that infrastructure the same way to protect it. So how many more magnitudes of hosts are sending DNS queries than xTRs sending Map-Requests (and please normalize this to every site having at least 2 xTRs per site). We are over-reacting a bit, but just saying that is not going to calm fears. With continued experimentation and deployment, we will prove it. Dino P.S. Don't eat that burger today, it will kill you just like the cigarette you may smoke today. ;-) _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
