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
