City training jobs must span GPU racks in more than one Layer-2 domain inside the municipal data center. Why should the fabric team prefer RoCEv2 over classic RoCE for that design?

Classic RoCE is oriented around a Layer-2 scope, while RoCEv2 encapsulates RDMA over UDP/IP so flows can be routed across Layer-3 boundaries. When city training jobs must span GPU racks in more than one L2 domain inside the municipal data center, RoCEv2 is preferred because that routability lets collectives leave a single broadcast domain without redesigning the entire POD as one giant L2. Claiming RoCEv2 is routable via TCP/IP gets the transport wrong: RoCEv2 encapsulates RDMA over UDP/IP with destination port 4791, not TCP, so TCP/IP cannot explain its ability to cross L2 boundaries for multi-domain city training. Describing RoCEv2 as routable via Ethertype 0x8915 confuses the versions: 0x8915 is classic RoCE's Layer-2 Ethertype that stays within a single broadcast domain, while RoCEv2's ability to span racks comes from routable UDP/IP encapsulation. Saying classic RoCE is routable via GRH/IP reverses the design: classic RoCE remains Layer-2-oriented and cannot use L3 forwarding, so it cannot carry training across separate municipal L2 domains like routable RoCEv2 can. Exam caveat: routable RoCEv2 still needs consistent QoS and congestion treatment across the L3 path—routing alone does not create lossless behavior. Operational check: place trainer endpoints in distinct L2 domains connected by civic L3, enable RoCEv2, confirm UDP/IP RDMA flows traverse the routed path successfully, and validate end-to-end Cos/DSCP and PFC/ECN behavior across that path.