as-out metrics

Trying to wade through all the mails from Friday. Not around sorry -
this one definately catches my eye. DFK is correct here. 
What you have to be careful of with a general representation (which is
what this is) is not to map too much current directly into the syntax.
The  fact is the peer can interperate this metric (what metric by the
way ? MED, Local Pref, BGP passes two - just adding a little confusion
to  the clarity bag) as it wishes. The source has no control on it. It
is an idication of policy but an indication potentially only available in
some protocols and the granularity of intention is different per
protocol.
However, I do see that it may be useful to have "optional" indicative
protocol metrics if it helps to clearly descride what pllicy is being
set (this may need to map on a per peer basis in some cases so the
semantics of the attribute needs the association to peer as well). 
Again, tools may have a hard time with this but.....

	--Tony.

P.S. If this is all discussed later then apologies,
 
 Daniel Karrenberg <Daniel.Karrenberg at ripe.net> writes:
  * 
  *   > Laurent Joncheray <lpj at merit.edu> writes:
  *   > 
  *   > > Is its use defined by the protocol?
  *   > > My first impulse is to register this as
  *   > > bgp-metric: <metric> <as> ...
  *   > > since it is protocol specific and needs a specific value configured
  *   > > rhather than a relative cost.
  *   > > Is this acceptable?
  *   > 
  *   > 	Why changing everything? ALC handle this metric
  *   > correctly, i don't see any need to create another attribute.
  * 
  * Why? For clarity!
  * 
  * The cost in as-in is relative. The absolute numbers do not have any meaning
  * .
  * It defines a static preference independent of protocol.
  * 
  * The bgp-metric is something different, applicable only to BGP and its
  * use by the peer is not predicatble. So to my mind it should go somewhere
  * else. 
  * 
  * But I'll sleep over it.
  * 
  * Daniel



-------- Logged at  Mon May 2 14:26:46 MET DST 1994  ---------