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

[brad cain <bcain@mediaone.net>]

Dmitri,

> 
> The BGP community is not a metric, it's an attribute -- quite
> different thing from the protocol design and operation standpoint.
> It's also a separate document from the specification standpoint.

Not true... communities are often used to convey BGP local preference
which last time I checked is a metric

Anyway, I don't think arguing this point is useful anymore... I
think there are too many people agree that there needs to be
one default metric and multiple "attributes" or metrics (depending
on what word you would like to use)


> It's also easy to name it if we take into consideration that
> the final goal is fastest response.

I don't think so... simple example: delay or throughput
 
> > Asking five people what the one metric should be
> > I got six answers.
> 
> We need rough consensus, don't we. If we had needed running
> consensus, we would've had very rough code. Remember ISO!

We have rough consensus... one default generic metric... IGP
protocols do not specify what the default metric MEANS -- why
do you think we should?


> 
> Imagine there are two peering CDNs: CDN-A and CDN-B. CDN-A
> uses a DNS based RRS; CDN-B uses a L7 based RRS. A client
> enters CDN-A and asks for a.b.c/d. Since CDN-B RRS is L7
> based, {a.b.c/d, surrogate ID set} was advertised from CPG-B
> to CPG-A via RPP. 

Your example mixes distribution and request routing and confuses
some of the subtle issues.

If a DNS based lookup is performed (the client is not inline
with a proxy or a L7 switch) then a handoff will occur to the
request routing system with surrogates closest to the user. If
a handoff isn't possible because the CDN does not have a DNS
based system then direct network information can be sent to 
other root systems to make a selection.

My personal belief is that most decisions will be based not
on URIs but on network proximity information anyway.

However, we need to support a corner case of advertisement to
L7 switches which will probably be used more in the intra
domain case (though we are not solving it).

> Since CDN-A RRS is DNS based only a.b.c is
> known to be served by CPG-A (! - the gateway to CDN-B) to the
> CDN-A RRS boxes. When the DNS request for a.b.c is received by CDN-A,
> proximity calculations between the CDN-A a.b.c surrogates and
> the client LDNS is triggered (assuming the simplest form
> of DNS based RRS is used), plus CPG-A send request to CPG-B
> to measure proximity between a.b.c (which is probably CPG-B
> surrogates having "all" the a.b.c content) and the client
> LDNS. Clearly, CDN-B cannot perform L7 based merriments at
> this point. 

Yes... again CDN-B is both distribution and request routing.. if
it is using L7 request routing then only a small set of clients
can will use its request routing system... the example is an
ISP with a L7 switch which only services its own customers.

> It can either perform some primitive proximity
> measurements and report the corresponding result ({surrogate ID,
> metric} pair) back to CPG-A or reply to CPG-A with the negative
> result. In the latter case, the default metric between CDN-A
> and CDN-B (most probably administratively configured) is used.
> CPG-A injects then the obtained results into the CDN-A RRS
> process and the routing decision is made.
> 
> The case when a client enters CDN-B is much simpler. Since
> CDN-A uses a DNS based RRS, {a.b.c, surrogate ID set} was
> advertised from CPG-A to CPG-B. When a.b.c/d HTTP request
> is received by a CDN-B redirector (assuming HTTP redirection
> is used), it may be up to CPG-B responsibility to come up with
> the CDN-A {a.b.c/d, surrogate ID subset} and to communicate the
> result with the redirector. The proximity calculations are
> performed then and the routing decision is made.
> 
> The bottom line is that two RRSs of different type can
> peer at least somehow. Could you please elaborate on how
> it's possible when the RRS type is exposed in RPP?

I'm confused... doesn't this conflict with what you've said
below [which i agree with]

> > 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.
> 
> See both above and below :)
> 
> >  >    In its current form, the corresponding
> >  >    part of the draft:
> >  >    - significantly complicated the protocol
> >  >      design
> >
> > Why?
> 
> Because internals of peering RRS (namely, the RRS type)
> is exposed in the protocol.

I don't know of any way around this... [but i will think
about it]

My sense is that if we took a vote right now, most people would
want to only advertise network proximity information and not
advertise URIs.  If this is true we can just create another
address family for MBGP and use it.

-brad