Re: [rbridge] a stronger RPF check for TRILL

[letracy <[e-mail]>]

Hi Sunny,

I wanted to try and clarify my point a little better:

>From W¹s perspective nothing has changed except the addition of the SMAC.
RFC6325 does not mandate that it accept traffic from both links, so it can
have a single RPF check if it wishes.

In the example below, A and X do not know which port on the LAN link W will
send a particular frame on.  The RFC explicitly states that W is free to
loadsplit flows among its ports on the link and requires that A and X be
able to accept traffic from either of W¹s links (See RFC6325 Section 4.4.4).
This means that A and X (all Rbridges which share the LAN link with W) will
be required to have 1 RPF check per port W has on the link for W and for
each Rbridge behind W in the tree.

In the below example that means A must have the following RPF checks for its
interface connected to the LAN link:
(U,interface, SMAC_W1)
(U,interface, SMAC_W2)
(V,interface, SMAC_W1)
(V,interface, SMAC_W2)
(W,interface, SMAC_W1)
(W,interface, SMAC_W2)
(X,interface, SMAC_X)
(Y,interface, SMAC_X)
(Z,interface, SMAC_X)

Thanks,
Leonard



On 3/15/12 2:54 PM, "Sam Aldrin" <[e-mail]> wrote:

> Having read both sides of the story, two points I hear are
> 1. There is a scenario or corner case, where existing rpf check doesn't
> satisfy the needs.
> 2. Because the new proposal requires SMAC to be maintained, the size of tables
> exponentially increases.
> 
> IMO, weight given to 1and 2 could vary depending on vendor and whom you talk
> to. If stronger rpf check is needed, a solution without increasing the
> complexity in table size etc should be proposed. If that is something not
> going to be achieved, it should be left optional, till something is
> identified.
> 
> My 2 cents
> Sam
> 
> Sent from my iPhone
> 
> On Mar 15, 2012, at 2:28 PM, Santosh Rajagopalan
> <[e-mail]> wrote:
> 
>> I think that a similar argument can be made for the current RPF check as well
>> - it costs us table space and helps us in rare, transient cases. If you
>> decide that the RPF check is worthwhile having in its current form, I think
>> you can make the case that it's worthwhile having in the expanded form as
>> well. 
>> 
>> Because really, the new form of the RPF check says the same thing as the
>> current form - it's just that in multi-access links you need to qualify the
>> "allowed link" a little more strongly. Also, I'm not sure if its absence
>> could lead to loops - duplicates were just the first case I thought of.
>> 
>> Note that in the case you illustrated below (where rbridges have multiple
>> links to the CE network) you would need to have multiple RPF entries anyway,
>> even without the new expanded check. For example, the rbridge W would need
>> "allow (A, link_1)" in addition to "allow (A, link_2)". Of course, there's no
>> denying that adding the mac address there will bring in additional memory
>> costs. 

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge