On Tue, Mar 10, 2009 at 02:04:11PM +1100, Robin Whittle wrote:
> Hi Dave,
> 
> I have replied to part of your message in another thread on LISP-ALT
> scaling.  "Level 1" means an ALT router at the lowest level of the
> highly aggregated inverted tree ALT hierarchy.
> 
> You wrote, in part:
> 
> >>      How can an ALT router, such as this busy level 1
> >>      aggregation router, detect the failure or
> >>      unreachability of a Map-Server?  I guess it would
> >>      find out when it tries to send a Map-Request message
> >>      to the Map-Server via the GRE tunnel.  But is there
> >>      a keepalive arrangement so the level 1 router could
> >>      detect the disappearance of this Map-Server before
> >>      it sends a Map-Request?
> >>
> >>      More on potential problems with caching Map-Resolvers.
> > 
> > 
> >   Regarding "upness": You can make the same argument for
> >   BGP peers in the DFZ (or DNS if you like). In the case of
> >   BGP, we use BGP keepalives, BFD (if you like), and the
> >   existence of the route in the RIB/FIB as basically a
> >   bunch of heuristics, which work pretty well (when was the
> >   last time you couldn't get to Google because of a routing
> >   problem on the Internet?). Hence we don't need to
> >   calculate some exact value of "upness" (which is a good thing).
> > 
> >   BTW, the question "is entity X up" really reduces to
> >   Zeno's paradox (think: what is the granularity of
> >   "upness", and how often do I need to ask?). And we know
> >   what it took to solve Zeno's paradox. But as mentioned
> >   above, we can do a fine job (within our engineering
> >   constraints) with clever heuristics. The operational
> >   Internet is pretty much an existence proof of that.
> 
> Your answer is pretty general and doesn't seem to apply to the
> specific situation of the Map-Server and ETR.

        You didn't ask a question. I was just noting that the
        question as to whether or not something is "up" is not
        well formed.

        Dave

        

Attachment: signature.asc
Description: Digital signature

_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to