Dell - Internal Use - Confidential Hello lj, Regarding the second part you have mentioned about keeping the ARP resolution event configurable:
I think the configuration should be applicable to the control-plane (ARP/IP Stack) application that triggers the ARP requests. From SAI perspective, the ASIC should be setup to forward the packets based on the route or neighbor entry always. In this case, the routes pointing to an unresolved next-hop, will be expected to trap the packets to CPU for different control-plane needs - like, to trigger ARP resolution in control-plane (if configured as you pointed out) or to generate a standard ICMP error message (type 3, 5 etc) if the ARP resolution fails etc. Additionally, control-plane may create the neighbor entry with packet_action attribute set to DROP for the destination address in the current model. When ARP resolution fails (even after maximum retries), application could set the neighbor attribute which will be effective for all the routes pointing to the nexthop. This can be used for the security purpose to black-hole traffic for an unresponsive/insecure nexthop in the ASIC. Please let me know if this is fine. Regards, Sathish From: LJ Wobker [mailto:l...@barefootnetworks.com] Sent: Monday, June 01, 2015 11:14 PM To: Thanne, Sathish Kumar; opencompute-networking@lists.opencompute.org Subject: RE: [Opencompute-networking] SAI Next Hop functionality description Agree that these should not be tightly coupled. There are use cases (mostly esoteric ones, but use cases still the same) where you want to have a destination nexthop pointed to an interface without necessarily having a resolved adjacency. There should most definitely be a mechanism to have a packet to an unresolved adjacency trigger an ARP resolution event, but ideally this should be configurable as there may be cases (specific security models, etc) where the user specifically does NOT want a packet to an unresolved address to trigger an ARP event. --lj From: opencompute-networking-boun...@lists.opencompute.org<mailto:opencompute-networking-boun...@lists.opencompute.org> [mailto:opencompute-networking-boun...@lists.opencompute.org<mailto:opencompute-networking-boun...@lists.opencompute.org>] On Behalf Of sathish_kumar_tha...@dell.com<mailto:sathish_kumar_tha...@dell.com> Sent: Monday, June 01, 2015 6:22 AM To: opencompute-networking@lists.opencompute.org<mailto:opencompute-networking@lists.opencompute.org> Subject: [Opencompute-networking] SAI Next Hop functionality description Dell - Internal Use - Confidential Hi, This is to discuss on the below point documented in the SAI spec for SAI Next Hop functionality: "The user needs to create an IP neighbor before it creates an IP next hop. The sai associates them using the router interface ID and the IP address." I think there should not be a restriction that user needs to create the nexthop in SAI only after the neighbor entry is learnt/known. The nexthop and neighbor entry can be created from different applications and SAI implementation needs to associate them anyway for programming the routes. So, there need not be a dependency in the order of programming the entries in SAI. Additionally, when the nexthop is not ARP/neighbor resolved, the nexthop can be made to trap packet to CPU to enable ARP/neighbor resolution in the control-plane. This can be useful in a static route nexthop configuration and the neighbor can still be resolved dynamically when packets are routed to the nexthop. After the neighbor entry is learnt and created, SAI implementation can either update the nexthop object or update the route pointing to the nexthop object based on the support in ASIC. To summarize, should SAI let the user to create nexthop and neighbor entries independently and associate them internally? Also, should SAI implementation enable ARP/neighbor resolution when forwarding packets towards an unresolved nexthop? Please let me know your comments/questions. Regards, Sathish
_______________________________________________ opencompute-networking mailing list Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-networking opencompute-networking@lists.opencompute.org http://lists.opencompute.org/mailman/listinfo/opencompute-networking
