@JaiOCP, @marian-pritsak - could you please help sign off on this?

Hi Ravi, My question is why do we need yet another workflow via IP2ME for neighbor miss? Is this because of certain hw constraints? I am missing the rationale of the proposal. Regards, -Jai
…
On Thu, Sep 19, 2024 at 10:08 PM Ravi [Marvell] @.> wrote: @.* commented on this pull request. ------------------------------ In inc/saihostif.h <#2066 (comment)> : > @@ -343,6 +343,13 @@ typedef enum _sai_hostif_trap_type_t / SAI_HOSTIF_TRAP_TYPE_ISIS = 0x00002014, + /* + * @brief Packets matching subnet routes with NH pointing to router interface + * i.e., no neighbor entry route is present + * (default packet action is trap) + / + SAI_HOSTIF_TRAP_TYPE_NEIGHBOR_MISS = 0x00002015, + @JaiOCP <https://github.com/JaiOCP\> SAI_HOSTIF_TRAP_TYPE_NEIGHBOR_MISS is analogous to SAI_HOSTIF_TRAP_TYPE_IP2ME. The only difference is that SAI_HOSTIF_TRAP_TYPE_IP2ME applies to packets hitting the IP2ME routes, and SAI_HOSTIF_TRAP_TYPE_NEIGHBOR_MISS applies to packets hitting the subnet route (i.e. no neighbor/ARP entry is present). Today, a NOS following SAI (say SONiC) installs IP2ME routes with NH as CPU port. They do not set SAI_ROUTE_ENTRY_ATTR_USER_TRAP_ID. So, packets hitting any IP2ME route go to the CPU based on the configuration for the SAI_HOSTIF_TRAP_TYPE_IP2ME. [Say Workflow#1] If the NOS wants each IP2ME route to be processed differently, then they can use the workflow you mentioned above, i.e., use SAI_ROUTE_ENTRY_ATTR_USER_TRAP_ID. [Say Workflow#2] In essence, there are two workflows a NOS can follow. SAI currently supports Workflow#2 for all route based traps, and the SAI support for workflow#1 is available only for IP2ME but not neighbor-miss. This proposal is adding the missing piece for neigbor-miss packets. — Reply to this email directly, view it on GitHub <#2066 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKCSHLOKXI6LV6BM7BWRKGLZXOUT7AVCNFSM6AAAAABMO2EKI6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGMJXGI3TKOBWG4\> . You are receiving this because you were mentioned.Message ID: @.**>
-- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

This is not a h/w limitation. It is the definition as per the SAI model. When an IP address and subnet, say 10.1.1.1/24 is on a RIF, the following set of routes are created as per SAI:

root@sonic-dut:~# config interface ip add Ethernet120 10.1.1.1/24

2024-10-07.14:41:31.066482|c|SAI_OBJECT_TYPE_ROUTER_INTERFACE:oid:0x60000000004f2|SAI_ROUTER_INTERFACE_ATTR_VIRTUAL_ROUTER_ID=oid:0x3000000000276|SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS=00:30:64:68:63:43|SAI_ROUTER_INTERFACE_ATTR_TYPE=SAI_ROUTER_INTERFACE_TYPE_PORT|SAI_ROUTER_INTERFACE_ATTR_PORT_ID=oid:0x1000000000132|SAI_ROUTER_INTERFACE_ATTR_MTU=9100
2024-10-07.14:41:31.071107|c|SAI_OBJECT_TYPE_ROUTE_ENTRY:{"dest":"10.1.1.1/32","switch_id":"oid:0x21000000000000","vr":"oid:0x3000000000276"}|SAI_ROUTE_ENTRY_ATTR_PACKET_ACTION=SAI_PACKET_ACTION_FORWARD|SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID=oid:0x1000000000125
2024-10-07.14:41:31.081518|C|SAI_OBJECT_TYPE_ROUTE_ENTRY||{"dest":"10.1.1.0/24","switch_id":"oid:0x21000000000000","vr":"oid:0x3000000000276"}|SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID=oid:0x60000000004f2

1. 10.1.1.1/32 to CPU (SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID points to CPU port). The CPU queuing is controlled using SAI_HOSTIF_TRAP_TYPE_IP2ME,
2. 10.1.1.X/24 route : This route points to CPU (In the SAI API model, this is done by setting SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID as the RIF). However, there is no standard hostif trap defined to control the CPU queuing behavior.

Note: Both the routes are created with SAI_PACKET_ACTION_FORWARD and not SAI_PACKET_ACTION_TRAP.

Both these routes can achieve the functionality by changing the packet action to Trap and use UDTs; but the standard SAI definition is to use SAI_PACKET_ACTION_FORWARD and the NH will point to CPU and RIF for route 1 and 2 respectively.

Please refer : https://github.com/opencomputeproject/SAI/blob/f23185d5baf25ef27afb2d5823559d4d3e9c7022/inc/sairoute.h#L78: "Directly reachable routes are the IP subnets that are
    * directly attached to the router. For such routes, fill the router
    * interface id to which the subnet is attached. IP2ME route adds a local
    * router IP address. For such routes, fill the CPU port
    * (#SAI_SWITCH_ATTR_CPU_PORT)."

I think a default makes sense, in case the user has SAI_NULL_OBJECT_ID as the trap id in the route.

Otherwise the user is forced to apply per-route, and this also puts a stress on the implementation. It's possible that some implementations may not support a per-route assignment of trap id for neighbor miss.

In general I think this is a good idea and we already support this kind of configuration as an extension for some users.

@prsunny for viz