Link State Vector Routing
charter-ietf-lsvr-01

Document Charter Link State Vector Routing WG (lsvr)
Title Link State Vector Routing
Last updated 2018-02-23
State Approved
WG State Active
IESG Responsible AD Alvaro Retana
Charter Edit AD Alvaro Retana
Send notices to aretana.ietf@gmail.com

Charter
charter-ietf-lsvr-01

Data Centers have been steadily growing to 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.  The LSVR WG will utilize existing IPv4/IPv6
transport, packet formats and error handling of BGP-4 consistent with BGP-LS
NLRI encoding mechanisms (RFC7752) 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 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 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 will consider the effects (if any) of deploying the LSVR 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 LSVR from other
address families may be defined (as needed).

The LSVR 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 LSVR 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 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 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

 - 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.