Re: [rbridge] a stronger RPF check for TRILL

[Santosh Rajagopalan <[e-mail]>]

I think that a similar argument can be made for the current RPF check as 
well - it costs us table space and helps us in rare, transient cases. If 
you decide that the RPF check is worthwhile having in its current form, I 
think you can make the case that it's worthwhile having in the expanded 
form as well. 

Because really, the new form of the RPF check says the same thing as the 
current form - it's just that in multi-access links you need to qualify 
the "allowed link" a little more strongly. Also, I'm not sure if its 
absence could lead to loops - duplicates were just the first case I 
thought of. 

Note that in the case you illustrated below (where rbridges have multiple 
links to the CE network) you would need to have multiple RPF entries 
anyway, even without the new expanded check. For example, the rbridge W 
would need "allow (A, link_1)" in addition to "allow (A, link_2)". Of 
course, there's no denying that adding the mac address there will bring in 
additional memory costs.

--
Sunny Rajagopalan




From:   letracy <[e-mail]>
To:     Jon Hudson <[e-mail]>, Radia Perlman 
<[e-mail]>, Santosh Rajagopalan/Santa Clara/IBM@IBMUS
Cc:     Donald Eastlake <[e-mail]>, "[e-mail]" 
<[e-mail]>, Anoop Ghanwani <[e-mail]>
Date:   03/14/2012 09:37 PM
Subject:        Re: [rbridge] a stronger RPF check for TRILL
Sent by:        [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

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