routing table go boom

William Herrin bill at herrin.us
Wed Mar 20 18:51:22 UTC 2013


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




More information about the NANOG mailing list