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

[Gray, Eric]

It does not appear to me that there is disagreement here.

Yes, we should use Ethernet default link costs.  
Yes, we should allow configuration of link costs.

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Pierre Francois
--> Sent: Thursday, July 13, 2006 1:41 PM
--> To: Guillermo Ibáñez
--> Cc: rbridge at postel.org; Radia Perlman
--> Subject: Re: [rbridge] How to deal with RBridge-Rbridge 
--> link metrics ?
--> 
--> 
--> 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
--> >
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->