Subject: Re: [nvo3] suggestions on data plane requirements draft

From: ramki Krishnan <[email-masked]>
Date: Mon, 3 Jun 2013 11:15:37 -0700

Hi Nabil, All,

Hope you got a chance to look at the comments below.

Thanks,
Ramki

From: ramki Krishnan
Sent: Thursday, May 09, 2013 8:06 AM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [nvo3] suggestions on data plane requirements draft

Dear Authors,

Would like to remind on the following.

1)
In section 3.3.2.1 (LAG/ECMP), the change suggested below articulates the inference of entropy in a much better way.

>>The entropy information MAY be inferred from the NVO3 overlay header or underlay header.

The entropy information should be ideally present in the overlay header e.g. Entropy Label for MPLS [RFC 6790], VXLAN – UDP source port. In case the overlay protocol does not support the necessary entropy information or the switches/routers in the underlay do not support parsing of the additional entropy information in the overlay header, the following support is needed in the underlay switches/routers. The underlay switches and routers should be programmable, i.e. select the appropriate fields in the underlay header for hash calculation based on the type of overlay header – the point to note is even the location of the underlay header in the packet will vary based on the type of overlay header.

2)
In section 3.3.2.1 (LAG/ECMP), it is worth adding large flow load balancing as an optional requirement for optimal bandwidth utilization.
http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/

Thanks,
Ramki
From: Jon Hudson [mailto:[email-masked]]
Sent: Wednesday, April 17, 2013 8:41 AM
To: ramki Krishnan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] suggestions on data plane requirements draft

+1

On Apr 17, 2013, at 5:25 PM, ramki Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
Dear Authors,

In section 3.3.2.1 (LAG/ECMP), the change suggested below articulates the inference of entropy in a much better way.

>>The entropy information MAY be inferred from the NVO3 overlay header or underlay header.

The entropy information should be ideally present in the overlay header e.g. Entropy Label for MPLS [RFC 6790], VXLAN – UDP source port. In case the overlay protocol does not support the necessary entropy information or the switches/routers in the underlay do not support parsing of the additional entropy information in the overlay header, the following support is needed in the underlay switches/routers. The underlay switches and routers should be programmable, i.e. select the appropriate fields in the underlay header for hash calculation based on the type of overlay header – the point to note is even the location of the underlay header in the packet will vary based on the type of overlay header.

Thanks,
Ramki
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Mon, 3 Jun 2013 21:02:30 +0000

Hi Ramki,

Your 1st comment has already been included in the soon-to-be-published revision.
The 2nd comment has not been addressed per se since there is already a generic sentence about optimal bandwidth usage.

Thanks,
Marc

________________________________
From: ramki Krishnan [mailto:[email-masked]]
Sent: Monday, June 03, 2013 8:16 PM
To: Bitar, Nabil N; LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); [email-masked]; Lizhong Jin; Bhumip Khasnabish
Cc: [email-masked]
Subject: RE: [nvo3] suggestions on data plane requirements draft

Hi Nabil, All,

Thanks,
Ramki

From: ramki Krishnan

Dear Authors,

1)

>>The entropy information MAY be inferred from the NVO3 overlay header or underlay header.

The entropy information should be ideally present in the overlay header e.g. Entropy Label for MPLS [RFC 6790], VXLAN - UDP source port. In case the overlay protocol does not support the necessary entropy information or the switches/routers in the underlay do not support parsing of the additional entropy information in the overlay header, the following support is needed in the underlay switches/routers. The underlay switches and routers should be programmable, i.e. select the appropriate fields in the underlay header for hash calculation based on the type of overlay header - the point to note is even the location of the underlay header in the packet will vary based on the type of overlay header.

2)

Thanks,
Ramki

+1

>>The entropy information MAY be inferred from the NVO3 overlay header or underlay header.

The entropy information should be ideally present in the overlay header e.g. Entropy Label for MPLS [RFC 6790], VXLAN - UDP source port. In case the overlay protocol does not support the necessary entropy information or the switches/routers in the underlay do not support parsing of the additional entropy information in the overlay header, the following support is needed in the underlay switches/routers. The underlay switches and routers should be programmable, i.e. select the appropriate fields in the underlay header for hash calculation based on the type of overlay header - the point to note is even the location of the underlay header in the packet will vary based on the type of overlay header.

Thanks,
Ramki

---

From: ramki Krishnan <[email-masked]>
Date: Mon, 3 Jun 2013 14:45:31 -0700

Hi Mark,

Thanks.

On the second comment - I think it is worth adding the large flow draft as reference for optimal bandwidth usage. For example, you are already referencing RFC 6391.

Thanks,
Ramki

From: LASSERRE, MARC (MARC) [mailto:[email-masked]]
Sent: Monday, June 03, 2013 2:03 PM
To: ramki Krishnan; Bitar, Nabil N; Balus, Florin Stelian (Florin); [email-masked]; Lizhong Jin; Bhumip Khasnabish
Cc: [email-masked]
Subject: RE: [nvo3] suggestions on data plane requirements draft

Hi Ramki,

Thanks,
Marc

To: Bitar, Nabil N; LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); [email-masked]<mailto:[email-masked]>; Lizhong Jin; Bhumip Khasnabish

Thanks,
Ramki

From: ramki Krishnan

Dear Authors,

1)

2)

Thanks,
Ramki

+1

Thanks,
Ramki