Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 07 Mar 2007 18:17:50 -0800

It isn't totally obvious how to do RPF (reverse path forwarding) checks 
to make multicast forwarding safer, when we're doing bidirectional trees 
(ingress is R1, but R1 chooses tree root R2).

So after thinking about it, I think this is how it would work, and it
introduces a new field that would be nice to add to the core instance 
IS-IS LSP. The field is "I promise to only choose the following set of 
RBridges to be tree roots". The only reasons for R1 to choose a 
distribution tree rooted on an RBridge other than itself are:

a) R1 is configured not to ask to be a tree root (so that RBridges don't 
have to calculate as many trees)

b) R1 wants to multipath multicast originating on its attached links.

The reason for having R1 preannounce is to simplify creating an RPF 
database associated with each tree.

If tree R1 is used if and only if R1 is the ingress for the data, then 
the RPF tree for tree R1 would look like this, at some RBridge R in the 
core:

for each "adjacency" (neighbor/port): one of the following: not in tree, 
in-port, or out-port. The RPF check would discard any incoming data for 
tree R1 except on the in-port.

However, if R1 chooses R2 as the root of the multicast tree, then the 
RPF database associated with the tree R2, at some core RBridge R looks 
like this:

Let S be the set of RBridges that have announced, in their LSPs, that 
they might choose R2 as the tree for multicast traffic they are sourcing 
into the campus.

R keeps, for tree R2, and for each adjacency, {set of RBridges that are 
plausible ingress RBridges for packets received on that adjacency}.

The set union of all of those will be S.

I hope that's correct, and that I've explained it clearly....

Radia

---

From: sanjays at cisco.com (Sanjay Sane (sanjays))
Date: Wed, 7 Mar 2007 23:19:23 -0800

What every rbridge wants to do is -- 
for every rbridge Rx that could use tree R1, 
On this tree R1, find which is the interface that leads me towards Rx,
or leads Rx towards me.
Multicast packets ingressed from Rx, and using tree R1, should be
allowed to come in only on this interface. 

The RPF state per interface could potentially be 
#ofswitches * #oftrees

By announcing this field, are you just trying to reduce the RPF state ? 

btw, should we use the term "RPF" to denote what's being checked here?
What we're really checking is whether the ingress rbridge is really
forwarding as per a given R1 tree. 

-Sanjay

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Wednesday, March 07, 2007 6:18 PM
To: rbridge at postel.org
Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees

Radia

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