**Session Date/Time:** 26 Jul 2024 00:00

# lsvr

## Summary

The LSVR working group met to discuss open issues on the BGP-SPF based document, aiming to finalize it for IESG submission.  Key discussion points included the stability of the environment, registry sharing with BGPLS, implementation status, route reflector behavior, unnumbered links, and the optionality of End-of-RIB (EOR). Decisions were made on how to address these points, and action items assigned to the document authors.

## Key Discussion Points

*   **Environment Stability:**  The group discussed the phrase "very stable environments" in the document. Concern was raised that it might limit applicability or require justification of when it's *not* appropriate.
*   **Registry Sharing (BGPLS vs. BGPSPF):** The group debated whether BGPSPF should have its own registry separate from BGPLS, given the re-use of attributes.  The concern was what happens when a new TLV shows up from BGPSPF into BGPLS.
*   **Implementation Status:**  The implementation section refers to a "dead draft."
*   **Route Reflector (RR) Mode:**  Discussion about clarifying RR behavior, specifically whether RRs reflect all received information or apply filtering policies.
*   **Unnumbered Links:**  Discussion on the "should" vs. "may" language regarding the inclusion of the link descriptor on unnumbered links and potential malformed consequences if omitted.
*   **End-of-RIB (EOR):** Discussion on management requirements surrounding EOR functionality.
*   **Security Considerations (DoS):** Briefly discussed but deemed no worse than existing BGP behavior.

## Decisions and Action Items

*   **Environment Stability:** The authors agreed to remove the line regarding "very stable environments."
*   **Registry Sharing:**
    *   Instead of splitting registries, authors will add text referencing the BGPLS specification stating that unknown TLVs are ignored.
    *   Check any new TLV across IDR and Routing Area.
*   **Implementation Status:** The authors will ensure the implementation draft is refreshed before IESG submission. Alternatively, move the implementation section into this document. Authors preferred to refresh existing implementation draft.
*   **Route Reflector (RR) Mode:** Authors will clarify in Section 4.3 that RRs reflect all received information without filtering policy. Add the policy consideration is not being addressed in this specification and rather it is for applicability.
*   **Security Considerations:** The security considerations are in applicability and the text will provide guidance on its existence.

## Next Steps

*   Authors to incorporate agreed-upon changes and post a revised version of the draft.
*   Adrian to review incorporated changes.
*   Close the working group last call and proceed with the next steps for IESG submission.