I agree with Anton. I will even go further to say that current problem statement does not specify any problem that need metadata to solve.
-----Original Message----- From: nvo3 [mailto:[email protected]] On Behalf Of Anton Ivanov (antivano) Sent: Wednesday, March 05, 2014 12:17 AM To: [email protected] Subject: [nvo3] Metadata and NVO3 Hi all, I believe that there has been a general agreement that there is some need for metadata in the transports. However, instead of doing the basic work needed to implement that agreement we are jumping straight to solutions. None of the drafts so far present: * What are the architectural touchpoints for metadata. Who and how can modify it. "We shall innovate in software by sticking more bits" is not an answer - it does not make a standard. * Who has access to metadata. What is the metadata security model? Example - are the circumstances under which the Tenant System may see some of the metadata? * How do you handle a packet with metadata incoming from somewhere else if you need to add you own. Overwrite? Label Stack? All formats presented so far do not answer that question or imply overwrite. If we look at what has been successful label stack is probably a better answer (despite imposing immediate limitations on size and format of metadata). * How do you query the metadata? * Are we going to define a protocol which peels off metadata and passes it for external processing? * Are we going to define an API? * If the security model will allow API to be queried from inside tenants how would it be handled architecturally - local or through a central "controller/API GW". Without these any metadata in an encaps is worthless - what is the point of having metadata if you cannot query it? This is just off the top of my head. This topic needs a proper requirement draft and if the req draft is successful it can ask to be an architecture annex to the main NVO3 arch. Once these are defined, we will need a draft on the query APIs and/or methods as these may limit what you can use as metadata (these may introduce extra limitations). Then, and only then, we should be defining metadata in transports (I suspect SFC will define them for us by that time anyway). A. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
