Subject: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/

From: Melinda Shore <[email-masked]>
Date: Wed, 10 Apr 2013 05:16:06 -0800

This is a call for working group adoption of
http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balancing/.

The authors report that they've incorporated feedback given at
the IETF 86 meeting, in particular
  . information model for flow rebalancing
  . operational considerations

We'll be assessing consensus on 24 April 2013.

Thanks,

Melinda

---

From: Lucy yong <[email-masked]>
Date: Wed, 10 Apr 2013 13:55:56 +0000

Support as one of co-authors.

Lucy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Melinda Shore
> Sent: Wednesday, April 10, 2013 8:16 AM
> To: [email-masked]
> Subject: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-
> load-balancing/
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: ramki Krishnan <[email-masked]>
Date: Wed, 10 Apr 2013 07:13:15 -0700

Support this draft.

Thanks,
Ram (aka Ramki)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, April 10, 2013 6:16 AM
To: [email-masked]
Subject: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/

This is a call for working group adoption of http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balancing/.

The authors report that they've incorporated feedback given at the IETF 86 meeting, in particular
  . information model for flow rebalancing
  . operational considerations

Thanks,

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 10 Apr 2013 14:33:54 +0000

Support. 

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

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 10 Apr 2013 09:58:23 -0700

Support (as co-author).

Anoop

---

From: Tina TSOU <[email-masked]>
Date: Wed, 10 Apr 2013 17:11:12 +0000

Dear all,
I support this adoption.

Thank you,
Tina

On Apr 10, 2013, at 9:58 AM, "Anoop Ghanwani" <[email-masked]<mailto:[email-masked]>> wrote:

Support (as co-author).

Anoop

On Wed, Apr 10, 2013 at 6:16 AM, Melinda Shore <[email-masked]<mailto:[email-masked]>> wrote:
This is a call for working group adoption of
http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balancing/.

Thanks,

Melinda
_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: ramki Krishnan <[email-masked]>
Date: Fri, 12 Apr 2013 09:37:38 -0700

Below are comments from Pete (as an individual) and responses below.

Agreed Pete - will do.

Thanks,
Ramki

-----Original Message-----
From: Pete Moyer 
Sent: Thursday, April 11, 2013 7:08 PM
To: ramki Krishnan
Subject: RE: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/

Cool. One last comment -

>>Did you mean "....is required to allow the import of large flow information from the router."?
No, in this case, the large flow recognition (detection) is handled in a external management station. The detected large flows need to be imported to the router for re-balancing purposes.

OK, I missed that but now I read it correctly. Perhaps you might say "export" (aka: push) to the router rather than "import" (aka: pull) to the router. That will also avoid confusion I think.

Thanks.

-----Original Message-----
From: ramki Krishnan 
Sent: Thursday, April 11, 2013 12:12 PM
To: Pete Moyer; Sanjay Khanna; Gary Seebaum; Norival Figueira
Subject: RE: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/

Hi Pete,

Thanks a lot. For some of the questions, I will cc the opsawg mailing list. The chairs love to see activity in the mailing list.

>>Section 3, Step 2) The egress component links are periodically scanned for link
   utilization. If the egress component link utilization exceeds a pre-
   programmed threshold, an operator alert is generated. The large flows
   mapped to the congested egress component link are exported to a
   central management entity.

>>Did you mean "Information about the large flows mapped to the congested egress component link are exported to a central management entity."
Yes, thanks for catching this.

>>Section 4.2) In cases where large flow recognition is handled by an external
   management station (see Section 3.1.3), an information model for
   flows is required to allow the import of large flow information to
   the router.

>>Did you mean "....is required to allow the import of large flow information from the router."?
No, in this case, the large flow recognition (detection) is handled in a external management station. The detected large flows need to be imported to the router for re-balancing purposes.

>> Also, have you considered any OpenFlow/SDN use case for re-balancing the flows?
Certainly. I have not explicitly mentioned OpenFlow since it is not advocated by IETF.

Regarding SDN, it is covered in section 4.2 " In cases where large flow recognition is handled by an external  management station (see Section 3.1.3), an information model for flows is required to allow the import of large flow information to  the router....". The SDN application would be an sFlow collector performing the large flow recognition.

Thanks,
Ramki

-----Original Message-----
From: Pete Moyer 
Sent: Thursday, April 11, 2013 11:45 AM
To: ramki Krishnan; Sanjay Khanna; Gary Seebaum; Norival Figueira
Subject: RE: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/

I will do that. I do have a few comments:

Section 3, Step 2) The egress component links are periodically scanned for link
   utilization. If the egress component link utilization exceeds a pre-
   programmed threshold, an operator alert is generated. The large flows
   mapped to the congested egress component link are exported to a
   central management entity.

Did you mean "Information about the large flows mapped to the congested egress component link are exported to a central management entity."

Section 4.2) In cases where large flow recognition is handled by an external
   management station (see Section 3.1.3), an information model for
   flows is required to allow the import of large flow information to
   the router.

Did you mean "....is required to allow the import of large flow information from the router."?

Also, have you considered any OpenFlow/SDN use case for re-balancing the flows? 

Thanks.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, April 10, 2013 6:16 AM
To: [email-masked]
Subject: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/

Thanks,

Melinda

---

From: "Cao,Zhen (cz)" <[email-masked]>
Date: Tue, 16 Apr 2013 13:15:08 +0800

Hi All,

This is a useful document for DC operators as well as SPs that are
operating data centers. And I would like to support this adoption.

With the following comments,
1. title of section 2, "Hash-based Load Distribu tion in LAG/ECMP", you
might need to remove the space within 'distribution'
2. For Section 3.1.1., there is a short discussion about flow
identification of several tunneling protocols, VXLAN, NVGRE, etc, I expect
more description of the challenges and problems for these protocols as they
are happening with the DC, e.g., mapping of the overlay flow pattern to the
physical layer, could be a useful guidance for those who are operating
these tunnel.

