%% You should probably cite draft-ietf-trill-pseudonode-nickname instead of this I-D.
@techreport{hu-trill-pseudonode-nickname-04,
    number =    {draft-hu-trill-pseudonode-nickname-04},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-hu-trill-pseudonode-nickname/04/},
    author =    {Hongjun Zhai and Tissa Senevirathne and Radia Perlman and Donald E. Eastlake 3rd and Mingui Zhang and fangwei hu},
    title =     {{RBridge: Pseudo-Nickname}},
    pagetotal = 21,
    year =      2012,
    month =     dec,
    day =       12,
    abstract =  {RBridges provide frame forwarding service to layer2 switches or end stations at the edge of TRILL campus. As defined in {[}RFC6325{]}, when there are multiple RBridges attached to the same LAN segment, only one edge RBridge is allowed to be the frame forwarder of a specific VLAN in order to avoid potential frame duplication and loops in the TRILL campus. However, in some application scenarios, for example an end station is multi-homed to multiple RBridges needs to improve the resiliency and increase the available network bandwidth of the connection. This means all those RBriges attached to the end station can act as the frame forwarders of a specific VLAN. This kind of active-active connection violates the definition above. Frame duplication and forwarding loops may happen and it may cause the flip-flopping of the egress RBridge nickname associated to the MAC address of such an end station in remote RBridges' forwarding tables. The Reverse Path Forwarding Check does not work as well, which has been addressed in {[}CMT{]}. This document proposes the concept of Virtual RBridge, along with the pseudo-nickname configuration for this Virtual RBridge, to address the above problems in accompany with {[}CMT{]}.},
}