[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distribution CPG Protocol





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