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

[Ketan Talaulikar <[e-mail]>]

Hi Greg,

Please start a separate email thread to share your comments on the L3DL
document. The document is currently in a WG document state.

Thanks,
Ketan


On Tue, Dec 19, 2023 at 1:54 AM Greg Mirsky <[e-mail]> wrote:

> 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
>>
> _______________________________________________
> Lsvr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsvr
>