[BGP Metrics] Tony Li wrote:

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.

Agreed, though i was coming to it from the diffrent angle -- out of the sense of general disgust about having several different metrics, every one being rather limited. I.e. the idea was to introduce a simple generic mechanism including all existing metrics as particluar cases.

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.

There's a clear statement that the default value of a single AS hop is 1.0. Since there's no central administration, there's no way to coordinate the scale of metrics globally (i.e. what constitutes 1/2 of a default hop?) -- so the weights are provided to give other parties ability to compensate the variations in the interpretation. The reason for carrying a vector is to make possible establishing local policies on values originated from remote side, and to allow operators to do things like having closer metrics to have higher costs (i.e. the more remote as-path component is, the less important its metric is).

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.

Then it does not take space in the path attributers. I.e. if you have a box implementing proposed metrics, and use only old-style paths, you end up with identical updates and identical results of their comparison. If old boxes implement transitive attributes properly, their effect would simply be setting static metric 1.0 for a hop.

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?

Exactly the same happens when you have different MEDs or different communities. Since the proposal obsoletes MEDs and LOCAL_PREFs (and makes the practice of ASN replication unnecessary) the overall overhead is likely to be close to zero (providing that same policies are implemented). --vadim