Re: Distribution CPG Protocol

["Hilarie Orman" <HORMAN@novell.com>]

I'm having trouble following this discussion, but maybe I'm
missing something ...

1. Is the proposal to have generic metrics have meaning only
between two admins?  This means that if two admins agree
that "5" is "bandwidth", then one may have agreed with
admins of other CDN's that "5" is "latency in milliseconds"
and with another that "5" is "hops".  ??  Is this really manageable?

2. If the metrics really are only bilateral, then there's some
trust implied, and in that case, one wouldn't expect the
advertisements to be used as part of an antagonistic
campaign.  If you need to encode "not applicable" to
get around this, it's fine, but trying to obscure the
meaning of the metrics seems futile.

Hilarie

>>> brad cain <bcain@mediaone.net> 01/12/01 01:42PM >>>


Phil Rzewski wrote:

> As usual, I'd like to bore everyone with BGP folklore [ :) ]. This problem
> was solved in the BGP universe with Communities. Each route may be
> optionally tagged with a list of Communities (up to 16, I think?) each of
> which is just a number that only has significance to the people on that
> peering session (the side that defined it & the side that interprets it). I
> don't wanna be accused of always trying to turn this work into BGP, but I
> have a fetish for things that have reached implementation.
> 
> Indeed, once you've just got a list of numbers, there's really not even a
> need to name them "Bandwidth", "Disk space available"... you've just got a
> list of "Genric Metrics". We certainly CAN think of some metrics that are
> likely to have some use (such as "Bandwidth"), but if we build them into
> the protocol, we'll just be taking up extra space in the event those
> specific metrics aren't used somewhere. Since we can't possible think of
> EVERY metric someone might want to define, we'll need to have a place for
> Generic Metrics anyway. Why not make them all Generic?
> 
> (That being said, it would be silly to just do exactly the same thing as
> Communities, as Communities are just single 32-bit values. They're nice for
> tagging things like "this route came from Acme" or "you should attach a low
> preference to this route", but NOT good for tagging things like "the
> temperature is 62 degrees at the place where this route came from". As a
> result, since we want to indicate things like "Bandwidth=128", I imagine
> that each Generic Metric in the list would look like Metric1=valueA,
> Metric2=valueB, etc. Should all values be only numeric? Hmm. Myself, I'm ok
> with numeric.)

Agree with Phil here... I posted this a couple of days back as
a quick suggestion:

>> It seems as if all three of these cases need a protocol
>> which does a quick handshake and then exchanges:
>>         URI #1, Attribute #1, Attribute #2
>>         URI #2, Attribute #1, Attribute #3
>>         etc
>> 

Where each URI is tagged with multiple attributes that mean different
things between providers (ala bgp communities).  I also think that
having a simple metric to prevent looping that is well known is
reasonable... 


> I think this is an important distinction. Once again, I think this makes a
> case for a Generic Metric. One of the things I was previously stuck on with
> regard to capacity advertisements was an implication (assumed on my part)
> that these advertisements might have some universally-accepted meaning.
> :)  In other words, if we imposed a "space available" metric, and every CDN
> actually had to catalog their available space and advertise it, I think a
> lot of them would not want to participate because they'd never wanna send
> the message of "there's no room at the inn". Fear is that they'd end up on
> the cover of CDN Illustrated with the headline "Foobar CDN is out of space!" :)

Yes... even IGP routing protocols use generic metrics which can be set
any way an admin desires... external metrics are harder because they
are between two separate parties..

-brad