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

From: pfr at info.ucl.ac.be (Pierre Francois)
Date: Tue, 11 Jul 2006 15:19:13 +0200 (CEST)

Hi,

I have questions regarding "IS-IS like" link metrics that would be used in
trill.

Shouldn't the requirements specify that if zero configuration must be made
possible, it should also be made possible to configure RBridge->RBridge
link metrics in order to allow smarter than smallest hopcount path
forwarding...

In the zero configuration case, what would be the default metric ?

Also, what would be the behaviour of a RBridge if not all the links have a
configured metric ?

Consider all links have default metrics or configured links have their
configured metrics and the other the default ?

Wouldn't the last solution lead to a forwarding mess during a migration
from an unconfigured link metrics architecture to a configured one ? For
example if the default metric is 1, traffic will be concentrated on
unconfigured links during the transition as they will provide the shortest
paths...

If this solution is used, shouldn't the default metric be made
configurable in order to solve (at least try to solve) this problem ?

Also, if link metric config is possible, shouldn't there be a requirement
stating that a metric re-configuration should not lead to packet
loops/loss ?

Pierre.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Jul 2006 07:27:23 -0700

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.

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.

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.

Radia

Pierre Francois wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

---

From: riw at cisco.com (Russ White)
Date: Wed, 12 Jul 2006 07:19:08 -0400

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

> favor this, but I'd certainly prefer someone who has been working with 

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

> 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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 13 Jul 2006 19:25:11 +0200

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

---

From: pfr at info.ucl.ac.be (Pierre Francois)
Date: Thu, 13 Jul 2006 19:41:06 +0200 (CEST)

Guillermo,

This is a typical scenario where, imo, link metric configuration should
be made doable by the operator.

Pierre.

---

From: pfr at info.ucl.ac.be (Pierre Francois)
Date: Thu, 13 Jul 2006 19:57:08 +0200 (CEST)

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.

---

From: pfr at info.ucl.ac.be (Pierre Francois)
Date: Thu, 13 Jul 2006 20:29:36 +0200 (CEST)

Radia,

On Thu, 13 Jul 2006, Radia Perlman wrote:

> I don't think it's a problem to have two RBridges, R1, and R2, have
> different costs for
> the two directions of the R1-R2 link.

I agree it's not a problem, in general, to have asym. link metrics.
However, in our case here, we give a link A->B a default metric
for a 1Gbps link, although a "part a the link" is a 100Mbps one.

> I think what we're all agreeing on is that link costs should be tunable,
> but that there should be
> reasonable defaults.

Agreed, but if we say we refer to 802.1D defaults, we must remember that
it will not always match the link speed in TRILL, as illustrated
by Guillermo's case.

Pierre.

> Then the question is, should we specify the defaults for different types
> of links, and if so, in
> which document?
>
> One potential answer to "which document" is "not in TRILL", since we
> might be able to assume
> that any metrics used by IS-IS for layer 3 will work just fine for layer
> 2 TRILL.

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 13 Jul 2006 20:31:23 +0200

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.

---

From: pfr at info.ucl.ac.be (Pierre Francois)
Date: Thu, 13 Jul 2006 20:39:11 +0200 (CEST)

Guillermo,

As far as I understand, RBridges MUST work with zero-configuration. Now, I
don't see why we should make it non-tunable.

Pierre.