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

Pierre Francois pfr at info.ucl.ac.be
Fri Jul 14 14:04:18 PDT 2006 


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

More information about the rbridge mailing list