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

[Pierre Francois]

Guillermo,

This is a typical scenario where, imo, link metric configuration should
be made doable by the operator.

Pierre.

On Thu, 13 Jul 2006, Guillermo Ibáñez wrote:

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