On 8/3/16 4:34 PM, Tom Herbert wrote:
On Wed, Aug 3, 2016 at 3:54 PM, Fabio Maino <fma...@cisco.com> wrote:
On 8/3/16 3:38 PM, Tom Herbert wrote:
On Wed, Aug 3, 2016 at 2:26 PM, Fabio Maino <fma...@cisco.com> wrote:
On 8/1/16 4:21 PM, Alia Atlas wrote:
On Mon, Aug 1, 2016 at 6:35 PM, Tom Herbert <t...@herbertland.com> wrote:
On Mon, Aug 1, 2016 at 2:59 PM, Fabio Maino <fma...@cisco.com> wrote:
On 7/29/16 6:38 PM, Jesse Gross wrote:
On Jul 29, 2016, at 4:39 PM, Fabio Maino <fma...@cisco.com> wrote:
On 7/29/16 12:44 PM, Jesse Gross wrote:
On Jul 29, 2016, at 12:17 PM, Fabio Maino <fma...@cisco.com> wrote:
On 7/29/16 11:45 AM, Tom Herbert wrote:
On Jul 29, 2016 11:12 AM, "Fabio Maino" <fma...@cisco.com> wrote:
On 7/27/16 1:43 PM, Tom Herbert wrote:
On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino <fma...@cisco.com>
wrote:
On 7/27/16 12:27 PM, Tom Herbert wrote:
On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino
<fma...@cisco.com>
wrote:
On 7/27/16 10:53 AM, Tom Herbert wrote:
On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci
<farina...@gmail.com>
wrote:
On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino)
<fma...@cisco.com>
wrote:
On 7/26/16 12:08 PM, Dino Farinacci wrote:
Having VXLAN as an Independent Stream RFC gives a
document
to be
used
to
innovate from. I believe that was the intent of
VXLAN-GPE
- to
provide the ability
for needed extensions.
The only new feature the VXLAN-GPE brings to the table
is
a
way to
identify that NSH is being encapsulated.
or any other shim header, NSH just happens to be one.
Precisely. GPE addresses the limitation associated with
VXLAN, namely
the lack of multi-protocol support. As we've seen on the
list, other
protocols have come up: MPLS for example.
This is technically not true. As long as you are willing to
spend 14
bytes on a MAC header, then anything with an ethertype can
be
encapsulated
with VXLAN.
And I have working code that encapsulates both IPv4 and
IPv6
in
VXLAN
with ethertypes 0x0800 and 0x86dd, respectively.
There are some other technical benefits as well: version
and
OAM.
As do Geneve and GUE. But this thread is not about touting
the
features of these protocols, it is about the technical
objections to
them. My major objections (from the list I posted) to
VXLAN-GPE
is
that it has no extensibility and offers no security of the
VNI.
These
are showstoppers in my deployment.
Tom,
extensibility is achieved via shim header:
- if you want to carry end to end metadata you can define the
appropriate
shim header
- If you want to protect the integrity of the VNI, you can
include an
HMAC
of the VNI in the shim header
Please point me to the specification where this shim header
with
the
HMAC is described and add a reference to it in the security
considerations section of the VXLAN-GPE draft.
Hi Tom,
there are a lot of use cases that can be addressed with shim
headers, and
each solution may look fairly different depending on the
requirements.
The security option including the specific header format is
described
in draft-herbert-gue-extensions. You can use the same data
format.
Can you point me to an nvo3 specification of what are the
requirements that
need to be addressed to provide VNI integrity protection? If
the
requirements are the same you used for GUE, the shim header
could
use an
encoding similar to the GUE security option.
Section 6.2 of draft-ietf-nvo3-security-requirements describes
the
dataplane requirements. The most important requirement of nvo3
is
to
maintain strict isolation between tenant virtual networks. The
problem
is exacerbated in UDP encapsulation since any non privileged
application can send a UDP packet to any port thereby making it
easier
to inject packets into a virtual network than in a non-UDP based
encap
protocol like nvgre. In our large scale network we need strong
mechanisms to guarantee this isolation; Ethernet CRC and network
mechanisms like firewalls or address spoofing are not sufficient
for
multi-tenant nv security.
Tom,
I went back and re-read the draft. Requirement 10, that is the
one
that seems relevant here, is not a MUST. From that standpoint
VXLAN-GPE does
comply with that draft.
I don't want to argue that there are use cases where
authenticaton
of
the VNI might be useful, but certainly there are others where it
isn't.
Otherwise the WG would have settled for a MUST there.
In the design of VXLAN-GPE we have choosen to not burden the cost
of
ALL the implementations with a mandatory authentication field.
However,
thanks to VXLAN-GPE flexibility and extensibility, this function
can be
added via shim header.
Lacking the requirement document, I'm sure we can add a
paragraph
in the
security section that describes how it can be done.
Please be specific in that. If you just say "use NSH" that is
not
helpful at all to your potential implementors or users. If we
were
to
implement security we need to know the exact bits that are set
in
the
packet.
Tom
That should not go in the VXLAN-GPE draft. All that draft needs
to
specify is that there might be a following shim header. The
VXLAN-GPE draft
does that today.
if I read your comment right, you seem to agree that it can be
done.
Is this your MAJOR objection to VXLAN-GPE? If we were to specify
such a
draft, would that change your opinion in supporting VXLAN-GPE for
WG
adoption?
My major objections are lack of security and extensibility. The
counter argument seems to be use a shim header for security or
extensions,
but there has never be any specifics offered (I have asked several
times now
how to implement a 64 bit security cookie in VXLAN-GPE). Also the
security
considerations section in the draft provides no useful guidance.
In my data center if we are going to commit to using a protocol
for
the long term (like if we buy into HW support), I need to believe
it is
adaptable to face changing security risks and new technologies. I
know how
to extend GUE and in fact we have useful extensions defined. I
believe I
would know how to extend Geneve, although I still wish there were
some
standard TLVs spec'ed. However, I don't know how extend VXLAN-GPE.
I can't
afford to find out two years from now that I need switch protocols
because
we can't adapt the running protocol. This is particularly true in
data
center security, the demands for strong security mechanisms will
only be
increasing-- I need a protocol that can deal with that...
This is all just my opinion of course :-)
I think that the point at hand here is that the AD is pushing the
WG
to
have a discussion on which encapsulations should be selected for
standard
track. What should guide that decision are the requirements
emerging
from
the set of documents that are adopted by the WG.
As I said in the previous message, IMO VXLAN-GPE does address the
security requirements as expressed in
draft-ietf-nvo3-security-requirements.
I note that you have not objected to that point.
Also, I pointed to NSH as ONE example of how VXLAN-GPE can be
extended
using a shim header. NSH implements SFC and metadata transport.
Looking at
what NSH + VXLAN-GPE achieves, it makes fairly hard to maintain
that
VXLAN-GPE is not extensible. Extensibility is achieved via
layering.
It
might not be the same way extensibility is achieved by the other
contenders,
but it's a fairly established way to design protocols.
I think this should answer the objections to security and
extensibility
for the purpose of the selection of an nvo3 encapsulation.
The issue with shim headers is that introducing a new one breaks the
ability of existing implementations to parse the packet. There are a
lot of
use cases where just being able to get to the packet data is hugely
useful -
a NIC steering incoming frames to a VM shouldn’t need to be modified
for
every use case. Even simple examples like tcpdump/Wireshark benefit
from
this - it’s really useful to be able to generally get a look at a
packet
even if it doesn’t understand everything. With both Geneve and GUE
this is
possible but not with the design that you are describing with
VXLAN-GPE.
That approach forces your customers to pay upfront for the cost of
buffering metadata that their devices don't know how to handle,
and/or
they
may never use. To implement a new feature, you'll need buffers AND
logic.
Even if you allocate buffer in advance (before the feature is
specified),
you'll have to spin a new version of the HW to add the logic that
addresses
that new feature.
In this sense VXLAN-GPE allows an implementor to be sensible in
allocating resources, by using only the buffer space that is actually
needed
by that specific implementation.
I suspect that the result of the pressure of cost on implementations
will
be such that, some HW implementations of Geneve, may implement only
the
basic functions, restricting to very few, if any, support for
variable
length options. Packets with unknown options will be eventually
punted
to
the slow path, and vendors will claim support for the protocol.
This is not very different from how an unknown shim header will be
handled. Flexibility and HW implementations might be a bit of a
unicorn…
I think that you are making some specific assumptions about the types
of
implementations here. In particular, you are assuming that the only
device
class is a fixed-function switching ASIC. The comments don’t really
apply to
software, NICs, or even the more programmable switching ASICs that are
starting to come out.
In that specific situation, I agree that it doesn’t make sense to
include
elements of an implementation that can’t be usefully deployed.
However,
in
cases where the device would need to be respun to include new logic, I
doubt
that anyone would prematurely include vestigal pieces that would drive
up
the cost. They would simply implement the support as necessary and the
cost
would reflect what the device is capable of doing. This is similar to
VXLAN-GPE in that regard.
However, I don’t believe that networks consist exclusively of fixed
switching ASICs. As I mentioned before, there are many other
components
that
can take advantage of extensibility. I don’t see that it is necessary
to
deny them those benefits even if some devices may need to be
incrementally
respun.
This diverse base of implementation platforms is, IMO, what makes hard
to
select a single encap for the nvo3 use case. A feature of the protocol
that
might be a benefit for one platform, introduces significant
costs/disadvantages when deployed in another one.
Can you give a specific example of a feature that demonstrates this?
With regards to extensibility I am not seeing why using NSH has lower
costs or fewer disadvantages to deploy compared to flag-fields in GUE
or even TLVs in Geneve...
[Alia] Do recall that the question is around significant technical
concerns
that
must be addressed. It isn't whether one approach is "better" or
"easier"
for a
particular deployment scenario as compared to another.
The major concern comes from selecting a single MUST implement
encapsulation
that has the option to include hundreds of bytes of unstructured,
variable
length metadata. Such a feature is fairly unfriendly to implement in
fixed
switching ASICs.
This is where I think there is confusion on the "HW implementability"
arguments that are being made. VXLAN-GPE is a fixed length header and
that is perfectly amenable to switching ASICs-- but so is GUE and
Geneve without any options present (they all resolve to a simple fixed
length 8 byte headers that can no doubt be implemented in switching
ASICs with equal ease). But, if you take into account processing
options for extensibility which would be TLVs in Geneve, flag-fields
in GUE, and NSH with VXLAN-GPE as you suggested-- then GUE is the most
friendly to HW (parsing is amenable to implement by TCAM for
instance), and Geneve is likely easier to process since TLVs in one
protocol header is more straightforward for processing a header chain
(e.g. IP options vs. ext. hdrs. experience).
The amount of buffering required, and the number and ordering of options
makes a difference as well. TCAM adds to the cost and is a resource
contended by other functions in the ASIC. Given that the HW needs to be
re-spun anyway to process new features the flexibility of the protocol
itself doesn't make much of a difference.
Fabio,
Sorry if it seems like I'm being contentious, but I really would like
to understand the what your concerns are. Your statement was
"Considerations on implementability of an approach is, in my opinion,
a very significant technical concern in selecting a standard.". Yes I
agree, infeasibility in implementation would be a valid technical
objection. But as Matthew as stated in the original email thread
"Please be as concrete and detailed as possible as to your technical
objection.". I would infer that you're objecting that to Geneve and
GUE because they are less implementable in HW than VXLAN-GPE. If that
is indeed your technical objection to those protocols, can you provide
a concrete and detailed explanation why you consider VXLAN-GPE to be
more implementable in HW?
Tom,
it's more than just infeasibility that should be considered as part of
the technical evaluation, but also the cost/complexity associated with
implementations.
Encapsulations are not implemented in a vacuum, but compete with other
features for resources available in a given platform. VXLAN-GPE was
designed to be a superset of VXLAN. VXLAN happens to exist as a legacy
encapsulation and will likely be around for quite some time. An
implementation of VXLAN-GPE makes a more efficient use of resources on
platforms that need also to support VXLAN (that to my knowledge are a
very significant chunk of the implementations out there). This is
particularly true for fixed-functions ASICs, but I think it stands true
for other platforms as well when you consider the cost/complexity of
verification and testing.
Then there's the cost/complexity associated with the transport of
metadata. I think that a parser for a fixed length portion of a header
with an ordered set of metadata can be implemented with less
cost/complexity than a parser for a variable length header where
metadata can appear in any order. This is particularly evident in
fixed-function ASICs. IMO, a mandatory to implement encapsulation,
shouldn't force implementations to deal with variable length unordered
sets of metadata.
To me those are two important technical aspects to consider, if we have
to select a single encapsulation mandatory to implement.
Fabio
Thanks,
Tom
Fabio
Tom
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
