Re: [rbridge] a stronger RPF check for TRILL

[Donald Eastlake <[e-mail]>]

Hi,

I agree that use of the stronger, simpler RPFC should be optional.
Among other things, we certainly don't want to declare faithful
implementations of RFC 6325 non-conformant. Also, I think there are,
for reasonable implementation strategies, cases where there would be
more state information with the current standard RPFC requirement and
other cases where there would be more state information with the
simpler, stronger RPFC requirement. (The most important factor for
distinguishing between these cases is, as implied by the message
below, how many ports each RBridge has on the multi-access link.)

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Thu, Mar 15, 2012 at 7:19 PM, letracy <[e-mail]> wrote:
> 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