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

["Dmitri Krioukov" <dima@krioukov.net>]

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.

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.

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.

   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. CPGs are responsible for
   translating RR information obtained via
   internal proprietary RR methods into this
   standard information exchanged via the RRS
   peering protocol (RPR, DPR, APR, if three;
   CPR if one!).

   Examples of how the overall system would
   operate even in the complex cases (like
   peered RRSs of different types) are
   straightforward.

   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.
--
dima.