Please see remarks within.
Abbie barbir
-----Original Message-----
From: Dmitri Krioukov [mailto:dima@krioukov.net]
Sent: Thursday, January 25, 2001 10:09 PM
To: Cain, Brad
Cc: cdn
Subject: comments on draft-ietf-cain-request-routing-req-00.txt
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 think the draft indicated support for required metric(s) and optional ones. The floor is open on deciding the number of required metric(s). The bottom line in my view is that there should be such support.
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.
If you can get everyone to agree on such a (single) metric, I am ok with that ( I will buy the beer).
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.
Please elaborate with more examples. This is the kind of feedback that is needed.
In its current form, the corresponding
part of the draft:
- significantly complicated the protocol
design
Why? How? Clarify?
- essentially violates the "black box"
approach to the individual RRSs
Why? How? Clarify?
- does not allow for peering between RRSs
of different types
Why? How? Clarify?
- does not support L3 (IP routing) based RRSs
(they are not popular but existent)
Sometimes less is better. Can you show the need for this case?
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.
Spooky? (well I do not see that)
Interoperability as problem, this should not be the case if the protocol is well defined regardless of the degree of complexity.
Simplification, yes the work will focus on figuring out the list of absolutely required requirements with room for future growth.
Abbie