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

[Pierre Francois]

Guillermo,

As far as I understand, RBridges MUST work with zero-configuration. Now, I
don't see why we should make it non-tunable.

Pierre.

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

> It seems that choosing worst case metric would be the logical decision.
> Manual configuration is against zero configuration objectives stated on
> RBridge origins.
> Universal metric regardless bandwidth seems irrational having 10**n
> bandwidth range with Ethernet.
>
> Pierre Francois wrote:
>
> >Guillermo,
> >
> >Thinking top of my head there, but, in your particular case, where there
> >is only one bridge in the middle, you could rely on what follows :
> >
> >RBridgeA has a link metric of x,
> >RBridgeB has a link metric of y < x.
> >
> >All the RBridges detect an asymetrical link metric, consider the largest,
> >x, as the metric for RbridgeA->RBridgeB and RbridgeB->RBridgeA so that
> >no one will consider that the link A->B is a 1Gbps link.
> >
> >Once you have two bridges in the middle, I don't see how
> >to make the metric be accurate without a manual configuration...
> >
> >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
> >>
> >>
> >>
>