[rbridge] a stronger RPF check for TRILL

[Anoop Ghanwani]

The tree adjacency check already accounts for this.
http://tools.ietf.org/html/rfc6325#section-4.6.2.5

>>
   The Outer.MacSA is checked and the frame discarded if it is not a
   tree adjacency for the tree indicated by the egress RBridge nickname
   on the port where the frame was received.
>>

This is done in addition to the port-based RPF check.

Anoop

On Thu, Mar 8, 2012 at 9:43 AM, Santosh Rajagopalan
<sunny.rajagopalan at us.ibm.com> wrote:
> It appears the the multidestination frame checks present in TRILL may not be
> strong enough to cover some cases of packet duplicates during network
> transition scenarios. In this email, I'm going to suggest a modification of
> the TRILL RPF check to cover these cases.
>
> The root problem is that there's a notion of directionality built into the
> RPF concept ("accept packets from X along this vector"). In a p2p link,
> specifying the port alone uniquely qualifies that vector. However, in a
> multiaccess link, there are many "links/adjacencies" overlaid on the
> physical link. To identify one of them, you need to specify both the
> outer_smac *and* the port. So the RPF check should actually be "accept
> packets from X along (outer_smac, port)".
>
> Consider this network:
>
> F--A--B--C--o--D
> All the links except the link between C and D are p2p links. C and D are
> connected over a classical ethernet network (represented by the pseudonode
> "o"). Let's say D gets picked as the root for a multidestination tree (the
> choice of root is unimportant here).
> The resulting tree looks like:
>
> F--A--B--C--o--D
>
> Now lets say that a link comes up from A to the same classical ethernet
> network. So the network looks like this:
> ________
> | |
> F--A--B--C--o--D
>
> Let's say the resulting tree in steady state includes all links except the
> B-C link. After the network has converged, a packet that starts out from F
> will go F->A, where A will send one copy to the A-B link and another copy
> into the CE network, from where it will be received by C and D.
>
> However, lets consider a transition stage where A and D have acted on their
> LSPs and programmed their forwarding plane, while B and C have not yet done
> so.
> This means that B and C both consider the link between them to still be part
> of the tree.
>
> So a packet that starts out from F and reaches A will be copied by A into
> the A-B link and the A-o link. D's RPF check says to accept packets on this
> tree coming from F over its link to the CE network, so it gets accepted. D
> is also adjacent to A on the tree, so the tree adjacency check also passes.
>
> However, the packet that gets to B gets sent out by B to C. C's RPF check
> still has the old state, and it thinks the packet is ok. C sends the packet
> along the old tree, which is towards the CE network. D receives one more
> packet, but the tree adjacency check passes because C is adjacent to D in
> the new tree as well. The RPF check also passes because D's link to the CE
> network is ok for receiving packets from A.
>
> So now D gets duplicates of every packet until B and C act on their LSPs and
> program their hardware tables. The AF state is (I believe) irrelevant here
> because we're talking about TRILL encapsulated packets, not native CE
> frames.
>
> In the example above, the adjacency check alone doesn't help, because the
> rbridge D has adjacencies to both A & C on the tree. A check on (port, smac)
> will pass for packets from both A and C.
>
> The only check which can stop this from happening, I believe, is if you
> replace the current RPF check which looks like this:
> {tree_id, source_rbridge}->{allowed_port}
>
> with a modified check which looks like this:
>
> {tree_id, rbridge}->{allowed_port, allowed_outer_smac}
>
> This will make sure that packets will be accepted by D only if they were
> sent by A. This combined check can be a replacement for the currently
> separate adjacency and RPF checks.
>
> Thoughts?
> --
> Sunny Rajagopalan
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>