RE: hard questions: request routing

["Cain, Brad" <bcain@cereva.com>]

Francis,

> My argument for today:
> 
> * The details of the Request Routing mechanism matter
> 
> For some mechanisms (eg, DNS CNAME, HTTP redirect), lookups are
> "forwardable" for lack of a better term, and can transfer state
> (prepend my name to domain name to get path-vector, so I can check for
> a loop on a per-lookup basis).  Some others (eg, forwarding by L4/L7
> switch), are forwardable, but don't transfer state (at least not
> easily).  Finally, others (eg, URL rewriting) aren't forwardable (and
> so don't have forwarding loops).

actually, URL rewriting may be forwardable because it may be impossible
to tell whether the DNS name that was written is used for peering
(though it wouldn't be prudent to have this situation it is still 
possible)

> Question: Is the goal to have loop avoidance for all of these types of
> mechanisms (well, the last are easy since they can't loop)?  If it's
> just for DNS, then it can be embedded into the lookup protocol (more
> on this in a second); if it's got to cover L4/7 forwarding, then it
> can't (unless L7 forwarding is defined to require header adjustment).


(see my first email that started this thread on the 29th for a 
discussion about "soft-state" in dns... we discussed this at the ietf
and it didn't seem to fly)

> The reason I ask is that transient loops are going to be harder to
> take care of if the loop avoidance is in a separate mechanism.  Even
> if the loop avoidance protocol works correctly, there will always be
> asynchronies between the various Request Routers and gaps between the
> loop-avoidance and redirection parts (which can be probably be solved,
> but require more care).  

all routing protocols create loops during transient conditions (with
a few exceptions -- e.g. diffusion update protocols like eigrp).. we
are not trying to solve that problem... we just want loop free in
steady state which is difficult enough

> If there are non-state-transfering RR mechanisms, or if using these
> state-transfer hacks is deprecated, I think it be might easier simply
> to make all mechanisms non-forwardable (eg, there are two classes of
> DNS names, and compliant nameservers can only change class A into
> class B, not vice versa).  

when you "change" a name from forwardable to non-forwardable how do
you make the decision?

i guess some CDNs could classify themselves as "leaf only" but that
doesn't cover the general case.  otherwise you don't know if someone
else can make a better decision than you can (without global link
state topology which i am not assuming)

> On reflection, this may be the right way to go, regardless, because it
> treats all RR mechanisms uniformly.  This is similar in spirit to
> Oliver's suggestion to limit the hierarchy depth.  But maybe there are
> specific scenarios in mind that require deep forwarding hierarchies?

it may be easiest to start out with a "state advertisement" protocol
which does not specify routing decisions -- then only use it in
a two level hierarchy (where everyone can make their own decisions)

-brad