Basic underlay routing bmv2 to handle MAC address updates

[KrisNey-MSFT]

Here is the convo re: the issue - the jist of what is needed is in the Title.

Chris: do you want to be able to send traffic from port1-port2 for underlay etc.

Volodymyr – Having if else in code for real HW and BMv2 would be confusing.

Marian – BMv2 could do GW to port. Volodymyr - full underlay support not required but enough to send and receive traffic.

Mukesh – MAC address aspect to be resolved. We can solve with basic SAI routing, but BMV2 implementation ignores and sends packet out on same interface. Test will still work with default route that is pointing to both interfaces. The ### gap is underlay mac address that was pushed needs to be updated. If we can plumb in MAC address using existing SAI API. We need P4 table updated just enough

Marian – agree MAC address portion is open

Vincent – Intel test cases document where routing lookup is done and MAC / port is needed

Marian – default routing works in BMv2 and specific IP destination is looked up and send to specific port does not work

Volodymyr – Real DPU we advertise real addresses. P4 needs an update to update MAC address and need Automatic way to implement libsai

Group – WE can add the simple routing with MAC address resolution to task list.

For Real HW with 2 ports is the requirement for packet to come in one port and go out on another ? Yes. Both ports have same cost and ECMP needed.

For DASH assume simple routing. There needs to be a model how we connect these 2 blocks of routing and DASH. Full routing with uplinks/downlinks is SmartSwitch use case.

Don’t need to support per router interface. List of attributes in DASH HLD needs to be implemented, router-interface and source MAC address should be of the switch. Destination should be resolved based on Nexthop and neighbor. LPM lookup will point to ECMP of both ports so it doesn’t matter.

[KrisNey-MSFT]

As sections are added to SONiC-HLD we can refer to the latest from Prince

[KrisNey-MSFT]

Discussed James' email of 2/1/2023 to go through and identify if P4 items are applicable.
Code base unmaintained, work may be 'nontrivial'.
Possibly go over in Behavioral Model meeting 2/2/2023?

[KrisNey-MSFT]

Underlay MAC address needs to be added by underlay routing.

[KrisNey-MSFT]

Complete underlay in bmv2, we do not have the SAI path in the behavioral model.

Can we assume this will be done in SmartSwitch?

Had to comment out 'underlay routing' in @ashutosh-agrawal 's test

No neighbor table, how will bmv2 select the correct MAC address

Don't want to generate SAI APIs from P4 code

Next-hop table was implemented to facilitate testing

Allow pre-defined SAI APIs along side of DASH generated code; write a backend handler to deal w/hard-coded SAI APIs (Chris)