[Lsvr] WG Review: Link State Vector Routing (lsvr)

[The IESG <[e-mail]>]

A new IETF WG has been proposed in the Routing Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list ([e-mail]) by 2018-02-19.

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

Chairs:
  Gunter Van de Velde <[e-mail]>
  Victor Kuarsingh <[e-mail]>

Assigned Area Director:
  Alvaro Retana <[e-mail]>

Routing Area Directors:
  Alia Atlas <[e-mail]>
  Alvaro Retana <[e-mail]>
  Deborah Brungard <[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 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).

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

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:

  Mar 2019 - LSVR with standard Dijkstra path selection

  Mar 2019 - LSV distribution using BGP transport

  Mar 2019 - Applicability statement for LSVR in DCs

  Jul 2019 - YANG specification for LSVR