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

[Russ White]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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

The first question we actually need to answer is--wide metrics or
narrow? Since IS-IS has two metric types, if we do "zero configuration,"
we need to worry about the type of metric chosen in the default state.
IMHO, it would be better to specify wide metrics only.

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

I would say that if we want to go this route, some type of "x/bandwidth"
would work, but, we must be careful on two fronts:

- -- We don't really want to specify x, unless we specify it so close to
infinity that we'll never hit a link with greater than x available
bandwidth. There have been many points in the past when we've chosen
what we think x should be, and we're always wrong, in a sense. In fact,
it's hard to know what x should be, since it's not really derived from
the maximum link bandwidth in the network, but it's rather a balance of
the min and max link bandwidths available.

- -- We want to make certain that there is a way to change x in the
network without undue downtime (none would be preferred).

The first problem is something we, the trill community, need to address.
Perhaps we could specify a default metric of "x/bandwidth," with
operators able to set what they want (tune), and operators also setting
x, and the assumption that vendors may choose x for their products. The
second problem is outside the scope of TRILL, so we can ignore it, for now.

Or, another option is, as Radia says, simply make up a list. The problem
here is that no matter how you cut it, you're essentially doing some
form of x/bandwidth anyway, and you always run into some problems
figuring out what x should be. (Remember, as well, that x may not be a
single value, it may be a formula containing the bandwidth, as well).

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

It doesn't, really--in IS-IS today, you must tune if you want tuning,
the default metric is set such that we don't fall over the maximum with
narrow metrics in fairly large networks. I don't think that's really a
"good idea" for TRILL, if we can avoid it, since we want this to be
configuration less, if possible (?).

:-)

Russ


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEtNqsER27sUhU9OQRAkAHAKDC2ud3T7cooyQK7YMpEKd91ZuPyACaA9rR
FhZQutTJj+LMyAB6rrSw0L8=
=kl90
-----END PGP SIGNATURE-----