[rbridge] How to deal with RBridge-Rbridge link metrics ?
Guillermo Ibáñez
gibanez at it.uc3m.es
Fri Jul 14 10:14:30 PDT 2006
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
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