WG Action: Rechartered Link State Vector Routing (lsvr)

[The IESG <[e-mail]>]

The Link State Vector Routing (lsvr) WG in the Routing Area of the IETF has
been rechartered. For additional information, please contact the Area
Directors or the WG Chairs.

Link State Vector Routing (lsvr)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Ketan Talaulikar <[e-mail]>
  Jie Dong <[e-mail]>

Assigned Area Director:
  Jim Guichard <[e-mail]>

Routing Area Directors:
  John Scudder <[e-mail]>
  Jim Guichard <[e-mail]>
  Gunter Van de Velde <[e-mail]>

Mailing list:
  Address: [e-mail]
  To subscribe: https://www.ietf.org/mailman/listinfo/lsvr
  Archive: https://mailarchive.ietf.org/arch/browse/lsvr/

Group page: https://datatracker.ietf.org/group/lsvr/

Charter: https://datatracker.ietf.org/doc/charter-ietf-lsvr/

Data Centers have been steadily growing and commonly host tens of thousands
of end points, or more, in a single network. Because of their topologies
(traditional and emerging), traffic patterns, need for fast restoration, and
for low human intervention, data center networks have a unique set of
requirements that is resulting in the design of routing solutions specific to
them.

The Link-State Vector Routing (LSVR) Working Group is chartered to develop
and document a hybrid routing protocol utilizing a combination of link-state
and path-vector routing mechanisms along with mechanisms for the discovery
and liveness monitoring of links to neighboring routers. The LSVR WG will
utilize existing IPv4/IPv6 transport, packet formats and error handling of
BGP-4 consistent with BGP-LS NLRI encoding mechanisms (RFC9552) to facilitate
Link-State Vector (LSV) routing information distribution. An LSV is intended
to be specified as a data structure comprised of link attributes, neighbor
information, and other potential attributes that can be utilized to make
routing decisions.

The LSVR specification is initially focused on operation within a single
datacenter (DC) as a single distribution domain, which is defined as a set of
participating nodes in a single administrative domain. Routing protocol
functionality defined by LSVR, called BGP-SPF, would be typically routing
within a datacenter's underlay routing plane. The work will include
coexistence considerations with BGP IPv4/IPv6 unicast address families
installing and advertising routes into the same RIB. The WG may consider
protocol extensions for deployments beyond a single domain DC focus after
completion of the base protocol specification.

The WG will consider the effects (if any) of deploying the BGP-SPF protocol
while concurrently using the same transport session as other existing BGP
address families. These considerations will be documented as part of the main
protocol specification. A mechanism to be able to independently deploy
BGP-SPF from other address families may be defined (as needed).

The BGP-SPF protocol is intended as a self-standing routing protocol even if
using existing BGP transport mechanisms and encodings, or if sharing the same
transport session with other existing BGP address families. Similar as
existing routing protocols, the BGP-SPF protocol will not internally combine
the route selection mechanisms or share routing information, except through
common external interaction methods in the RIB.

In order to achieve the noted objective, the working group will focus on
standardization of BGP-SPF protocol functionality, defining Link-State
Vectors (LSVs) and defining standard path-vector route selection utilizing
the Dijkstra SPF based algorithm, BGP-4 protocol mechanics and BGP-LS NRLI
encoding.

The WG will also develop protocol mechanisms for the Layer-3 discovery of
neighboring routers running BGP-SPF for various BGP peering models thereby
providing the ability to discover the properties of adjacent BGP-SPF routers
for advertisement as LSVs. Such mechanisms must support the discovery of the
link and node attributes such as Autonomous System numbers, IP addresses,
encapsulation support, and other information as may be necessary for the
BGP-SPF protocol and network operations. The mechanism should also support
the monitoring of reachability of neighboring routers over links as well as
leverage the use of existing mechanisms such as BFD for faster liveness
monitoring.

The working group will provide specifications to manage routing information
from other unicast routing protocols or BGP address families to common
prefixes.

The LSVR WG is chartered to deliver the following documents:

  *   Specification document describing LSV with standard Dijkstra SPF
  route/path selection (calculation) utilizing existing BGP protocol baseline
  functionality and BGP-LS packet encoding formats. *   Specification
  documenting protocol extensions required to efficiently reuse BGP to
  distribute LSVs within an IPv4/IPv6 DC with scope to include privacy and
  security considerations.
     *   The impact of these extensions to the security properties of BGP
     will be studied and documented. *   New attack vectors will be explored
     and documented. *   Mitigations to any new attack vectors identified
     will be discussed and documented.
  *   Specification documenting a Layer-3 discovery and liveness monitoring
  protocol for supporting BGP-SPF operations.
     *   A base protocol documenting discovery and liveness for neighboring
     Layer-3 BGP-SPF routers. *   Protocol extensions for discovery and
     exchange of information required by an upper-layer or client protocol
     such as BGP-SPF. *   Security, authentication, and confidentiality
     aspects of the protocol and the information exchanged. *   Configuration
     and management of the protocol extensions.
  *   Applicability Statement for the use of LSVR in the Datacenter.
  *   YANG model specification for LSVR management.

The WG will closely collaborate with the IDR WG.  Any modifications or
extension to BGP that will not be specifically constrained to be used by LSVR
must be carried out in the IDR WG but may be done in this WG after agreement
with all the relevant chairs and the responsible Area Directors.

Milestones:

  Sep 2024 - LSV distribution using BGP transport

  Sep 2024 - LSVR with standard Dijkstra path selection

  Oct 2024 - Applicability statement for LSVR in DCs

  Mar 2025 - YANG specification for LSVR

  Jul 2025 - Layer-3 Discovery and Liveness Protocol Specification

  Dec 2025 - YANG specification for Layer-3 discovery and liveness monitoring
  protocol