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

[Oliver Spatscheck <spatsch@research.att.com>]

Dima,

	I think your comment is well taken. The problem is that each
requirement seems to have somebody who really thinks it is needed. I
think part of the process we have to go through by the next IETF is to
go look at all the arguments to decided which one are really
required. Please remember there is a reason they call IETF drafts
drafts ... .

Dmitri Krioukov writes:
 > 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:

If you have more examples it would be helpful to discuss them on
the mailing list.

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

I think that is what we intend to propose. Maybe it didn't become
clear in the draft. I think the consensus was to require a minimal
set of metrics say one and to allow for custom metrics which
are on a peer to peer basis. The rational was to be similar
to BGP community strings (peer to peer custom metric) while
preventing the shortfall of community strings that even for
common metrics every set of peers has to reinvent the wheel
(small set of required metrics).

By the way it is easy to say there should be only one metric without
naming it. Asking five people what the one metric should be
I got six answers.

 > 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 clarify for me why your protocol would not fulfill the
requirements stated in the draft. Maybe we should change
the requirements which are violated. We haven't proposed any protocol
as of yet and a simple protocol for a complex set of requirements
is always a good solution.

 >    In its current form, the corresponding
 >    part of the draft:
 >    - significantly complicated the protocol
 >      design

Why?

 >    - essentially violates the "black box"
 >      approach to the individual RRSs

Why?

 >    - does not allow for peering between RRSs
 >      of different types

Why?

 >    - does not support L3 (IP routing) based RRSs
 >      (they are not popular but existent)
 > 

Didn't you just argue we already support to much?

Oliver