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

[Ketan Talaulikar <[e-mail]>]

Hi Greg,

You will see that the charter text does cover use of BFD for fast
detection. However, BFD does not perform discovery or "base" liveness (also
known as adjacency/neighborship) management for its client protocols.

QUOTE
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*.
UNQOUTE

Thanks,
Ketan


On Thu, Jan 25, 2024 at 10:27 PM Greg Mirsky <[e-mail]> wrote:

> 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
>>>
>>