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

[Guillermo Ibáñez]

I did not follow the whole discussion. I apologize in advance.
A suggestion and a doubt.
For link metrics I would suggest to refer to 802.1D default link costs 
for bridges. (20.000.000/Link speed in Mbps), but what happens if 
between two RBridges A and B there is standard bridge and the link to 
one RBridge is 100 Mbps and the link to the other is 1 Gbps?
Guillermo

Russ White wrote:
> -----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-----
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>