Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing

From: ramki Krishnan <[email-masked]>
Date: Tue, 25 Sep 2012 20:42:49 -0700

All,

http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balancing/

Best Practices for Optimal LAG/ECMP Component Link Utilization in Provider Backbone networks - Key ideas
The suggested techniques in this draft for optimal LAG/ECMP component link utilization are meant to put forth a locally optimized solution, i.e. local in the sense of both measuring and optimizing for long-lived large flows at individual nodes in the network. This approach would not yield a globally optimal placement of a large, long-lived flow across several nodes in the network which some networks may desire/require. On the other hand, this may be adequate for some operators for the following reasons 1) Different links in the network experience different levels of utilization and, thus, a more "targeted" solution is needed for those few hot-spots in the network 2) Some networks may lack end-to-end visibility.

Areas which need further discussion
Standards-based data model for exporting long-lived large flow information from routers to a central management entity.

Your comments/feedback would be much appreciated.

Thanks, ramki

From: ramki Krishnan
Sent: Tuesday, September 25, 2012 10:10 AM
To: 'Scott Bradner'; 'Chris Liljenstolpe'; 'Melinda Shore'
Cc: Sanjay Khanna; [email-masked]'
Subject: new IETF draft - large flow load-balancing

All,

A new IETF draft on large flow load-balancing has been posted. We have very good feedback so far from Shane Amante; your comments would be much appreciated.

http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balancing/

Thanks, ram

---

From: "He, Peng" <[email-masked]>
Date: Wed, 26 Sep 2012 09:29:03 -0400

Ramki,

When talking about LAG, is this the IEEE LAG (802.1ax, or the previous IEEE 802.3ad) running LACP, or something else? If it is L2 LAG, then how a L3 router can decide which component link in the LAG to send traffic.

Long-lived flow/short-lived flows, or long holding-time flows/short holding-time flows, are sort of relative concepts. Usually how 'longer' a flow compared to 'short lived' flows can be defined as a long lived flow. this might be too practical, as it could be different to different networks and traffic characteristics.

Regards,
Peng

From: [email-masked] [mailto:[email-masked]] On Behalf Of ramki Krishnan
Sent: Tuesday, September 25, 2012 11:43 PM
To: Scott Bradner; Chris Liljenstolpe; Melinda Shore; [email-masked]
Cc: Sanjay Khanna
Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing

All,

Thanks, ramki

From: ramki Krishnan

All,

Thanks, ram

---

From: ramki Krishnan <[email-masked]>
Date: Wed, 26 Sep 2012 09:42:26 -0700

Hi Peng,

Thanks for the comments. Please find answers inline.

Thanks, ramki

From: He, Peng [mailto:[email-masked]]
Sent: Wednesday, September 26, 2012 6:29 AM
To: ramki Krishnan; Scott Bradner; Chris Liljenstolpe; Melinda Shore; [email-masked]
Cc: Sanjay Khanna
Subject: RE: new IETF draft - large flow load-balancing

Ramki,

When talking about LAG, is this the IEEE LAG (802.1ax, or the previous IEEE 802.3ad) running LACP, or something else? If it is L2 LAG, then how a L3 router can decide which component link in the LAG to send traffic.
[ramki Krishnan] This is IEEE LAG running LACP. Today's Layer 3 routers always support Layer 2; in other words, a Layer 3 router is also a Layer 2 switch besides being a router. Maybe, I will explicitly clarify this in the draft to avoid ambiguity.

Long-lived flow/short-lived flows, or long holding-time flows/short holding-time flows, are sort of relative concepts. Usually how 'longer' a flow compared to 'short lived' flows can be defined as a long lived flow. this might be too practical, as it could be different to different networks and traffic characteristics.
[ramki Krishnan] Our recommendation in the draft is to make the following parameters programmable in the router by the Operator - 1) The minimum time for which a flow has to be active to deem it a candidate long-lived large flow. 2) The minimum number of packets during the previously defined time interval. The above parameters will translate to a minimum long-lived large flow rate. This will help addresses various deployment scenarios/applications.

Regards,
Peng

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ramki Krishnan
Sent: Tuesday, September 25, 2012 11:43 PM
To: Scott Bradner; Chris Liljenstolpe; Melinda Shore; [email-masked]<mailto:[email-masked]>
Cc: Sanjay Khanna
Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing

All,

Thanks, ramki

From: ramki Krishnan

All,

Thanks, ram