Re: [rbridge] a stronger RPF check for TRILL

[Donald Eastlake <[e-mail]>]

Hi Anoop,

On Fri, Mar 9, 2012 at 7:51 AM, Anoop Ghanwani <[e-mail]> wrote:
> 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.

Ahhh, but this is not quite a strong as what Santosh is suggesting.
The subtle weakness is that "adjacency" has no directionality.

RFC 6325 currently specifies this part of the RPFC as two separate checks:
 1. Is ( tree, Outer.MacSA, arrival port) an allowed triplet according
to the current topology and tree?
 2. Is ( tree, ingress, arrival port ) an allowed triplet according to
the current topology and tree?

What Santosh is suggesting, which would be just a little stronger and
arguably simpler, is equivalent to replacing this with one test:
 -- Is ( tree, Outer.MacSA, ingress, arrival port ) an allowed quadruplet?

This is stronger because, on a multi-access link, one Outer.MacSA may
only be allowed on frames from the ingress and other Outer.MacSA may
only only be allowed on frames ingressed elsewhere.

I think some existing silicon may already use this combined RPFC test...

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

> Anoop
>
> On Thu, Mar 8, 2012 at 9:43 AM, Santosh Rajagopalan
> <[e-mail]> 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
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

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