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

[Ketan Talaulikar <[e-mail]>]

Hi Linda/All,

There was a discussion during the LSVR WG meeting at IETF 118 about
rechartering and there the feedback was that we perhaps look to just update
for the L3DL work.

That said, please continue to provide inputs on any specific update and
work that the WG members would like to consider updating in the charter.

Please also feel free to propose text changes/updates if there are terms
used that need further clarification.

Thanks,
Ketan


On Fri, Dec 15, 2023 at 10:39 PM Linda Dunbar <[e-mail]>
wrote:

> Gunter, et al,
>
> You said that  " The L3DL documents went (long ago) through WGLC and are
> have been ready to be published since long".
>
> Then, why need to go through the effort of rechartering just to include
> the include the L3DL technology into lsvr charter?
> Do you mean that the rechartered LSVR is just to move the already WGLC
> documents to IESG approval? What is the chartered work within LSVR?
>
> Thanks, Linda
>
>
>
>
> -----Original Message-----
> From: Shihang(Vincent) <[e-mail]>
> Sent: Monday, December 11, 2023 7:07 AM
> To: Gunter van de Velde (Nokia) <gunter.van_de_velde=
> [e-mail]>; Linda Dunbar <[e-mail]>
> Cc: [e-mail]
> Subject: RE: [Lsvr] Initiating LSVR re-chartering discussion - draft#1
> proposal
>
> Gunter, et al. ,
>
> Thanks for the re-chartering discussion. Another use case of the BGP SPF
> is to collect the **overlay** link state and calculate the best **overlay**
> path when BGP is already used, such as SDWAN. It is a simple application of
> existing BGP-SPF and a small step towards more innovative use-cases. The
> LSVR rechartering should consider it.
>
> Thanks,
> Hang
>
> -----Original Message-----
> From: Lsvr <[e-mail]> On Behalf Of Gunter van de Velde
> (Nokia)
> Sent: Thursday, December 7, 2023 5:41 PM
> To: Linda Dunbar <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Lsvr] Initiating LSVR re-chartering discussion - draft#1
> proposal
>
> [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
>