%% You should probably cite rfc9494 instead of this I-D.
@techreport{ietf-idr-long-lived-gr-06,
    number =    {draft-ietf-idr-long-lived-gr-06},
    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-idr-long-lived-gr/06/},
    author =    {Jim Uttaro and Enke Chen and Bruno Decraene and John Scudder},
    title =     {{Long-Lived Graceful Restart for BGP}},
    pagetotal = 20,
    year =      2023,
    month =     jul,
    day =       12,
    abstract =  {This document introduces a BGP capability called the "Long-Lived Graceful Restart Capability" (or "LLGR Capability"). The benefit of this capability is that stale routes can be retained for a longer time upon session failure than is provided for by BGP Graceful Restart (as described in RFC 4724). A well-known BGP community called "LLGR\_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community called "NO\_LLGR" is introduced for marking routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least preferred and that their advertisements be limited to BGP speakers that have advertised the capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is. This memo updates RFC 6368 by specifying that the LLGR\_STALE community must be propagated into, or out of, the path attributes exchanged between the Provider Edge (PE) and Customer Edge (CE) routers.},
}