VMWare, Inc.

Bangalore KA 562125 India pushpasis.ietf@gmail.com

Arrcus, Inc.

keyur@arrcus.com

Individual Contributor

santosh.pallagatti@gmail.com

Arista Networks

sajibasil@gmail.com

Network Working Group BGP Shortest Path Routing This document is an implementation report for the BGP Link-State Shortest Path First (SPF) Routing. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

describes an alternative solution which leverages BGP-LS and the Shortest Path First algorithm similar to Internal Gateway Protocols (IGPs) such as OSPF . The solution introduces an new BGP-LS-SPF AFI-SAFI and replaces the Phase 1 and 2 decision functions of the Decision Process specifed by with the Shortest Path First (SPF) algorithm also known as the Dijkstra algorithm. This solution avails the benefits of both BGP and SPF-based IGPs that include TCP based flow-control, no periodic link-state refresh, and completely incremental NLRI advertisements. These advantages can reduce the overhead in MSDCs where there is a high degree of Equal Cost Multi- Path (ECMPs) and the topology is very stable. Additionally, using an SPF-based computation can support fast convergence and the computation of Loop-Free Alternatives (LFAs) in the event of link failures. This document provides an implementation report of the Shortest Path Routing extensions to BGP protocol as specified in . The authors did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab.

Contact and implementation information for person filling out this form:

ArcOS Name: Pushpasis Sarkar Email: pushpasis@arrcus.com Vendor: Arrcus, Inc. Release: ArcOS Protocol Role: Route Reflector and Client FRR Name: Basil Saji Email: sajibasil@gmail.com Vendor: FRR Release: Protocol Role: Route Reflector Name: Santosh P K Email: santosh.pallagatti@gmail.com Vendor: FRR Release: Protocol Role: Route Reflector

Does the implementation support the following BGP-LS-SPF Peering Models as specified in Section 2 of ? 2.1 -- BGP Single-Hop Peering on Network Node Connections 2.2 -- BGP Peering Between Directly Connected Network Nodes 2.3 -- BGP Peering in Route-Reflector or Controller Topology Reelease 2.1 2.2 2.3 ArcOS Yes Yes Yes (Route Reflector only) FRR Yes Yes Yes

Does the implementation support the following BGP-LS-SPF TLVs as described in Section 4 and sub-sections of ?? T1 -- Node NLRI Attribute SPF Capability TLV T2 -- Node/Link/Prefix NLRI Attribute SPF Status TLV T3 -- Link NLRI Attribute IPv4 Prefix-Length TLV T4 -- Link NLRI Attribute IPv6 Prefix-Length TLV T5 -- Attribute Sequence-Number TLV Release Send / Recv T1 T2 T3 T4 T5 ArcOS Send Yes Yes Yes Yes Yes Recv Yes Yes Yes Yes Yes FRR Send Yes Yes Yes Yes Yes Recv Yes Yes Yes Yes Yes

Does the implementation support the following Best Path Decision processes as described in Section 5 and sub-sections of ? P1 -- Phase-1 BGP NLRI Selection P2 -- Dual Stack Support P3 -- SPF Calculation based on BGP-LS NLRI Release P1 P2 P3 ArcOS Yes Yes Yes TBA --- --- ---

TBA

N/A. - No protocol changes are proposed in this document.

This document does not introduce any change in any of the protocol specifications.