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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 14 Jul 2006 10:12:22 -0400

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
-->

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 14 Jul 2006 19:14:30 +0200

I agree. It was only the asymmetry in costs issue that I exposed but it 
is acceptable provided the worst case cost is applied at both RBridges.
But it seems that the default link costs can not be applied to links 
directly but need previous crosscheck with the path cost received from 
neighbour RBridges (those separated by only  std bridges)and apply the 
maximum (?) of them. It can be seen like some kind of agreement phase 
between neighbours on costs to be applied prior to running the 
algorithm. Link failures may introduce transients due to the reagreement 
of costs.
Guillermo

---

From: pfr at info.ucl.ac.be (Pierre Francois)
Date: Fri, 14 Jul 2006 23:04:18 +0200 (CEST)

Guillermo,

> algorithm. Link failures may introduce transients due to the reagreement

If you apply a two-way connectivity check "? la" IS-IS, you will not have
a transient issue, as a link A--B will only be useable if A advertises
A->B and B advertises B->A, with their respective metrics. So that, when a
link is being considered for SPT computation by an RBridge in the campus,
it knows the metrics for both directions, and can pick the largest one.

Pierre.

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 15 Jul 2006 09:36:49 +0200

OK. So the "anomaly" cases may happen only with links between standard 
neighbour bridges with small bandwidth, cost is not visible to RBridges, 
as in RB=b-b=RB.
Guillermo