Re: [rbridge] a stronger RPF check for TRILL

[Radia Perlman <[e-mail]>]

Ah.  Yes, thank you for that explanation, Donald.  Santosh is indeed
correct, and it also makes the spec easier to read, which is an
additional plus.

Radia

On Fri, Mar 9, 2012 at 6:44 AM, Donald Eastlake <[e-mail]> wrote:
> 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

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