|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: consistent policy != consistent announcements
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 <[email protected]> > To: Vadim Antonov <[email protected]> > Cc: [email protected] > 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 - - - - - - - - - - - - - - - - -
|