[snip]
>> Without these any metadata in an encaps is worthless - what is the point
>> of having metadata if you cannot query it?
>>
> These are implementation and API considerations rather than
> 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
> 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.
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
> 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.
In the absence of requirements that will be a very very very long run then.
>
>> 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).
>>
> 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?
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.
>
> Thanks,
> Tom
>
>> 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
