[161591] in North American Network Operators' Group
Re: routing table go boom
daemon@ATHENA.MIT.EDU (William Herrin)
Wed Mar 20 14:51:55 2013
In-Reply-To: <5149D8CD.6040401@necom830.hpcl.titech.ac.jp>
From: William Herrin <bill@herrin.us>
Date: Wed, 20 Mar 2013 14:51:22 -0400
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