Best regards,
zhen
chinamobile

---

From: Benoit Claise <[email-masked]>
Date: Tue, 16 Apr 2013 12:52:34 +0200

Dear all,

My analysis is that the mechanism described in the draft is a local 
load-balancing optimization, which doesn't influence the bits on the wire.

Note that Curtis had a similar concern during the OPSAWG meeting (see 
the minutes 
<http://www.ietf.org/proceedings/86/minutes/minutes-86-opsawg>),

    Curtis Villamizar: Looks like implementation details, not operational issues.
    Not appropriate here, even as an Informational RFC.  Also has concerns with
    specific approach, which requires configuration.

Therefore, I don't believe that this draft is appropriate for the WG.

Regards, Benoit (as a contributor)

---

From: ramki Krishnan <[email-masked]>
Date: Tue, 16 Apr 2013 13:48:07 -0700

Dear Zhen,

Thanks a lot for your comments. We will incorporate the appropriate changes in the next version.

Thanks,
Ramki

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cao,Zhen (cz)
Sent: Monday, April 15, 2013 10:15 PM
To: Melinda Shore
Cc: [email-masked]
Subject: Re: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/

Hi All,

This is a useful document for DC operators as well as SPs that are operating data centers. And I would like to support this adoption.

With the following comments,
1. title of section 2, "Hash-based Load Distribu tion in LAG/ECMP", you might need to remove the space within 'distribution'
2. For Section 3.1.1., there is a short discussion about flow identification of several tunneling protocols, VXLAN, NVGRE, etc, I expect more description of the challenges and problems for these protocols as they are happening with the DC, e.g., mapping of the overlay flow pattern to the physical layer, could be a useful guidance for those who are operating these tunnel.

Best regards,
zhen
chinamobile

On Wed, Apr 10, 2013 at 9:16 PM, Melinda Shore <[email-masked]<mailto:[email-masked]>> wrote:
This is a call for working group adoption of
http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balancing/.

Thanks,

Melinda

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 19 Apr 2013 10:46:34 -0700

Benoit,

Discussion of issues like these (without changing the bits on the wire) are
often found in BCPs and other informational RFCs. see
http://www.rfc-editor.org/rfc/rfc4928.txt as an exmple. I support this
draft being adopted by the WG.

Cheers,
Andy

On Tue, Apr 16, 2013 at 3:52 AM, Benoit Claise <[email-masked]> wrote:

> Note that Curtis had a similar concern during the OPSAWG meeting (see the
> minutes <http://www.ietf.org/proceedings/86/minutes/minutes-86-opsawg>),
>
> This is a call for working group adoption ofhttp://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balancing/.
>
> OPSAWG mailing [email-masked]://www.ietf.org/mailman/listinfo/opsawg
>
>
>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 24 Apr 2013 10:57:27 -0700

Folks,

I came to the attention of the Chairs and the ADs during the call for 
adoption that an IPR disclosure was likely pending on this draft. It has 
since transpired.

The disclosure can be reviewed here.

http://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-krishnan-opsawg-large-flow-load-balancing.

In my opinion this is bit late frankly but short of 6701 remedy 
territory. I have asked the chairs to extend the current call for 
additional time (which they should chime in on), and I would ask that if 
the disclosure alters you opinion of the document that you please make 
your concerns known.

I'd like to thank the authors for their candor, and the chairs for 
bringing this to our attention.

Joel

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Apr 2013 07:09:01 +0900

> adoption that an IPR disclosure was likely pending on this draft. It
> has since transpired.
> 
> additional time (which they should chime in on), and I would ask that
> if the disclosure alters you opinion of the document that you please
> make your concerns known.
> 

i sent a concerned private email to some folk.  one replied

    The authors have indicated that the stuff on which they've filed the
    patent application is not the only mechanism that can be used for
    large flow detection - i.e. this can be implemented without using
    their to-be-encumbered technology.

if this is the case, why not simply remove the to-be-encumbered
technology from the document?

otherwise, we potentially will waste a lot of time over this ipr claim.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Apr 2013 11:35:18 +1200

> technology from the document?

I agree; it's not worth the pain, for an example algorithm in an
Informational document. (The same goes for
draft-krishnan-ipfix-flow-aware-packet-sampling.)

    Brian

---

From: ramki Krishnan <[email-masked]>
Date: Wed, 24 Apr 2013 16:40:29 -0700

Thanks Brian, agreed.

Thanks,
Ramki

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, April 24, 2013 4:35 PM
To: Randy Bush
Cc: [email-masked]
Subject: Re: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/

> technology from the document?

I agree; it's not worth the pain, for an example algorithm in an Informational document. (The same goes for
draft-krishnan-ipfix-flow-aware-packet-sampling.)

    Brian

---

From: Benoit Claise <[email-masked]>
Date: Thu, 25 Apr 2013 15:42:48 +0200

> technology from the document?
While it's not the IETF business to validate IPRs, let me stress one 
line from the IPR page
     Reasonable and Non-Discriminatory License to All Implementers with 
Possible Royalty/Fee.

Regards, Benoit

---

From: Sanjay Khanna <[email-masked]>
Date: Wed, 24 Apr 2013 17:33:47 -0700

Folks,

I am supporting the draft as a co-author. We have seen problems in carrier networks where large flows can trump small flows. This draft is presenting some solutions to the problem which will be beneficial in solving this problem in provider networks. 

Regards,
Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, April 10, 2013 6:16 AM
To: [email-masked]
Subject: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/

Thanks,

Melinda