Hi Pankaj, I think the key point here is that it is one thing to indicate in the transport encapsulation that metadata is being carried but it is an entirely different thing to actually carry that metadata in the transport encapsulation itself.
From: Pankaj Garg <[email protected]<mailto:[email protected]>> Date: Monday, March 3, 2014 at 12:04 PM To: "Surendra Kumar (smkumar)" <[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]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [sfc] Followup on genev metadata Inline. From: Surendra Kumar (smkumar) [mailto:[email protected]] Sent: Monday, March 3, 2014 10:30 PM To: Pankaj Garg; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: Followup on genev metadata Inline. From: Pankaj Garg <[email protected]<mailto:[email protected]>> Date: Monday, March 3, 2014 8:43 AM To: Surendra Kumar <[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]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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. [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? 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 protected]] Sent: Monday, March 3, 2014 10:00 PM To: Pankaj Garg; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Followup on genev metadata [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.
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
