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

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

Dmitri,

> The traffic engineering (TE) extensions to IGPs (Brad's
> multiple metrics, I assume) or the multiprotocol extension
> to BGP treat the corresponding routing protocol as an
> information distribution tool only. The protocol itself is
> not used to avoid routing loops. Some external (and not
> immediately obvious) methods are required for loop
> avoidance.

Correct... 

This can be implemented by multiple methods... (e.g. 
defined ordering (ala bgp) or tagging
requests)... since we don't know what the protocol is
going to look like, we just say that advertisements and
routing decisions should not loop


> The point I'm trying to make is that:
> - if the RRS peering protocol (RPP) model is as one of BGP
>   in RFC2547, then some explicitly external to RPP loop
>   avoidance mechanism is required;
> - if the BGP loop avoidance method (path-vector) is chosen
>   instead and optimal metrics from the draft are defined
>   as optimal attributes *and* used in the route selection
>   algorithm (by "route selection" I mean what is described
>   in Section 9.1 of RFC1771, for example), then I can not
>   see how one can claim that to come up with such an
>   algorithm causing no global route selection inconsistencies
>  (read, no route oscillations) is an easy task.

I agree with your statement assuming the following:
	1. an arbitrary topology with attributes all transitive
	2. no routing information attached to requests

addressing #1:

- I think there will be many "nontransitive" metrics
which are exchanged between just two providers... 

- I also believe that request routing systems will 
be connected in full meshes (as opposed to the Internet 
routing topology partial mesh).  


addressing #2:

You have made the assumption that requests themselves
don't contain routing information which I don't think is
a fair assumption... an easy fix is to tag requests with
path vectors... (note: this obviously doesn't translate for 
regular ip routing)... this is "in-line" loop prevention


in summary:
	1. we all want the protocol to be *extensible* for
	multiple metrics which is why it is part of the
	requirements
	2. we don't know HOW we will perform loop prevention
	on the actual routing of requests... except perhaps
	through a default metric
	3. we don't know what information will be available
	in the request itself (which may assist in loop
	prevention)


there is only one alternative which is to just have one
metric (e.g. a generic 128 bit field) which is completely
arbitrarily set... [because we could never agree on
a single metric]...   I do believe that we will have a
default metric which will be generic


-brad