Re: [rbridge] a stronger RPF check for TRILL

[Jon Hudson <[e-mail]>]

I agree! Both stronger & easier to read/understand. 

Very nice Santosh!

On Mar 9, 2012, at 7:57 AM, Radia Perlman <[e-mail]> wrote:

> 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

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