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

[Greg Mirsky <[e-mail]>]

Hi Ketan,
thank you for considering my proposal. I think that the state of art in
dynamic routing has historical explanations rather than the result of
design. To the best of my understanding, none of routing protocols can use
its hello process to guarantee sub-second failure detection and use BFD for
that purpose. If BGP-SPF requires sub-second failure detection, then, in my
opinion, introducing a mechanism that would not support that seems like a
strange design choice. For that reason, I suggest using the well-known and
proven mechanism for sub-second network failure detection, BFD.

Regards,
Greg

On Wed, Jan 24, 2024 at 10:32 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Greg,
>
> Routing protocols have their own keepalive/hello based liveness detection
> mechanism and use BFD for "faster detection". The same is being followed
> here.
>
> If you look at the BGP-SPF peering model in
> https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf-29#section-4.2,
> then the BGP session is established between the loopbacks that is monitored
> by BGP keepalive. There is the requirement for monitoring the liveness over
> the underlying links between the neighboring routers.
>
> I hope that clarifies.
>
> Thanks,
> Ketan
>
>
> On Thu, Jan 25, 2024 at 2:42 AM Greg Mirsky <[e-mail]> wrote:
>
>> Hi Gunter,
>> thank you for sharing the proposed updated charter. I have one question
>> about the scope of the Layer-3 Discovery and Liveness work. The proposed
>> charter states the following:
>>
>> 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.
>>
>> From experience with routing protocols, fast convergence is essential to
>> operators. BFD demonstrated its ability to provide sub-second detection of
>> network failure at scale. Considering that, would it be reasonable to
>> center on BFD as only fast defect detection method and reword the sentence
>> as follows:
>>
>> The mechanism should also support the monitoring of reachability of
>> neighboring routers over links based on the use of existing mechanisms such
>> as BFD for faster liveness monitoring.
>>
>> Regards,
>> Greg
>>
>> On Wed, Jan 24, 2024 at 8: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
>>>
>> _______________________________________________
>> Lsvr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsvr
>>
>