Uri,
Thank you very much for your thoughts on the standards process.
We do need to understand significant technical objections to
whatever existing solution might be stated from.
Unfortunately, the solutions haven't responded to much
input or changed from the WG yet.
Regards,
Alia
On Jul 24, 2016 5:19 AM, "Elzur, Uri" <[email protected]
<mailto:[email protected]>> wrote:
Reading the threads here, it may be good to take a
moment to discuss expectations out of a std process. To
me, a “standard” is about an industry agreement, on a
path forward, in a timely fashion, that paves the way
(ushers in) the next wave of innovation. Let me try to
parse it
-Industry agreement: in singular (not in plural). The
process is to produce ONE agreed upon solution that
ideally gives no party any unfair advantage. It is
conceivable, however, that leaders retain some of the
first mover advantage. If the outcome is MULTITUDE of
“standards”, and in this particular case, it may mean
simply documentation of 3 separate commercial camps
where vendors have created competing approaches, we may
have missed the mark.
-In a timely fashion: One can’t ignore the time aspect.
When the std process is not moving fast enough, it
jeopardizes the value of the “industry agreement”. In
the last years, a significant productivity gains by the
software development and open source, enables much
faster evolution, one risks therefore, a catch up
scenario, lost relevance and falling into documentation.
The IETF process has to be updated to cope with the
faster evolution, so that within a year of emerging open
source direction (where relevant) the WG has narrowed
down the options to one and is very close to being done.
(yes, I know this is ideal…but this is what is needed)
-Path forward: that is a suitable technical solution to
a given set of problems with a limited set of forward
looking mechanism based on experience ( the “limit” is
really a judgment call to help with the goal of
timeliness); Including however, a reasonable evolution
of HW + SW. i.e. assuming HW (NICs in this case) is to
be of stagnant limited functionality (i.e. XSUM like
feature invented in 1996 – 20 years ago) as a base
assumption, should not be the lead assumption. IETF has
historically been more SW oriented, but data path
encapsulation should not be SW only discussion! Also the
emergence of programmable HW and modeling of HW to allow
easier programming, means that the std may be relaxed in
terms of rigid assumptions of HW functionality. (also
not to ignore other aspects, in most cases, the std
needs to be backwards compatible to not break existing
solutions)
-New innovation: a successful timely process, keeping
pace with the industry, with less vendor specific
options will do the trick here…
If we have similar expectations, it may be easier to
converge on the complicated problem at hand. 3 options
on the table for prolonged time, where the HW and SW
have already made progress. So I for one, don’t think in
THIS CASE, creating a 4^th option is the way forward. We
may be better served by picking one out of the existing ones
Thx
Uri (“Oo-Ree”)
C: 949-378-7568 <tel:949-378-7568>
*From:*nvo3 [mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *Linda Dunbar
*Sent:* Friday, July 22, 2016 1:11 PM
*To:* Anoop Ghanwani <[email protected]
<mailto:[email protected]>>; Bocci, Matthew (Nokia -
GB) <[email protected]
<mailto:[email protected]>>
*Cc:* NVO3 <[email protected] <mailto:[email protected]>>
*Subject:* Re: [nvo3] Consensus call on moving forward
with a single encap.
+1.
Besides, IETF already has specified many encapsulations,
is it really that bad having one extra?
Linda
*From:*nvo3 [mailto:[email protected]] *On Behalf Of
*Anoop Ghanwani
*Sent:* Friday, July 22, 2016 7:55 AM
*To:* Bocci, Matthew (Nokia - GB)
*Cc:* NVO3
*Subject:* Re: [nvo3] Consensus call on moving forward
with a single encap.
On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia -
GB) <[email protected]
<mailto:[email protected]>> wrote:
Please respond to this email on the NVO3 list by 29th
July 2016:
- Given the IETF's mission, should NVO3 move forward on
the standards track with a single encapsulation on the
standards track? If not, please explain your concern in
detail.
While the world would be a better place with only one
encapsulation, I think it's better to stick with the
original path of allowing the 3 encapsulations as
experimental.
The NVO3 charter says:
>>>
Based on these requirements the WG will select, extend,
and/or
develop one or more data plane encapsulation format(s).
>>>
Based on the charter, the WG has gone through the
process of accepting to work on 3 encapsulations. What
do we know now that we did not know back then?
If we were going to progress only a single
encapsulation, I think there would have been more
critical feedback and strong suggestions for changing
that "winning" encapsulation to accommodate what the
other encapsulations perceive as their relative
strengths. And we risk opening up that discussion now
and delaying progress even more.
Otherwise, not having a standard has not been a
hinderance for getting protocols deployed in the past,
and I suspect that if the developers of these
encapsulations care enough, we will see deployments of
all of them regardless of whether or not we progress
them within the working group.
Thanks,
Anoop
_______________________________________________
nvo3 mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
