Subject: [rbridge] Compromise proposal---allowing tradeoff between com putation and optimality of delivery

From: sanjays at cisco.com (Sanjay Sane (sanjays))
Date: Thu, 2 Nov 2006 09:42:49 -0800

inline with <sanjay>

3) Right. Choosing which n RBridges get to be roots based on MAC
addresses is arbitrary. I just wanted a simple tie breaker so all the
RBridges compute the same trees. For DR election there's a priority
field that is used as the most significant byte of the address. We could
do the same thing here. Rather than a flag saying "I want to be a root",
there can be, say, a 1 byte TLV in the link state packet saying "my
priority for being a tree root is x". If the TLV is not there at all
then it means "I don't want to be a root at all, unless there are no
other volunteers and I happen to be the lowest MAC address". Otherwise,
the n RBridges with the highest ( root priority | MAC ) get chosen.

<sanjay> And is this "n" derived from the lowest n seen from the "I can
support n trees" message from rbridge TLVs. ?

So, the TLV inside rbridge LSP could contain 2 things 
1 -- "my priority for being a tree root is x". 
2 -- "I can support n trees"

If both of these are absent, we could choose 1 tree, and the rbridge
with lowest MAC address is the root of that single tree.

-Sanjay

----- Original Message -----
From: "Gray, Eric" <Eric.Gray at marconi.com>
Date: Wednesday, November 1, 2006 11:51 am
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between
com putation and optimality of delivery

> Radia,
> 
> 	There are three problems with this proposal: 1) the general
problem 
> associated with having options, 2) the fact that it is not consistent 
> with the idea of trying to utilize links more fully if the approach 
> may require traffic to traverse the same links more than one time, and

> 3) there is nothing about a low MAC address that has anything to do 
> with the suitability of a particular RBridge to act as the root for a 
> shared tree.
> 
> 	I think there are other ways to allow for an optional server for

> broadcast/multicast/flooding distribution than to complicate the TRILL

> protocol with optional implementation alternatives like this proposal 
> seems to suggest.  Part of the complication - at a minimum - is the 
> need to provide for a neogitation mechanism with one or more tunable 
> parameters for determing a primary, and one or more secondary, roots 
> for the shared tree.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: rbridge-bounces at postel.org
> --> [rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> --> Sent: Wednesday, November 01, 2006 1:43 PM
> --> To: rbridge at postel.org
> --> Subject: [rbridge] Compromise proposal---allowing tradeoff between

> --> computation and optimality of delivery
> --> 
> --> There is understandable nervousness about the need to compute 
> --> per-ingress trees for every RBridge, and optimality of delivery.
> --> I actually was dubious about whether people *really* wanted to 
> --> have to compute per-ingress trees.
> --> 
> --> Here's a proposal that will allow tradeoff between overhead of 
> --> computation and optimality of delivery. If people really want they

> --> can have RBridges compute trees rooted at every RBridge. Or they 
> --> can have all multicast delivered on a single shared tree.
> --> Or anything in
> --> between.
> --> I'm arbitrarily picking the zero configuration option being a 
> --> single tree.
> --> 
> --> The new shim format allows the ingress RBridge to specify the 
> --> distribution tree for multicast, by putting into the "egress 
> --> RBridge"
> --> field a tree rooted at at the specified RBridge.
> --> 
> --> In this proposal, by default, the only tree that will be computed 
> --> is a single shared tree rooted at the RBridge with smallest MAC 
> --> address. Let's say
> that--> RBridge has nickname "71". By specifying 71 as egress
> RBridge in
> --> a multicast packet, the delivery path will be via the
> bidirectional--> tree rooted at 71.
> --> 
> --> An RBridge can be configured to demand that it, too, be the
> root of
> --> a tree, and it informs the other RBridges with a flag in its link 
> --> state packet.
> --> 
> --> So now we have a subset of RBridges that can be used as roots of 
> --> trees, because they have specified that in their link state 
> --> packet.
> --> Let's say that RBridges with nicknames 11, 15, 71, 222, and 259
> all--> have announced that they want to be roots of trees.
> --> 
> --> Then an ingress RBridge, say R2, with nickname 11, can send a
> --> multicast/unknown destination packet with "ingress"=11 (its own)
> --> and "egress"=11 (because it said it wanted to be a root). 
> --> Or it could
> --> choose any of the other potential ones (15, 71, 222, 259).
> --> 
> --> Likewise, an ingress RBridge, say R3, with nickname 13, who has
> --> not requested to be the root of a tree, can specify only
> --> the trees 11, 15, 71, 222, 259. Note it cannot specify 
> --> "13", since we
> --> are assuming it has not requested that all RBridges 
> --> calculate a tree 
> --> rooted at itself.
> --> 
> --> If no RBridges are configured to say they want to be the root,
> --> then only a single tree will get computed---the one rooted
> --> at 71.
> --> 
> --> So the zero configuration option is a single shared tree 
> --> (still filtered
> --> based on IP multicast announcements and VLANs) rooted at 
> --> the RBridge with
> --> smallest MAC address. But by configuration, more and more 
> optimality--> can be introduced by having RBridges compute more trees.
> --> 
> --> Radia
> --> 
> --> _______________________________________________
> --> 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: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 02 Nov 2006 11:20:04 -0800

Warning---half-baked idea at the end of this message (my own---see "***")

>with lowest MAC address is the root of that single tree.
Right. I'm a bit nervous about some random RBridge that can only support 
one tree, or that just
leaves the TLV out, from going up and down. We have to make sure it's 
not unstable.

Suppose the nickname of the RBridge with highest priority for being root 
is 24.
Suppose ingress RBridge R1 doesn't notice that wimpy RBridge R5 (that 
can only support one tree)
has joined the net, and R1 selects "79" as the tree .

