[rbridge] How to deal with RBridge-Rbridge link metrics ?

[Radia Perlman]

When we said "zero configuration" we weren't intending to preclude 
configuration for tuning. So perhaps we have
to change the wording in the documents. VLANs almost certainly require 
configuration, and there will always
be tuning.

Should we consider setting of link metrics, and what the defaults are, 
to be an implementation issue? I agree
with Pierre that it would be good, for instance, to choose defaults in 
the base TRILL document, so that all
implementations use the same logical defaults.

Should we pick a single default for link cost for all types of links? (I 
think not)
Should we pick a default value for each link type? (say, a link of this 
speed would have this default). I think I
favor this, but I'd certainly prefer someone who has been working with 
IS-IS recently decide.

The easiest thing would be to ignore this issue and claim that the IS-IS 
specification deals with it, but I think
it would be nice to suggest defaults.

Radia

Pierre Francois wrote:

>
>Hi,
>
>I have questions regarding "IS-IS like" link metrics that would be used in
>trill.
>
>Shouldn't the requirements specify that if zero configuration must be made
>possible, it should also be made possible to configure RBridge->RBridge
>link metrics in order to allow smarter than smallest hopcount path
>forwarding...
>
>In the zero configuration case, what would be the default metric ?
>
>Also, what would be the behaviour of a RBridge if not all the links have a
>configured metric ?
>
>Consider all links have default metrics or configured links have their
>configured metrics and the other the default ?
>
>Wouldn't the last solution lead to a forwarding mess during a migration
>from an unconfigured link metrics architecture to a configured one ? For
>example if the default metric is 1, traffic will be concentrated on
>unconfigured links during the transition as they will provide the shortest
>paths...
>
>If this solution is used, shouldn't the default metric be made
>configurable in order to solve (at least try to solve) this problem ?
>
>Also, if link metric config is possible, shouldn't there be a requirement
>stating that a metric re-configuration should not lead to packet
>loops/loss ?
>
>
>
>Pierre.
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>