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. 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
