%% You should probably cite rfc7746 instead of this I-D.
@techreport{ietf-mpls-self-ping-05,
    number =    {draft-ietf-mpls-self-ping-05},
    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-self-ping/05/},
    author =    {Ron Bonica and Ina Minei and Michael Conn and Dante Pacella and Luis Tomotaki},
    title =     {{LSP Self-Ping}},
    pagetotal = 12,
    year =      2015,
    month =     oct,
    day =       2,
    abstract =  {When certain RSVP-TE optimizations are implemented, ingress LSRs can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through an LSP as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes. LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures. LSP Self-ping is an extremely light-weight mechanism. It does not consume control plane resources on transit or egress LSRs.},
}