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

[Gray, Eric]

Guillermo,

	Just to be clear, having a manual configuration capability
does not prevent "zero-configuration" as long as a well understood
default exists (either a set of specific values, or something that
can be derived).

--
Eric 

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