Re: [lisp] Comments on draft-fuller-lisp-alt-04

[Vince Fuller <[e-mail]>]

On Tue, Feb 17, 2009 at 05:14:41PM -0800, Dino Farinacci wrote:
>> The case where an EID prefix does exist in the LISP database but has  
>> no
>> reachable RLOCs is, in some sense, more interesting. Dino - what do is 
>> the
>> correct behavior for an aggregating ALT router in this case?
>
> No reachable RLOCs and no RLOCs in the map-cache entry are two different 
> things. For the former, you drop the packet, for the later you don't 
> encapsulate it because you have concluded that the site is not LISP 
> capable so you forward packet natively (unencapsulated).

That's what an ITR does if it is asked to forward a packet when an EID
prefix is shown as unreachable in it's map cache: if something (a map server
or ALT router) returned a negative Map-Reply indicating that a covering
prefix is not a LISP destination, then it fowards natively. If none of
the RLOCs are reachable, then the destination is unreachable and the ITR
drops the packet.

But what does an ALT router do if it receives a Map-Request for an EID-prefix
that is unreachable? If the ALT router knows a covering EID-prefix does not
exist in the ALT database, then it returns the negative Map-Reply. But what
if it knows that the EID-prefix does exist (i.e. it is configured to accept
the EID-prefix via BGP from one of its "downstream" ETRs) but it has no
mapping because either the BGP sessions to all downstream ETRs are down or
none of the downstream ETRs are actively advertising the EID-prefix?

Should it signal anything to the querying ITR that the ETRs are not reachable,
through ICMP or otherwise? If it simply drops the Map-Request, what will the
ITR do when it gets no response at all after some timeout? Conclude that the
destination is unreachable and drop any traffic to it? Conclude that the
ALT is broken and that it should try to forward the traffic natively?

	--Vince