On Wed, Mar 20, 2013 at 11:42 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
William Herrin wrote:
I can't speak for LISP per se, but the general solution for map-encap systems like LISP is that the ITR tags the first packet to the ETR and some percentage of subsequent packets to the ETR with an ack request. If it doesn't get an ack from the ETR (not the final destination), then the ETR or the path to it is depreferenced.
As the ETR is not the final destination, it is subject to blackholing after ETR, which means:
The path from the ETR to the destination, and by extension the full path from the ITR to the destination, is not the ITR's responsibility.
Already had the correct answer in there; you didn't need to restate it.
It merely means that LISP is not end to end
Yeah. LISP provides virtual packet-switched data circuits. Like a metro-ethernet from here to my ISP. The protocols transiting LISP are what's end to end. And no aspect of LISP that I'm aware of compels changed behavior by those protocols.
Some local system is responsible for detecting connectivity between the ETR and destination and updating the destination-to-ETR map accordingly.
Some local system?
Yeah, you know, like OSPF or EIGRP. Just like exporting a route from the IGP to the EGP except that you're exporting a route from the IGP to the LISP map instead. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004