Markdown Version | Transcript | Session Recording | Session Materials
Session Date/Time: 19 Mar 2026 03:30
LSVR
Summary
The LSVR (Link State Vector Routing) Working Group met at IETF 125 in Shenzhen. The session focused on the status of the BGP-LS YANG model, the strategic direction for Link Layer Discovery (specifically choosing between L3DL and L3ND), and extensions for BGP-LS-SPF to support SRv6 and policy state synchronization. Key administrative items included addressing outstanding errata on RFC 9015 and the need for a response to an IEEE liaison.
Key Discussion Points
WG Status and Administration
- Errata: Two errata (one technical, one editorial) have been filed against RFC 9015. Acee Lindem and Keyur Patel committed to reviewing and verifying these.
- Liaison: A liaison from the IEEE has been pending for a year. The chairs noted a response is required and will be informed by the decision on the L3DL/L3ND direction.
- Draft Status: draft-ietf-lsvr-bgp-ls-yang has been updated to version 03.
1. A YANG Model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF
Arvind Babu presented updates to draft-ietf-lsvr-bgp-ls-yang.
- Technical Updates: The model has shifted from a TLV-centric representation to an NLRI-expanded structure to better handle variable-length, nested, and unknown TLVs. Known attributes now use explicit YANG types, while unknown ones are preserved as binary blobs for extensibility.
- Discussion: Mahesh Jethanandani clarified that work on the BGP base model is parallel and not a blocking dependency for the BGP-LS parts. Ketan Talaulikar cautioned against BGP-LS becoming a "moving train" and suggested limiting the base model scope to RFC 9552, using augmentations for future extensions. The authors agreed to keep the base model focused.
2. L3DL & L3ND / L3DL and L3ND Straw man Direction
Keyur Patel, Acee Lindem, and Rob Shakir discussed the path forward for link discovery.
- Protocol Choice: The authors strongly recommended pursuing L3ND over L3DL. Rob Shakir noted that L3ND is significantly simpler as it uses standard TCP/TLS rather than a custom transport layer over raw Ethernet.
- Implementation Interest: Rob Shakir questioned the current industry requirement for this work, noting author fatigue. David Lamparter indicated that L3ND would be much easier to implement in FRRouting than L2-based alternatives.
- Consensus Path: The Chairs will use the mailing list to determine if there is sufficient interest to proceed with L3ND as a replacement for the expired L3DL work.
3. Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF
Li Zhang presented updates on this individual draft.
- Technical Updates: Added a new section on SRv6 SIDs and reachability, clarifying how locators and SIDs should be installed in the RIB/forwarding plane based on algorithm support and reachability checks.
- Discussion: Ketan Talaulikar expressed that the document is stable and urged the working group to move to an adoption poll.
4. BGP-LS-SPF Extensions for SRv6 Policy State Synchronization
Wen Chenyang presented a proposal for a new sub-TLV to indicate if an SRv6 SID is active in a policy.
- Discussion: Acee Lindem questioned how non-head-end nodes would accurately know the active state of a SID in a policy. Li Zhang raised concerns regarding potential congestion if traffic steering decisions are made based on this state. Jie Dong requested the authors further clarify the specific use cases and benefits for path computation at the ingress node.
Decisions and Action Items
- Action: Acee Lindem and Keyur Patel to verify/respond to errata on RFC 9015.
- Action: Chairs to initiate a discussion on the mailing list to choose between L3DL and L3ND.
- Action: Chairs to initiate a response to the IEEE liaison following the L3DL/L3ND decision.
Next Steps
- Call for adoption poll for the "Applying BGP-LS SRv6 Extensions to BGP-LS-SPF" draft on the mailing list.
- Authors of the BGP-LS-SPF Policy State draft to address comments regarding use cases and visibility on the mailing list.
- Authors of draft-ietf-lsvr-bgp-ls-yang to continue aligning with IGP topology support in RFC 9552.