Subject: [nvo3] Metadata and NVO3

From: "Anton Ivanov (antivano)" <[email-masked]>
Date: Wed, 5 Mar 2014 08:16:53 +0000

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.

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 5 Mar 2014 08:44:52 +0000

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-masked]] On Behalf Of Anton Ivanov (antivano)
Sent: Wednesday, March 05, 2014 12:17 AM
To: [email-masked]
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.

  * 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-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Mar 2014 09:12:38 +0000

I want to support Anton's request regarding new solutions; its a good idea to not put the "donkey before the cart" as he said yesterday. 

	--Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 5 Mar 2014 11:48:04 -0800

> of having metadata if you cannot query it?
These are implementation and API considerations rather than
fundamental characteristics of an on-the-wire protocol. The set of
Internet protocols is replete with protocols that include variable
length options (IP, TCP, GRE, etc.), and I don't see anything
particularly unique in nvo3 which necessitates a re-architecture of
the concept. If you look at implementations of these other protocols
you'll get a lot of answers to your questions. Please try to separate
out the implementation, API, and product requirements from protocol
specification; in the long run it will yield a simpler and more
generic protocol with fewer customizations.

> suspect SFC will define them for us  by that time anyway).
Sounds like a rather long process to me. In this model, what is the
time frame when a protocol would be proposed that I might be able to
implement and deploy?

Thanks,
Tom

---

From: "Anton Ivanov (antivano)" <[email-masked]>
Date: Wed, 5 Mar 2014 23:17:06 +0000

[snip]

> fundamental characteristics of an on-the-wire protocol.

Protocols serve a purpose. At least for most of us.

If a protocol has no purpose it has no right to exist.

>  The set of
> the concept.

Several "minor" points
    - they all serve a purpose
    - they were invented in the days when hardware was not a major
consideration
    - the designers had some reqs to satisfy _BEFORE_ they designed the
protocol

>  If you look at implementations of these other protocols

In the absence of requirements that will be a very very very long run then.

> time frame when a protocol would be proposed that I might be able to

If there will be no requirements for the proto including how to use it
(which means considerations on how to consume the metadata), then the
correct answer is "not any time soon".

So if you want the process to be shorter write requirements draft first.

A.