[rbridge] Pseudo-node nickname

[Erik Nordmark]

On 7/26/11 7:42 AM, Donald Eastlake wrote:

> I'm not sure what the problem is. R2 can't tell the difference between
> R1 dying and the link dying. If R2 is higher nickname priority than
> R1, R2 keeps the nickname if it creates a pseudonode. I don't think
> there is any reason to generate a pseudonode if you think you are the
> only RBridge on a link. If R2 lower nickname priority, it get a new
> nickname. (Nickname priority is unrelated to DRB priority.)

Let me try explaining what I see as a potential issue.
If R2 is lower nickname priority, then to handle a partition R2 needs to 
pick a new pseudo-node nickname when there is a link partition. If R2 
can't tell the difference between a link partition and R1 failing, then 
R2 will need to create a new pseudo-node nickname even when R1 fails.

*If* that is the case, then there are no significant benefits of 
pseudo-node nicknames; upon an RBridge failure nickname to use to reach 
some endnodes will change.
Hence my question is how can R2 reliably tell whether R1 failed, and the 
link between R1 and R2 failed but R1 is still alive.

> When there are two copies of the same nickname being advertised in the
> topology, frames with that value as egress nickname are sent to the
> one that is least cost away.

Sure; that isn't the potential issue above.

>> Does this mean that the RPF check needs to be able to verify whether a
>> multidestination frame came from pseudo-node (the previous hop was the
>> pseudo-node) as opposed to from a particular RBridge attached to the
>> pseudo-node? (One can't tell from the frame since there isn't a outer
>> MAC SA for the pseudo-node, so I hope that isn't necessary.)
>
> The RPF check is only based on input port, ingress nickname, and tree
> (i.e., egress nickname). [Check 2 in Section 4.5.2 of RFC 6325]
>
> There is a separate check of the Outer.MacSA on Ethernet links that
> the frame came from a tree adjacency. [Check 1 in Section 4.5.2 of RFC
> 6325] While that section of the RFC is not crystal clear on this
> point, it only makes sense when applied to physical RBridge
> adjacencies.

OK, so that description would need to be tweaked if the tree includes 
pseudo-nodes; presumably any outer.macsa from two hops earlier in the 
tree should be OK if one hop earlier is a pseudo-node.

    Erik