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

Sat Jul 15 00:36:49 PDT 2006

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

Pierre Francois wrote:
> 
> Guillermo,
> On Fri, 14 Jul 2006, Guillermo Ibáñez wrote:
> 
> 
>>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.
> 
> 
> 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.
> 
> 
>>Guillermo
>>
>>Gray, Eric wrote:
>>
>>>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
>>>-->
>>>
> 