Re: consistent policy != consistent announcements
Randy Bush wrote:
A normal condition of peering between consenting adults is that the peers have consistent policy across all points where they peer.
[example of a quasi-consistent scenario skipped]
Am I being unfair to my peers? Would they be justified in making a stronger requirement than 'consistent' policy? What requirement would be reasonable?
There are three quasi-answers: 1) it's ok with consent of parties involved (i.e. you may want to coordinate fancy policies with peers) 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? 3) on a phylosophical level, all involved parties should have a way to control destiny of routes, to a some extent. Right now, it's either control local to the destination (local preferences), or control by adjacent neighbour (MEDs). There's no way to extend it further (save for as-replication kludgery) or to combine local and remote metrics in any meaningful way. --vadim
Vadim Antonov wrote:
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?
On this point does anyone have any experience of using the cisco DPA implementation between providers ? --Tony
>> A normal condition of peering between consenting adults is that the peers >> have consistent policy across all points where they peer. > [example of a quasi-consistent scenario skipped] > 1) it's ok with consent of parties involved (i.e. you may want to coordinate > fancy policies with peers) In this particular case, a peer is complaining about a simple policy. Is there an other policy that would make them happy. Can I hope that it is not complex, hardier to maintain, or have undesirable side effects? Is the peer justified in asking me to implement different policy and what other policies? > 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? I thought that there was some plan to experiment with this, but have seen nothing recently. Perhaps the BGP artists have become otherwise occupied. [ what will changing the length of the ASN do to the community format? ] > 3) on a philosophical level, all involved parties should have a way to > control destiny of routes, to a some extent. Right now, it's either > control local to the destination (local preferences), or control by > adjacent neighbour (MEDs). There's no way to extend it further (save for > as-replication kludgery) or to combine local and remote metrics in any > meaningful way. I agree that this is worth exploring. But it is a philosophical problem and protocol design issue, thus perhaps better suited to other fora. I am just an unsmooth operator trying to understand how to be a good citizen and how far I may have to bend to be one. The reason I posted to NANOG is that I have a real today problem with an actual unhappy peer. And I am trying to understand if there is something reasonable I can do to make them happy. The inconsistencies described may also cause problems for real world routing analysis tools. So all good points. And I agree with you philosophically. But please bail me out today. randy
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
participants (4)
-
randy＠psg.com -
Tony Barber -
Tony Li -
Vadim Antonov