%% You should probably cite draft-ietf-l2vpn-vpls-bridge-interop instead of this I-D.
@techreport{sajassi-l2vpn-vpls-bridge-interop-03,
    number =    {draft-sajassi-l2vpn-vpls-bridge-interop-03},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-sajassi-l2vpn-vpls-bridge-interop/03/},
    author =    {Ali Sajassi},
    title =     {{VPLS Interoperability with CE Bridges}},
    pagetotal = 19,
    year =      2006,
    month =     jul,
    day =       13,
    abstract =  {One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer bridges. If only connectivity among customer IP routers/hosts was desired, then IPLS solution {[}IPLS{]} could have been used. The strength of the VPLS solution is that it can provide connectivity to both bridge and non-bridge types of CE devices. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks today or the same level of service that they receive from their Ethernet Service Providers using IEEE 802.1ad-based networks {[}P802.1ad{]} (or its predecessor \textendash{} QinQ-based network). When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. Majority of these issues have currently been addressed in IEEE 802.1ad standard for provider bridges and they need to be addressed for VPLS networks. This draft discusses these issues and wherever possible, the recommended solutions to these issues.},
}