On Fri, 29 Jan 2021 22:59:06 -0800 Pravin Shelar wrote: > On Fri, Jan 29, 2021 at 6:08 AM Jonas Bonn <jo...@norrbonn.se> wrote: > > On 28/01/2021 22:29, Pravin Shelar wrote: > > > 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.
