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
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