1. Proposed title of this feature request
Virtual Fabric for enabling Host-based Routing

2. What is the nature and description of the request?
This outline identifies the technical requirements for what the product needs beyond what is already available:

FRR / routing stack control plane

• Red Hat Support.
• EVPN Type 2 and Type 5 to SRv6.
• IS-IS (Intermediate System to Intermediate System) for underlay networks, BGP for overlay connectivity.
• Resilience of forwarding in the event of FRR crash/restart: datapath non stop forwarding.

Dataplane

• SRv6 L3VPN (End.DT46) & EVPN (End.DT2 Encap & Decap).
• Packet tracing tools with filtering as packet rate will capture all traffic.
• High capacity multi-NIC hosts [ability to move traffic without saturating PCI bus (Nx100 Yx400G)].
• Ability to visualize network path (POD to NIC edge) [command line is acceptable, dashboard would be nice to have eventually].
• PE router CPU footprint expected to be between 2 and 8 CPUs for 25Gbps (35Mpps, zero packet drop).
• PCI utilization visibility.

OpenShift

• Image-based installation and networking reconfiguration: IS-IS peering is mandatory at install time.
• Appliance builder multi node clusters and per-node configuration files.
• With Virtual Control Plane clusters: PE runs on the hypervisor, not in the VM
        1. Possible longer term with hypershift: one PE per physical server, for both the hosting and hosted clusters.
• Provide the same deployment model (PE on the node) for both IT workloads and Telco workloads.
• End to end troubleshooting and performance monitoring:
        1. Include a list of critical metrics.
        2. Include packet traceability across the stack.

Workloads

• HBR SHALL be transparent to the workloads for both primary and secondary interfaces: The deployment of these workloads SHOULD NOT be amended.
• Selected high performance workloads (<5Mpps/pod and/or zero packet loss, deterministic and low jitter and latency) SHALL be able to directly peer with the fabric.
• Workloads requiring any SLA (for example: 5Mpps/pod and/or zero packet loss, deterministic and low jitter and latency) MUST be supported by the PE router.
• SPK support for all clusters (SR-IOV pods today, VMs in the future).

3. Why does the customer need this? (List the business requirements here)
Users want to bypass the time delays in provisioning compute workload clusters that is caused by the dependency on their switching fabric layer and the teams that manage it for networking provisioning.

The goal of this RFE is to minimize or remove that overhead by simplifying the switching layer significantly and moving routing capabilities to the OpenShift hosts themselves. Minimizing the overhead of moving compute workloads between clusters will results in faster, more automated "Day 0" cluster build process. This change is critical for rapid scaling of users with complex networking installations.

4. List any affected packages or components.
UNK