Lucy,
Thanks for sending this mail. It contains a lot of useful
information.
My understanding is that, if we decide to use a new
encapsulation
- instead of making the simplest changes possible to existing/deployed NVO
encapsulations - we will already be inflicting some degree of pain on the DCN
industry.
You ask a good question, though, and - to answer it - we would
need
a way to determine which approach will inflict the greatest pain.
The answer seems obvious: living with more than one additional
form
of encapsulation (there already exists one standard form of encapsulation for
the L2 case, at least) will result in a cumulative costs that we can clearly
expect
to exceed the expected lower cost of only living with one additional encaps.
With existing deployments, however, the approach of using a
single
new encapsulation inflicts a short-term migration cost on those who already
have deployed solutions.
Previously, this would be viewed as the risk of early
deployment of a
non-standard solution.
As you are probably aware, though, the industry recently went
through
a bit of a fiasco because viewing excessive migration costs as the risk accepted
by customers who have deployed a non-standard solution, is not acceptable to
customers any more.
In this case (for example) while VxLAN and NVGRE are not
standards,
they are very well known mechanisms.
As I understand it, our present predicament is not the result
of having
two solutions that don't work; it results from having two solutions that do
work.
So, in reality, isn't it likely that - if we define yet another
encapsulation
approach - we may only be increasing the immediate, short-term costs by quite
a lot on the unrealistic (and unverifiable) presumption that everyone will
switch
to it, and we'll end up with 3 additional encapsulations that need to interwork
(effectively increasing the long term costs of the presumed lower-long-term cost
approach such that it is now higher, rather than lower, than the cost of simply
modifying existing/deployed approaches)?
In other words, isn't it likely that the real alternatives are:
1) minimal modifications to existing approaches - incurs a long-term cost
associated with having two alternative additional encapsulations
(requiring
interworking and other complexities) until such time (if ever) when the DCN
industry settles on one choice and we move on.
2) create a new encapsulation that meets requirements (that must be over and
above the requirements satisfied by at least the standard components of the
current deployed solutions) - and assume that the industry will switch over
to using this lovely new encapsulation, thus avoiding any issues with
having
multiple additional encapsulation solutions.
3) create a new encapsulation that meets requirements - and find out that the
industry doesn't entirely switch over to the new (read untried and possibly
immature) encapsulation, existing deployed alternatives are documented in
some (possibly non-standard) way and we incur the costs associated with
living with three alternatives additional encapsulations until such time
(if ever)
when the DCN industry settles on fewer (possibly as few as one) choices,
and
we move on.
And this means that the real answer to your question (which
approach
will result in the least pain) depends very much on which of the 2nd and 3rd
alternatives above actually turn out to be the case.
I suspect the answer is not as cut-and-dried as some may think
it is.
If - as your mail suggests - there really is a willingness
among those
who have currently deployed solutions, to switch to a common encapsulation,
it would be very useful if each and every one of them would please tell us so.
--
Eric
From: nvo3 [mailto:[email protected]] On Behalf Of Lucy yong
Sent: Monday, March 10, 2014 12:33 PM
To: [email protected]; [email protected]
Subject: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap
Hi All,
GROSS brings a lot of attentions in this IETF meeting. VXLAN and NVGRE defects
for Network Virtualization Overlay (NVO) technology were extensively discussed
on nvo3 mailing list last year
(http://www.ietf.org/mail-archive/web/nvo3/current/msg02779.html) and the
enhancements on VXLAN and NVGRE for the technology were also proposed in the
draft-yong-l3vpn-nvgre-vxlan-encap-03 and draft-ietf-tsvwg-gre-in-udp-00.
If we look at the geneve proposal, it addresses the defects identified in VXLAN
and NVGRE for NVO and has the essential key elements required by NVO in the
encapsulation header.
Should we enhance VXLAN and NVGRE for NVO technology or create a new
encapsulation protocol for NVO? Industry (or major vendors (authors in gross)
in NVO) seems prefer the latter choice now. The benefit of the latter is that
having one encapsulation protocol for the NVO technology, which is good for
both vendors and operators. The "cons" is that we have a new encapsulation
protocol, which is not compliant with either VXLAN or NVGRE.
So the question is should we quickly face out VXLAN and NVGRE with GENEVE and
have one encap. for NVO or we live with this pain ( enhance both VXLAN and
NVGRE for NVO and use both in NVO). IMHO: Having two encapsulation semantics
for the same technology is not good, the only reason we do it is for the
reality. Is this reality not true anymore by seeing the authors in geneve?
What should IETF do for NVO technology development? With current NVO3 WG
progress pace, it is not much except discussing the technology and solution
pieces on the mailing list. In the meanwhile, IETF keeps receiving these
informational drafts from the industry (precisely, the nvo leader vendors).
Which one will IETF publish as informational?
Does IETF really want working on NVO technology?
Regarding medadata option in geneve header, I'll express my opinion in a
separated mail.
Thanks,
Lucy
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
