Hi Andrew, A slight difference - I have mentioned that SAI implementation will setup the ASIC to enable ARP resolution for an unresolved nexthop, whenever application creates the nexthop and has not created the neighbor entry.
Even if application needs to do so explicitly, the existing SAI neighbor API packet_action attribute can be used to trap packets for the IP address. This should solve the ECMP route case, I think. Anyway, we shall wait to hear from others about your proposal for the new API. Just to close on the original topic of the email - which is about the documentation in SAI Spec for Next Hop functionality - It looks like we can remove the restriction about mandatorily creating IP neighbor before the IP next hop. Please let me know if that is fine. Regards, Sathish From: Andrew Qu [mailto:andrew...@mediatek.com] Sent: Thursday, June 04, 2015 2:26 AM To: Thanne, Sathish Kumar; l...@barefootnetworks.com<mailto:l...@barefootnetworks.com>; opencompute-networking@lists.opencompute.org<mailto:opencompute-networking@lists.opencompute.org> Subject: RE: [Opencompute-networking] SAI Next Hop functionality description Hi Sathish, I followed your point that Application should be able to setup the ASIC to punt the packet routed towar the unresolved Adj to CPU. Then Application should be able to call SDK of any vendor to get a unique Adj that will do what you design. So those FIB using such ADJ will redirect packet to CPU so that SW will send ARP out, also once ARP resolved, Application Can do inline modification of that ADJ with new valid rewrite information. I didn’t see SAI provide such API so that Application can do such thing. Because in this case, Application has no next_hop_ip at All to call SDK to allocate next_hop ADJ for that FIB. Also consider ECMP case also requires such API as well. Hence, Yes, I am proposing new API if I didn’t miss it. Thanks, Andrew From: sathish_kumar_tha...@dell.com<mailto:sathish_kumar_tha...@dell.com> [mailto:sathish_kumar_tha...@dell.com] Sent: Wednesday, June 03, 2015 1:47 AM To: Andrew Qu; l...@barefootnetworks.com<mailto:l...@barefootnetworks.com>; opencompute-networking@lists.opencompute.org<mailto:opencompute-networking@lists.opencompute.org> Subject: RE: [Opencompute-networking] SAI Next Hop functionality description Hi Andrew, Thanks for sharing your views. Just to clarify, I am not mentioning to have a new SAI API/attribute in the reply to lj. My point is, SAI will setup the ASIC to punt packets routed towards unresolved adjacency to CPU and application can take the action needed (like ARP resolution, drop etc). Application can create the neighbor entry to be installed in ASIC as needed. Are you proposing that we need a new API/attribute in SAI for the two cases you have mentioned below? For the ECMP route case, unresolved paths will not be included in the ECMP group and packets for the destination route will be routed towards the active next hop paths, as you mentioned. Only when packets destined to the unresolved nexthop's address are routed, the packets will be punted to CPU based on the on-link route for the local interface subnet. Alternatively, application can create the neighbor entry with TRAP packet-action for the resolving the unresolved nexthop address. Please let me know if this is fine. Regards, Sathish From: Andrew Qu [mailto:andrew...@mediatek.com] Sent: Wednesday, June 03, 2015 12:22 PM To: Thanne, Sathish Kumar; l...@barefootnetworks.com<mailto:l...@barefootnetworks.com>; opencompute-networking@lists.opencompute.org<mailto:opencompute-networking@lists.opencompute.org> Subject: RE: [Opencompute-networking] SAI Next Hop functionality description Hi Sathish, I agree with your point to let application to allocate adjacency for the case you metioned. Also there may be ASIC that HOST/FIB/ adjacency including statistics counter index, so In this case, if multiple FIB share the same adjacency, but application want to attach stats counter To one of the FIB, so we can use separate ADJ for such fib and let the rest to share. In this case, Using interface and next hop will not be able to let Application to uniquely allocate A HW ADJ. Also there is a case where an IP FIB has ECMP path, but one of the PATH is not reaolved. So Application need also specifically allocate a ADJ which will punt packet to CPU to trigger ARP, without this approach, the unresolved path may *never* get resolved because HW will always forward packet out if we don’t force the unresolved ADJ (punting ADJ) Into the HW ECMP path. So pretty much letting user to allocate HW ADJ and providing such API is mandatory. Thanks, Andrew 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 ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
_______________________________________________ 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
