Re: [Lsvr] Final draft LSVR re-charter text - final disagreements before end-of-business day 30 Jan 2024

[Gyan Mishra <[e-mail]>]

I reviewed the proposed Charter and it looks good.

Thank you


<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*



On Wed, Jan 24, 2024 at 11:40 AM Gunter van de Velde (Nokia)
<gunter.van_de_velde=[e-mail]> wrote:

> Hi LSVR WG,
>
> This note is provide an update on the eminent LSVR re-chartering. Together
> with our AD it was agreed to keep the changes minimal and focus upon
> formally including the Layer-3 Discovery and Liveness deliverable and a
> revised Milestone agenda, without expanding any other LSVR scope. In
> addition we also added more explicit reference to bgp-spf. Please find
> below the finally proposed revised LSVR charter. If no strong opposition,
> before End-of-Business day 30 January we’ll move forward and formally
> propose the below charter to our AD.
>
>  Be well and kind Regards,
>
> Gunter & Ketan
>
> =========== Final draft LSVR Charter ===========
>
> 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 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 <https://datatracker.ietf.org/doc/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 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 LSVR routers
> for advertisement as LSVs. Such mechanisms must support the discovery of
> the link and node attributes such as AS numbers, IP addresses,
> encapsulation support, and other information as may be necessary for the
> LSVR 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:
>
> Date
> Milestone
> Associated documents
>
> Mar 2024            LSV distribution using BGP transport
>
> Mar 2024            LSVR with standard Dijkstra path selection
>
> Jul 2024               Applicability statement for LSVR in DCs
>
> Jul 2024               Layer-3 Discovery and Liveness Protocol
> Specification
>
> Dec 2024             YANG specification for LSVR
>
> Dec 2024             YANG specification for Layer-3 discovery and liveness
> monitoring protocol
>
>
> _______________________________________________
> Lsvr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsvr
>