On Fri, 29 Jan 2021 22:59:06 -0800 Pravin Shelar wrote:

On Fri, Jan 29, 2021 at 6:08 AM Jonas Bonn [off-list ref] wrote:

quoted

On 28/01/2021 22:29, Pravin Shelar wrote:  

quoted

Receive path: LWT extracts tunnel metadata into tunnel-metadata
struct. This object has 5-tuple info from outer header and tunnel key.
When there is presence of extension header there is no way to store
the info standard tunnel-metadata object. That is when the optional
section of tunnel-metadata comes in the play.
As you can see the packet data from GTP header onwards is still pushed
to the device, so consumers of LWT can look at tunnel-metadata and
make sense of the inner packet that is received on the device.
OVS does exactly the same. When it receives a GTP packet with optional
metadata, it looks at flags and parses the inner packet and extension
header accordingly.  

Ah, ok, I see.  So you are pulling _half_ of the GTP header off the
packet but leaving the optional GTP extension headers in place if they
exist.  So what OVS receives is a packet with metadata indicating
whether or not it begins with these extension headers or whether it
begins with an IP header.

So OVS might need to begin by pulling parts of the packet in order to
get to the inner IP packet.  In that case, why don't you just leave the
_entire_ GTP header in place and let OVS work from that?  The header
contains exactly the data you've copied to the metadata struct PLUS it
has the incoming TEID value that you really should be validating inner
IP against.
 

Following are the reasons for extracting the header and populating metadata.
1. That is the design used by other tunneling protocols
implementations for handling optional headers. We need to have a
consistent model across all tunnel devices for upper layers.

Could you clarify with some examples? This does not match intuition, 
I must be missing something.

2. GTP module is parsing the UDP and GTP header. It would be wasteful
to repeat the same process in upper layers.
3. TIED is part of tunnel metadata, it is already used to validating
inner packets. But TIED is not alone to handle packets with extended
header.

I am fine with processing the entire header in GTP but in case of 'end
marker' there is no data left after pulling entire GTP header. Thats
why I took this path.