Re: [Lsvr] Initiating LSVR re-chartering discussion - draft#1 proposal

[Greg Mirsky <[e-mail]>]

Hi, Gunter and the authors of L3DL,
you've noted that L3DL has already advanced past the WG LC. I clearly
missed that discussion. I read the document, and I have several OAM-related
questions. I would appreciate your suggestions on what could be the
appropriate way to discuss them, considering the state of the draft.

Regards,
Greg

On Thu, Dec 7, 2023 at 1:41 AM Gunter van de Velde (Nokia)
<gunter.van_de_velde=[e-mail]> wrote:

> [co-chair hat on]
>
> Hi Linda,
>
> Thanks for sharing these thoughts.
> The current low hanging fruit focus for ongoing re-charter exercise is to
> include the L3DL technology into lsvr charter.
> The L3DL documents went (long ago) through WGLC and are have been ready to
> be published since long.
>
> Once both BGP-SPF and L3DL documents are published, there is a preliminary
> idea floating around for a second re-charter exercise (in approx. 12
> months), intended to tune the charter of LSVR WG to new innovative
> use-cases and enhancements associated with BGP-SPF Link State Vector
> Routing. The question if we should morph LSVR into a generic superscale BGP
> based dc routing WG is a big step away from current lsvr charter. At first
> glance the BGP WG may be an reasonable fit for such focus also. It is an
> item to consider in the grander scheme for LSVR futures during the
> re-charter exercise once BGP-SPF and L3DL are published.
>
> G/
>
>
> -----Original Message-----
> From: Linda Dunbar <[e-mail]>
> Sent: Thursday, December 7, 2023 2:22 AM
> To: Gunter van de Velde (Nokia) <[e-mail]>
> Cc: [e-mail]
> Subject: RE: [Lsvr] Initiating LSVR re-chartering discussion - draft#1
> proposal
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext for additional
> information.
>
>
>
> Gunter, et al. ,
>
> Thanks for initiating the re-chartering discussion.
>
> With many large-scale  data centers using only Path Vector based routing,
> as described in RFC7938 (Use of BGP for Routing in Large-Scale Data
> Centers), and the trend towards congestion control in hyperscale DC for ML
> training models, the LSVR rechartering should consider addressing those
> issues.
> For example, the new LSVR WG can explore potential mechanisms to enable
> data centers with only path vector-based routing (e.g., BGP) for superscale
> computing..
>
> Cheers,
> Linda
>
> -----Original Message-----
> [Lsvr] Initiating LSVR re-chartering discussion - draft#1 proposal "Gunter
> van de Velde (Nokia)" <[e-mail]> Tue, 05 December
> 2023 10:49 UTCShow header
>
> Hi LSVR WG,
>
> We would like to initiate the convergence towards a first LSVR charter
> update.
> During IETF LSVR118 WG session there was consensus we should initially
> embrace the L3DL work, and consider additional enhancements in a later
> follow-up charter update
>
> Look for the embedded L3DL text <new>text</new> .
>
> Thoughts, suggestions and constructive feedback on the draft#1 charter
> proposal is appreciated.
> If necessary we could setup an interim to discuss detailed nuances.
>
>
> **********DRAFT#1**********
>
> Charter for Working Group
>
> 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 <new> and the Layer-3
> Discovery and Liveness (L3DL) protocol to discover IP Layer-3 attributes of
> links, such as neighbor IP addressing, logical link IP encapsulation
> abilities, and link liveness </new>.
> The LSVR WG will utilize existing IPv4/IPv6 transport, packet formats and
> error handling of BGP-4 consistent with BGP-LS NLRI encoding mechanisms (
> 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 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.
>
> <new>The L3DL protocol is developed to discover link IP Layer-3 attributes
> and is focused upon discovering mutually supported layer-3 encapsulations
> for IP and/or MPLS interface addressing. The discovery protocol must
> present this data to BGP-SPF so that topology and routing tables can be
> build. L3DL should provide support for authenticity verification of
> protocol messages and provide a mechanism for Layer-2 keep-alive messaging
> to support session continuity, and finally support build-up for Layer-3
> link liveness such as BFD.</new>
>
> 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
>         o The impact of these extensions to the security properties of BGP
> will be studied and documented
>         o New attack vectors will be explored and documented
>         o Mitigations to any new attack vectors identified will be
> discussed and documented <new> . Specification documenting L3DL  protocol
> considering usage with BGP-SPF
>         o A base protocol documenting Layer-3 Discovery and Liveness
> protocol
>         o Protocol extensions documenting Layer-3 Discovery and Liveness
> Signing
>         o Protocol extension to communicate the parameters needed to
> exchange inter-device
>         Upper Layer Protocol Configuration for upper-layer protocols such
> as the BGP family L3DL
>         Upper-Layer Protocol Configuration </new> . Applicability
> Statement for the use of LSVR in the Datacenter . YANG model specification
> for LSVR management . YANG model specification for L3DL 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.
>
> (revision proposal) Milestones:
> . Mar 2024      Applicability statement for LSVR in DCs
> . Mar 2024      LSV distribution using BGP transport
> . Mar 2024      LSVR with standard Dijkstra path selection
> . Dec 2024      YANG specification for LSVR
> . <new>Jul 2024        Layer-3 Discovery and Liveness
> . Jul 2024        Layer-3 Discovery and Liveness Signing
> . Jul 2024        L3DL Upper-Layer Protocol Configuration
> . Dec 2024      YANG specification for L3DL</new>
>
> -----Original Message-----
>
>
> _______________________________________________
> Lsvr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsvr
>