On Wed, Mar 20, 2013 at 11:42 AM, Masataka Ohta <mo...@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 ................ her...@dirtside.com b...@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
