nvgre parsing

[budgrise]

Nvgre output was added by PR #308 Add ST route type.
Is there also a requirement for parsing incoming nvgre packets?

[KrisNey-MSFT]

No support for packets coming to the pipeline, they can only go out.
No use for it right now (no implementation for nvgre on ingress), but may be in the future, and we would need to add the code.
Assumption is that 2 DASH devices would not communicate using nvgre.
ST is a tunnel towards a public IP (on the Internet). Do packets return on nvgre? Ask @prsunny

[KrisNey-MSFT]

Reminder of this question @prsunny or @r12f or @kperumalbfn

ST is a tunnel towards a public IP (on the Internet). Do packets return on nvgre?

[KrisNey-MSFT]

Added @pranjal-git in case he may know

[r12f]

Hi @budgrise, on high level, the packet transformation will still follow this doc: https://github.com/sonic-net/DASH/blob/main/documentation/general/sdn-pipeline-basic-elements.md#service-tunneling, and I am sure you are already aware of it:

In my understanding, the return packet will rely on reverse flow to do the transformation:

• The return packet will have 2 layers of encaps, which will be all decap'ed before sending to the pipeline. However, this is not modeled today in DASH and our BM, but this is what should be happening.
• After decap, the flow matching will only use the 5 tuples from the inner most packet. This will find the reverse flow and apply the transformations.

[r12f]

Hi Bud, I have updated the proposal for making this behavior clarified as well as addressing certain future cases. Please feel free to take a look and let me know what you think: https://github.com/r12f/DASH/blob/user/r12f/pipeline/documentation/general/dash-sai-pipeline-packet-flow.md#54-packet-decap.

The PR can also be found here: #449. Feel free to leave me comments as well! :D

[KrisNey-MSFT]

Closing in favor of PR449 per Community Call