Subject: [sfc] Followup on genev metadata

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 3 Mar 2014 16:30:29 +0000

[Could not finish my question at the open-mic in consideration to fellow IETFrs behind me]

Author's stand on the metadata from the presentation and responses:

  1.  Metadata is for innovating and future-proofing
  2.  Metadata is indeed tied to the transport
  3.  Metadata will be standardized as they are defined
  4.  If metadata needs to be used on different transports, it is up to the folks defining it to take it to each and every transport and request standardization – obviously, these needs happen for every single one of them.

#4 makes absolutely no sense to me, please think about it. Why in the world does everybody have to go through the pain on every transport including those transports that are not defined yet but will be in the future. Would you rather not want these guys to standardize it once and use it in whatever transport they need to use ? Isn't that future proofing in a much better way ?

Surendra.
PS: BTW, this is no endorsement of the draft; rather wanted to get this straight given the discussion; I had to state It, sorry.

---

From: Pankaj Garg <[email-masked]>
Date: Mon, 3 Mar 2014 16:43:18 +0000

Just a clarification, author's stand is that transport provides a way to carry meta-data.

Let us take NSH example, how would you carry NSH in a protocol that doesn't have ETYPE for NextProtocol? If you think about it, then it would make sense that in one way or the other, you would need to extend the protocol to carry NSH and in turn get hardware offloads working for that protocol etc. For example, how would you carry it in VXLAN as it does not have ProtocolType field, so yes, you have to extend VXLAN, correct?

You can do the following, define a generic service chaining header (which I think is anyways the right approach), then decide the mechanism to carry it in different protocols, i.e. for one class of protocols, carrying it via ETYPE may be the right approach, whereas for other protocols a different mechanism may be better.

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, March 3, 2014 10:00 PM
To: Pankaj Garg; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Followup on genev metadata

  4.  If metadata needs to be used on different transports, it is up to the folks defining it to take it to each and every transport and request standardization - obviously, these needs happen for every single one of them.

Surendra.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 3 Mar 2014 16:59:39 +0000

Inline.

From: Pankaj Garg <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 3, 2014 8:43 AM
To: Surendra Kumar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Followup on genev metadata

Just a clarification, author’s stand is that transport provides a way to carry meta-data.

Let us take NSH example, how would you carry NSH in a protocol that doesn’t have ETYPE for NextProtocol? If you think about it, then it would make sense that in one way or the other, you would need to extend the protocol to carry NSH and in turn get hardware offloads working for that protocol etc. For example, how would you carry it in VXLAN as it does not have ProtocolType field, so yes, you have to extend VXLAN, correct?
SK> we both know the answer to this. GRE/NVGRE/VXLAN (gpe) all have protocol fields. It is not the same as signaling geneve. This is about transport independence.

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, March 3, 2014 10:00 PM
To: Pankaj Garg; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Followup on genev metadata

Surendra.

---

From: Pankaj Garg <[email-masked]>
Date: Mon, 3 Mar 2014 17:04:36 +0000

Inline.

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, March 3, 2014 10:30 PM
To: Pankaj Garg; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Followup on genev metadata

Inline.

Let us take NSH example, how would you carry NSH in a protocol that doesn't have ETYPE for NextProtocol? If you think about it, then it would make sense that in one way or the other, you would need to extend the protocol to carry NSH and in turn get hardware offloads working for that protocol etc. For example, how would you carry it in VXLAN as it does not have ProtocolType field, so yes, you have to extend VXLAN, correct?
SK> we both know the answer to this. GRE/NVGRE/VXLAN (gpe) all have protocol fields. It is not the same as signaling geneve. This is about transport independence.
[PG] No I don't know the answer, because VXLAN-GPE is not used today and hardware does not supporting offloading it. There is a proposal on generic UDP encapsulation which uses IP protocol number, how would you carry NSH in that? Isn't that dictating that you would get transport independence only if you support encapsulating ETYPE? Btw think about other use case, how do you carry IPv6 in IP and Ethernet?

Surendra.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 4 Mar 2014 09:21:28 +0000

SK> we both know the answer to this. GRE/NVGRE/VXLAN (gpe) all have protocol fields. It is not the same as signaling geneve. This is about transport independence.
[PG] No I don’t know the answer, because VXLAN-GPE is not used today and hardware does not supporting offloading it. There is a proposal on generic UDP encapsulation which uses IP protocol number,

[Xiaohu] Did you mean http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-01 ? If so, there is an ETYPE field in the GRE header which would be used for indicating the existence of metadata in the encapsulated packet.

Xiaohu

 how would you carry NSH in that? Isn’t that dictating that you would get transport independence only if you support encapsulating ETYPE? Btw think about other use case, how do you carry IPv6 in IP and Ethernet?

---

From: Pankaj Garg <[email-masked]>
Date: Tue, 4 Mar 2014 09:36:33 +0000

Inline

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Tuesday, March 4, 2014 2:51 PM
To: Pankaj Garg; Surendra Kumar (smkumar); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [sfc] 答复: Followup on genev metadata

[Xiaohu] Did you mean http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-01 ? If so, there is an ETYPE field in the GRE header which would be used for indicating the existence of metadata in the encapsulated packet.
[PG] No I meant: http://tools.ietf.org/id/draft-herbert-gue-00.txt

Xiaohu