I think Uri makes an important point when he says that adding a 4th
encapsulation will compound the problem rather than solving it,
especially considering where the HW/SW implementations are today.
IMO this WG should focus on designing a control plane that allows to
discover and select the appropriate encapsulation, based on receiver's
capability.
Once that is done the overall architecture will be able to deal with
multiple encapsulations, and more than one can be moved to standard track.
This kind of work will also help with backward compatibility with
encapsulations (such as VXLAN, for example) that will be around for
quite some time.
Fabio
On 7/24/16 6:54 AM, Alia Atlas wrote:
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]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
