%% You should probably cite rfc7438 instead of this I-D.
@techreport{ietf-mpls-mldp-in-band-wildcard-encoding-00,
    number =    {draft-ietf-mpls-mldp-in-band-wildcard-encoding-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-wildcard-encoding/00/},
    author =    {IJsbrand Wijnands and Eric C. Rosen and Arkadiy Gulko and Uwe Joorde and Jeff Tantsura},
    title =     {{mLDP In-Band Signaling with Wildcards}},
    pagetotal = 14,
    year =      2014,
    month =     mar,
    day =       3,
    abstract =  {There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" to an MPLS multipoint label switched path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exists the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either "Source-Specific Multicast" trees or "Bidirectional multicast" trees) to be attached to an MPLS multipoint label switched path (MP-LSP), either in the context of a particular VPN or in a "global" (non-VPN) context. However, the previous documents do not specify procedures for attaching IP "Any Source Multicast" trees to MP-LSPs, nor do they specify procedures "aggregating" multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings making it possible to specify, when setting up an MP-LSP, that a set of IP multicast trees or a shared IP multicast tree should be attached to that MP-LSP.},
}