Re: [rbridge] a stronger RPF check for TRILL

[letracy <[e-mail]>]

I think one drawback to the stronger RPF check is that Rbridges will be
required to maintain more state.  In the best cases, Rbridges will be
required to maintain a 6 byte source MAC address per RPF.  In some other
cases, the stronger check will require additional RPF checks as well.

Consider a case such as:

             A - B - C
             |
 U - V - W = o - X - Y - Z

Where o is a LAN link and W has two parallel links into the LAN o with
unique MAC addresses on each link.
 
In this case, W is allowed to loadsplit among the two links and Rbridges
A and X are required by RFC6325 to accept traffic coming from either of
W's ports.  This will mean bridges X and A are required to maintain two
RPF entries each for Rbridges U, V and W (One RPF check accepting (W, SMAC1)
and one accepting (W, SMAC2), etc...).  Thus, the number of RPF checks
required in the network becomes proportional to the number of Rbridge ports
connected to LAN links as well as to the number of Rbridges in the network.
In larger networks this could explode in terms of scale and complexity.

Considering that the problem case is transient, rare, and only results in
duplicate packets (as opposed to loops) - I'd like to suggest that the
stronger check be made optional.
 
Thanks,
Leonard Tracy


On 3/9/12 1:55 PM, "Jon Hudson" <[e-mail]> wrote:

> 
> 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

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