I guess we should say that if you see a specified tree that shouldn't be 
legal, you drop the packet, right?

***An alternative is to continue forwarding it along the 79-tree and 
hey, if R5 is on the path, it will
drop the packet and only nodes downstream from R5 will suffer. We could 
even do complicated things
like say that you can calculate trees beyond R5's capabilities by 
considering links out of R5 to be
infinity. That way a wimpy RBridge can be a leaf, and going up and down 
won't affect existing trees.

Radia

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 4 Nov 2006 17:09:47 -0500

I really can't see why the minimum should be one. In an network where
Rbridge trees make any difference you have at least two Rbridges so I
can't see why you wouldn't, at a minimum, have two trees. I think we
should just prohibit Rbridges that claim to be able to support only one
tree.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Thursday, November 02, 2006 2:20 PM
To: Sanjay Sane (sanjays)
Cc: rbridge at postel.org
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between
com putation and optimality of delivery

Warning---half-baked idea at the end of this message (my own---see
"***")

Right. I'm a bit nervous about some random RBridge that can only support
one tree, or that just leaves the TLV out, from going up and down. We
have to make sure it's not unstable.

Suppose the nickname of the RBridge with highest priority for being root
is 24.
Suppose ingress RBridge R1 doesn't notice that wimpy RBridge R5 (that
can only support one tree) has joined the net, and R1 selects "79" as
the tree .

***An alternative is to continue forwarding it along the 79-tree and
hey, if R5 is on the path, it will drop the packet and only nodes
downstream from R5 will suffer. We could even do complicated things like
say that you can calculate trees beyond R5's capabilities by considering
links out of R5 to be infinity. That way a wimpy RBridge can be a leaf,
and going up and down won't affect existing trees.

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sat, 04 Nov 2006 14:23:07 -0800

Actually, I think it would work to have all RBridges calculate
just a single bidirectional multicast tree (pruned according to VLANs 
and IP multicast downstream of
each port in the tree). Even if it was a fairly large
campus, if a negligible percentage of traffic was multicast/unknown 
destinations, this
wouldn't even be that suboptimal. Unicast would still go via optimal 
paths. But multicast would just
go according to the one tree.

Not that I'm advocating a single tree---it's just that I don't think it 
would be incorrect.

Radia