> 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.
>
Fabio,
GUE is based on GRE which is one of the world's most mature and
deployed encapsulation protocols. GRE is the only protocol we've found
with variable length headers that is commonly processed by both switch
and NIC hardware. We would have used GRE for our deployment but its
extensibility is too limited.
> 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.
>
Options in GUE are will ordered, it does not have the combinatoric
complexity associated with TLVs. draft-herbert-gue-extensions shows
the GUE header with all the currently proposed fundament encapsulation
options:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| Source port | Destination port | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
| Length | Checksum | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
|Ver|C| Hlen | Proto/ctype |V|SEC|K|F|T|R| Rsvd Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VNID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Fragmentation (optional) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload transform (optional |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote checksum offload (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Private fields (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that for any combination of options (indicated by set flags)
there is only _one_ possible ordering. So the total number of possible
unique packet formats is 2^N where N is number of option bits. The
number variants of the GUE header is thus 128. To contrast, if these
options were in TLVs the number of possible orderings of the TLVs is
greater than 10,000-- this is the combinatoric nature of TLVs. 128
combinations is small enough that it is feasible to implementing
option parsing with parallel HW techniques (like a TCAM as an
example).
Another important field in the GUE header is Hlen. This provides two
important features:
1) It puts a hard limit on the amount of header that can be used for
options. This is important because a lot of HW implementation can only
load the first N bytes of a packet into their cache for parsing. The
limit also presents the possibility of DOS attack where an attacker
fills up a whole packet with dummy headers like can happen with IPv6
extension headers.
2) The Hlen provides a means for middleboxes to skip over the options
so that it can parse the payload. This means that middleboxes don't
need to understand or parse each option in order to just to DPI on the
payload.
SW implementation is also an important consideration. GUE extensions
are processed without needing a loop and the structure allows random
access. The latter is important if we have to go fishing for specific
options that are needed to processed before others (such as security).
In contrast TLVs and header chains inevitably will require a loop. If
some TLV must be processed early, this in fact may require multiple
passes over the TLVs.
> To me those are two important technical aspects to consider, if we have to
> select a single encapsulation mandatory to implement.
>
As demonstrated, those aspects are well considered in GUE.
Tom
> 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
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
