Re: [nvo3] Extensions in nvo3 encapsulations

[Patrick Frejborg <[e-mail]>]

Hi Tom,

thinking out of the box - what will break if you slightly change the
order in which the packets are processed at the VTEP/PE/NVE?
>From the VM perspective, you insert a new L2 module before the packets
are sent down to the virtual circuit. In this module you have e.g.
MACSec for encryption, MEF modules for OAM functions, perhaps add some
new mechanisms for fragmenting on L2 level , have some kind of Path
MTU discovery mechanism etc. Depending on you performance requirements
and amount of tunnels that need these extended features you could run
this undefined module as VM or when high performance is required then
have it deployed in DPDK or if hardware appliance exists insert them
to your hosting device. With service chaining you can direct these
extended services to appropriate tunnels regardless what kind of L3
tunnels are deployed between the VTEPs/PEs/NVEs peers as long as the
remote peer supports this undefined module. If VNID is needed on the
tunnel itself between the NVE peers, then chose a tunnel protocol that
supports that, if not then go for the tunnel with the smallest
overhead, Ethernet over UDP(?) and so on.

Regards,
Patrick

On Fri, Aug 19, 2016 at 2:24 AM, Tom Herbert <[e-mail]> wrote:
> Alia has asked that we provide some more information as to what the
> motivations for extensions are for nvo3 and to what form they should
> take. Here is some high level explanation with respect to GUE.
>
> Six fundamental extensions have been defined for GUE
>
> 1) VNID (draft-hy-nvo3-gue-4-nvo-03)
> 2) Checksum (draft-herbert-gue-extensions-00)
> 3) Remote checksum offload or RCO  (draft-herbert-gue-extensions-00)
> 4) Fragmentation (draft-herbert-gue-extensions-00)
> 5) Security (draft-herbert-gue-extensions-00)
> 6) Payload transform (draft-herbert-gue-extensions-00)
>
> All of these share some common properties:
>
> * The extensions seem cover three areas: integrity/security,
> addressing, and protocol processing.
> * These extensions break down into two classes: those that can be
> processed without any additional information (checksum, RCO,
> fragmentation), and those that require context (VNID, security,
> payload xfrm)..
> * These are all intrinsic to the encapsulation layer and are part of
> correct processing of the encapsulation when present. For instance the
> security option is expressly needed to secure the GUE header and in
> particular to provide security for VNID.
> * All of these are mandatory in the sense that they can't be ignored
> at a receiver. For instance, if some receiver decided to ignore RCO
> then that would just become a checksum error at the ultimate receiver.
> Anything to do with security can pretty much never be ignored. Also,
> as a general principle in large scale DCs, it's much better to drop a
> packet when we're not sure something is correct as opposed to allowing
> it through even if the risk is slight. Packet loss is much easier to
> debug than incorrectness!
> * With the exception of fragmentation, a subset of these will commonly
> be set in packets for some deployment. For instance in a nvo3
> deployment, VNID and security might be set all the time.
> * These are not intended for processing by middleboxes in transit. As
> I mentioned in my response to Bob Briscoe, intermediate devices cannot
> correctly parse UDP payloads (port number ambiguity problem in the
> network). Such information should be in HBH for IPv6 or IP options in
> IPv4.
> * These are interoperable and not proprietary.We allow proprietary
> extensions via a private data field but do do not encourage it, to do
> so otherwise would be to encourage vendor lock-in.
>
> While these six fundamental cover current needs, we cannot predict
> that they cover all the future needs of the protocol. At some point we
> will need to extend a deployed encapsulation protocol in the data
> center. The most likely scenario that we would need to extend the
> protocol is to addressed a newly discovered security vulnerability. We
> anticipate that extending a protocol is a rare event, but at large
> scale we need this capability. Extending a protocol is far simpler
> that replacing a protocol especially if we can avoid needing to swap
> out massive amounts of hardware.
>
> Another general characteristic is that GUE extensions are contained
> within a single header, as opposed to using shim headers or following
> headers. There are benefits to do this:
>
> * It's very clear that the extensions refer to the encapsulation. For
> instance if implement a checksum in a shim header then we need some
> consideration as to how the checksum covers prior headers.
> * We can limit the extensibility. This is important consideration for
> efficiency and avoid DOS attacks.
> * This allows "skip ahead". If a device just wants to look at the
> encapsulated IP packet for instance it does not need to parse a header
> chain for that.
>
> Thanks,
> Tom
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3