Clarification on Service Tunnel Inbound Processing

[budgrise]

The HLD describes service tunnel inbound processing:
https://github.com/sonic-net/DASH/blob/main/documentation/general/dash-sonic-hld.md

I have a few questions on the requirements.

In Section 2.3 "Service Tunnel (ST) and Private Link (PL) packet processing pipelines":
The text says: "ST/PL Inbound flow: Using the outbound unified flow, the reverse transposition (inbound unified flow) is created."

It was not clear to me what this is stating. Is it:
A) The outbound packet makes its way to the remote VM, and then the packet returned from the VM has its innermost SIP/DIP swapped.
B) Or, during processing of the outbound packet, the appliance creates a flow table entry for the reverse flow. And since the incoming outbound packet's innermost header is IPv4, and the incoming inbound packet's innermost header is IPv6, outbound processing creates two flow table entries?

• an IPv4 entry for matching on subsequent outbound packets
• an IPv6 entry for the inbound packets

In Section 3.6.2 "Service Tunnel":

1. I believe the description says the packet sent to the appliance is double-tunneled, is this correct?
   e.g. the header stack looks like:
   ETH IPV4 NVGRE ETH IPV4 NVGRE ETH IPV6 TCP

2a) h.4 says "Appliance shall first decapsulate the outer header and map it to a flow."
Does this mean decapsulate the first outer header or both the outer and middle headers?

2b) The flow table keys include IP addresses and L4 ports. What header fields from this stack are used for the flow table lookup?

[budgrise]

@prsunny you might be the best to answer these.

[KrisNey-MSFT]

pinged @prsunny re: this after Community Call 8/30/2023

[KrisNey-MSFT]

Inbound should create 2 flow entries, 1 IPv4 and 1 IPv6
How to handle double encap (2 headers) before the flow lookup - what is the logic?
Someone @budgrise - would you want to create a 'comment' or suggestion in the document location in SDN Pipeline Basic Elemenst or in SONiC HLD? If N, I can get to it :)

PrivateLinkTransforms - created 433

SONiC DASH HLD - created 434

[KrisNey-MSFT]

Close the PRs, create Issues instead

[r12f]

yes, in the ST case, the outbound packet will evaluates the DASH policies and eventually create 2 flows:

• Outbound direction forwarding flow: IPv4 flow, matching the IPs from the outbound side innermost IPv4 packet
• Inbound direction reverse flow: IPv6 flow, matching the IPs that is encoded by ST packet transformation and also reversed (dst ip = encoded IPv6 source IP, src ip = encoded IPv6 dst ip)

Detailed transformation can be found in the doc that KrisNey-MSFT shared above.

[KrisNey-MSFT]

@r12f , @prsunny , and @kperumalbfn - for the other questions in this Issue, do I need to create separate Issues? Or can we use this one? We were going to answer these and update the documentation...

In Section 3.6.2 "Service Tunnel":

Question:
I believe the description says the packet sent to the appliance is double-tunneled, is this correct?
e.g. the header stack looks like:
ETH IPV4 NVGRE ETH IPV4 NVGRE ETH IPV6 TCP

Question:
2a) h.4 says "Appliance shall first decapsulate the outer header and map it to a flow."
Does this mean decapsulate the first outer header or both the outer and middle headers?

Question:
2b) The flow table keys include IP addresses and L4 ports. What header fields from this stack are used for the flow table lookup?

[r12f]

Hi Kristina, it doesn't matter I guess, let's continue to use this issue : D.

And Hi Bud @budgrise , for the questions:

1. The detailed packet format can be found here: https://github.com/sonic-net/DASH/blob/main/documentation/general/sdn-pipeline-basic-elements.md#service-tunneling.
2. For 2a and 2b, they are both related to packet decap and flow matching, which is not clearly defined by any doc. This is the thing I am trying to address with this PR: DASH pipeline packet flow update proposal. #449. Please feel free to take a look and leave comments to me!

[KrisNey-MSFT]

Closing in favor of PR449 per Community Call