Subject: RE: Next question...

From: "Tony Li" <[email-masked]>
Date: Sun, 8 Dec 2002 02:02:34 -0800

|   > 2) Put the locators in the border router.  This frees the host
|   >    of the management burden, but makes it somewhat harder for the
|   >    host administrator to implement host specific policies without
|   >    the assistance of the administrator of the border router.  Host
|   >    specific policies can still be implemented, they just need to
|   >    be managed by the border router.  The number of unique host
|   >    policies can be a scalability issue for the border router.
|   
|   I would still like some hint from the host to the border 
|   router that the
|   current connection isn't working.

Not an unreasonable request.

|   If a host needs specific policies, would it be possible to "move the
|   border" for that host to that host? Then the real border 
|   routers only
|   have to pass the traffic without touching it and the host is in full
|   control, the border routers only get to say yes or no, 
|   which should be
|   enough to keep rogue sysadmins in check.

I think that this puts us firmly behind the dromedary.  Putting control
functionality in both places is more complicated than is truly 
necessary, IMHO, and thus is a fine candidate for Occam's Razor.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Sun, 08 Dec 2002 14:53:55 -0800

> Not an unreasonable request.

At first blush this may seem like a reasonable request, but there are so 
many reasons why a remote host would not respond that it would be 
impossible for the routing system to trust the local host with such 
requests.  For instance, perhaps the reason the remote host isn't 
responding is because the remote application has not properly 
authenticated the local user.  Another reason is that the remote host is 
down or misconfigured.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 9 Dec 2002 20:09:26 +0100 (CET)

> authenticated the local user.  Another reason is that the remote host is

I'm not sure if I understand what you're getting at the the issue of
trust.

But there is another problem: a site has many hosts. As you say, a host
can be down, but that doesn't mean a neighboring host is also down. So
if the SBR is going to reroute the traffic for a host a the source's
request, this must be done on a per-destination host basis, or the
source must request the alternate path in each individual packet, for
instance with a diffserv code point. Both of these are at least somewhat
problematic.

All of this makes me feel that doing this at the source host in the
first place might be a better solution in many cases.