Re: consistent policy != consistent announcements

[garyz () savvis com (Gary Zimmerman)]

I agree.  the BGP path is a blunt instrument.  BGP is in need of real
metrics.  I really want to fine tune but find it hard with current
abilities of BGP.  I would also like to use the bits within the TCP/IP
header to help determine class of services which is there but no one uses
or seems to care about.  

We could offer some really good services to the internet if we could get
this fine-grained control.  But, when you get down to it, most companies
are having a hard time with this from a resource and the overhead cost on
routers.  I think the big companies (cisco) are holding us back.  We need
routing to take place more on a switch fabric, hardware/card based, vrs
software based routing. Routers like the Ascend (NetStar) are a step in the
right direction.  This will help take care of the third issue.  

Gary Zimmerman
V.P. of Network Engineering
Savvis Communications

"I don't wear the uniform to play,  I wear it to win!"  Larry Byrd

----------
> From: Tony Li <tli () jnx com>
> To: Vadim Antonov <avg () pluris com>
> Cc: nanog () merit edu
> Subject: Re: consistent policy != consistent announcements
> Date: Sunday, March 16, 1997 10:58 PM
>
>
>    2) generally speaking, BGP path length is too blunt an instrument. 
More
>    fine-grained control is needed to allow peers to fine-tune balance of
>    their interests.  I'm sorry to be too naive, but i'm repeating that
for
>    years and nobody seems to agree that BGP needs real metrics.  How
come? 
> Well, for several reasons.
>
> First, any such proposal should have a reasonable architecture.  Not just
a
> description of the mechanism.  Motivational explanations are most
welcome,
> preferably sprinkled with real world examples.
>
> Second, there's the issue of the consistency of the values used.  As I
> recall your proposal, each domain in the path would propose a metric for
> its contribution for a prefix.  A receiving domain then weighted each
> domain in whichever way it chose to arrive at a final, composite metric.
> Thus, the semantics of the metric are hardly clear.
>
> Third, there's the pragmatic issue of implementation cost.  Yes, the cost
> of an integer per AS in an AS path is tolerable, tho not "cheap".  This
> cost becomes painful if most domains are not using the metric.  And it
> becomes more painful if two prefixes with otherwise identical attributes
> have different metrics.  This results in them not landing in the same
> update, thereby increasing overhead.  Are we willing to take a signficant
> step forward in overhead for this flexibility?  
>
> Tony
- - - - - - - - - - - - - - - - -