Thanks Mukhtiar, more inline. <MK>The problem is not necessarily when a link is removed from the LAG upon failure..but when it comes back up. Again, the assumption here is that link has been experiencing repeated failures and every time it comes back up, flows need to be readjusted. Therefore, if there is a history of failures on a given link in the LAG, rebalancing could be done in a more conservative way to minimize instability.
Good point. What you are bringing up would be applicable for normal LAG also - we could potentially reduce the weight of the LAG member ports connected to flaky links. Thanks, Ramki From: Mukhtiar Shaikh Sent: Tuesday, September 10, 2013 11:46 PM To: ramki Krishnan; [email protected] Cc: [email protected] Subject: Re: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" Thanks Ramki. Please see comments inline: From: ramki Krishnan <[email protected]<mailto:[email protected]>> Date: Tuesday, September 10, 2013 2:04 PM To: Mukhtiar Shaikh <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" Hi Mukhtiar, Thanks for your comments. Please find answers inline. >>I think section 4.3.4. Automatic Hardware Recognition is a little vague. It >>is not clear how and what is expected from the hardware to detect the large >>flows. Is it sampling of packet forwarding counters in hardware or something >>else? Any clarity on this will be good. Since the details are implementation specific, we are not planning on expanding this section - IETF does not recommend specific implementations. <MK> I was not suggesting to expand using implementation specific details..I was thinking of including some general examples such faster sampling capability in hardware, hardware packet counters etc >> Also, from operational considerations point of view, as indicated in section >> 6, frequent rebalancing of flows could be counter productive leading to out >> of order packets and /or system instability. Similar challenges could arise >> from immediate rebalancing of flows on one or more component links in the >> LAG experiencing frequent failures. System may implement a throttling >> mechanism to regulate when and what types of flows are re-distributed to >> potentially flaky links to avoid instability. Flaky links should be detected by the system and removed from the LAG right ? I am not sure if there is anything specific we need to for large flow LAG load balancing. <MK>The problem is not necessarily when a link is removed from the LAG upon failure..but when it comes back up. Again, the assumption here is that link has been experiencing repeated failures and every time it comes back up, flows need to be readjusted. Therefore, if there is a history of failures on a given link in the LAG, rebalancing could be done in a more conservative way to minimize instability. Regards, -Mukhtiar Thanks, Ramki From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mukhtiar Shaikh Sent: Monday, September 09, 2013 10:54 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" I support the publication of this document as informational RFC. Have a couple of additional comments. I think section 4.3.4. Automatic Hardware Recognition is a little vague. It is not clear how and what is expected from the hardware to detect the large flows. Is it sampling of packet forwarding counters in hardware or something else? Any clarity on this will be good. Also, from operational considerations point of view, as indicated in section 6, frequent rebalancing of flows could be counter productive leading to out of order packets and /or system instability. Similar challenges could arise from immediate rebalancing of flows on one or more component links in the LAG experiencing frequent failures. System may implement a throttling mechanism to regulate when and what types of flows are re-distributed to potentially flaky links to avoid instability. Thanks, -Mukhtiar -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Melinda Shore Sent: Saturday, August 24, 2013 1:07 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" This is to announce the start of working group last call on: Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ It is intended for publication as an informational RFC. Please give it a careful read and provide any feedback to this mailing list by September 9, 2013 Thanks, opsawg chairs _______________________________________________ OPSAWG mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
