And I am not saying LISP will or will not be able to handle it. I am just asking how it will handle it ;) Maybe the answer is to in the moment of exceeding capacity threshold of any xTR push some of the traffic to few bigger proxies ... just a thought.
Our LISP-MN implementation right now stores a single map-cache entry to a re-encapsulating LISP router. So just like you have a default route in a home router, you can have a default map-cache entry. And the data plane stretch can be the same if the re-encapsulating router is in the PE router provisioned with a product that has larger FIB capacity.
And if that PE router is a PITR connected to the ALT, it knows right away if the destination is a LISP site or a non-LISP site. When the destination is a non-LISP site, it forwards packet in hardware because it has a FIB route (via BGP), and when the destination is a LISP site, it can send a Map-Request and build the map-cache.
So the DOS attack on non-LISP sites is mitigated because BGP is in use and is no worse than today. A DOS attack on LISP sites can be bounded by the size of each EID-prefix. Not perfect, but that is what we have so far.
Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
