[rbridge] FW: (slight) modification of how to choose mulitcast trees

[Anoop Ghanwani]

(Resent message.)

This looks like a reasonable approach.  I have 
the following comments to add:

- Do we want to restrict traffic from certain
  VLANs to certain trees?  If so, then the Rbridge
  that decides the number of trees would also decide
  the mapping of VLAN to tree.  I would actually
  prefer this option, but I'd like to hear opinions
  on this.

- Do we care about path congruency -- i.e. when
  a MAC DA is unknown and it is sent over a multicast
  tree, and later it becomes known, do we want
  the unicast path to be along the branch of the
  multicast tree?  This would be essential for 
  maintaining ordering.  My personal opinion is
  that this becomes an implementation choice, but
  in the presence of multipathing it is not possible
  given the current RBridge specification (because
  it would require the computation of more than
  one tree, one each that included each ECMP path
  to the destination).

Anoop 

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Friday, March 28, 2008 7:55 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] (slight) modification of how to choose 
> mulitcast trees
> 
> Dinesh suggested the following, as a way of making 
> configuration easier for how to choose multicast trees.
> 
> 1) Each RBridge is configured with a priority for being 
> selected a multicast tree root (with of course a default 
> being a medium priority)
> 
> 2) Each RBridge R1 s also configured with a parameter 
> indicating "total number of trees in the campus", which R1 
> announces in its LSP
> 
> 3) RBridges are ranked by (priority, ID). The RBridge with 
> the numerically lowest priority, and then numerically lowest 
> ID being the tie breaker, dictates the total number of trees 
> all the other RBridges must calculate (the number that R1 
> announces in its LSP according to rule 2 above.
> 
> 4) An RBridge calculates n distribution trees, where n is the 
> number announced by the lowest (priority, ID) RBridge R1, in 
> R1's LSP, as the "total number of trees". The n trees 
> computed are the ones using the n numerically lowest 
> (priority, ID) RBridges as roots
> 
> 5) if RB1 is ingress RBridge on port p, and (*note another parameter
> "k"*) is configured to do k-way path splitting on that port 
> for multidestination frames, the k tree roots that RB1 
> chooses consist of the three for which the triple "(cost of 
> root to me, priority, ID)" are the k smallest.
> 
> Intuition: suppose there is a topology with a lot of "leaf" 
> RBridges., and "next level" RBridges that the leaf RBridges 
> connect to.
> If there are m leaf RBridges connected to next level RBridge 
> RBx, then there is no reason to compute trees with any of the 
> leaf RBridges as root -- the tree rooted at RBx will be the 
> same tree, and will indeed be a shortest path tree for each 
> of the attached leaf RBridges. If a leaf RBridge is attached 
> to several next-level RBridges, the most significant number 
> in the triple -- "cost of root to me" will cause the leaf 
> RBridge to multipath the multicast among multiple shortest-path trees.
> 
> This seems completely safe, and easier than configuring, for 
> each RBridge, the set of root RBridges to choose for 
> multicast tree roots.
> It also means that you can configure in one place a total 
> number of roots, rather than possibly having too many 
> RBridges volunteer for being tree roots, and winding up with 
> too much overhead on RBridges because they'll have to compute 
> a tree for every RBridge that says it will want to be a tree root.
> 
> There might be a concern about volatility -- when an RBridge 
> with numerically low priority goes down, it might cause:
> a) a change to the total number of trees to be computed by 
> everyone (since the next best might be configured with a 
> different number)
> b) a change to the list of "tree roots I will choose" 
> announced by RB2 when one of the roots for the k best (cost 
> to me, priority, ID) goes down.
> 
> Other than that, I can't think of any possible problems.
> 
> Radia
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>