Re: comments on draft-ietf-cain-request-routing-req-00.txt

[brad cain <bcain@mediaone.net>]

Dmitri Krioukov wrote:
> 
> I think that the draft follows the type of
> logic, which is quite opposite to the one
> suggested by Mark and Fred. Instead of
> trying to simplify, minimize and fix the
> set of requirements, the draft proposes to
> include and support all possibilities in
> the areas where trade-off between flexibility
> and simplicity should really be on the side
> of the latter.

I very much disagree... Altough the first draft may be
a bit confusing, the requirements are all based around
a simple advertisement architecture very much like
IP routing protocols... 

> 
> Just two examples:
> 
> 1) Support of various types of metric
> 
>    Wouldn't it be easier to support just
>    one standard metric or, at least, to fix
>    supported metrics to some reasonable
>    minimal set of required ones? CPGs are
>    then responsible for mapping the internal
>    proprietary set of metrics to this
>    standard one (either metric or a set of
>    metrics) and vice versa.

Most likely there will be one DEFAULT metric (ala OSPF) and
multiple other optional metrics.  The reasons for this are
very simple
	1. nobody can agree on a specific single metric -- we
	will most likely therefore have one single default
	metric.  the analogy is ip routing protocols.
	2. not supporting multiple metrics in the protocol
	is extremely shortsighted so we want to make it
	a requirement.  again, ip routing protocols have
	proved that this is invaluable.

 
> 2) Support of various types of RRSs
> 
>    Interconnected RRSs perform the function
>    of one global RRS. The function of *any*
>    RRS is to intelligently map the {client
>    IP address (prefix), URI} duplex to an ID
>    (which boils down to an IP address) of some
>    surrogate from the set of surrogates capable
>    of processing request for that URI.
>    "Intelligently" means that the minimal
>    metric (which is a function of all three --
>    client, URI and surrogate) is searched for.

Not true... there are TWO different DEPLOYED
type of architectures for request routing... BOTH
must be supported.. 
	1. "inline" case: this is the layer-7 or proxy
	case where URIs will be advertised
	2. the dns case: this is the common CDN case
	where only DNS names are visible.  this must
	be supported as well

>    So, what the RRS peering protocol MUST
>    do is to advertise URIs (possibly with some
>    "default" metrics), plus to be capable of
>    mapping {client, URI} requests to
>    corresponding {surrogate, metric}
>    responses. 

This is true for only #1 case above


>    In its current form, the corresponding
>    part of the draft:
>    - significantly complicated the protocol
>      design
>    - essentially violates the "black box"
>      approach to the individual RRSs
>    - does not allow for peering between RRSs
>      of different types
>    - does not support L3 (IP routing) based RRSs
>      (they are not popular but existent)
> 
> In general, the protocol satisfying the current
> set of requirements would look very fat and
> spooky. Interoperability would be the biggest
> issue with such a protocol. Some significant
> simplifications (like proposed above) are required.

I do admit that the protocol is SLIGHTLY more
complicated than what you desire.  However, that is
to accomodate the two types of request routing
systems that providers use. [interestingly the
case that you ignore (dns) is the more commonly
deployed]

Here is why the requirements can be used to form
a simple protocol:
	1. the requirements assume a simple "advertise and forget"
	model just like BGP
	2. a default metric is used with optional ones -- this does
	not complicate the protocol, only the policies which one
	may implement (analogy BGP).
	3. two types of advertisements can easily be supported by
	a type of "address family" (analogy: MBGP)
	4. selection decisions are made on a per request routing
	domain basis (barring loop prevention by for example a
	path vector algorithm)

In many ways the requirements can be supported by a simple
"BGP-like" protocol... I think this is fairly straightforward
and simple.

-brad