DASH pipeline packet flow update proposal.

[r12f]

Motivation

DASH pipeline packet flow is the core for data path modeling, and today, it provides a good starting point for modeling VNET traffic. However, certain behaviors of DASH pipeline is not well defined or not being flexible enough.

For example:

• Only certain VM related scenarios are supported.
  • Inbound pipeline is not fully modeled.
  • Things like load balancer will require large change to today's pipeline, e.g. PR 348: [NAT HLD] Nat hld #348.
• Routing types being the minimum building block makes it hard to add any new scenarios, because we have to change our behavior model for every new scenarios. This is not scalable for everyone that involved in DASH - both users or vendor implementations. E.g.:
  • PR 327: Add Private Link mapping #327
  • PR 273: [hld]: Support for multiple routing type actions #273
• Certain routing actions behaves differently under different routing types.
  • “staticencap” uses “underlay_ip” from ENI in regular scenario, while “pl_underlay_ip” in PL scenario.
  • “4to6” action uses pl_sip_encoding field from ENI to encode the overlay_sip, while in ST, it uses only overlay_sip.
• DASH object contains fields from Microsoft only scenarios, such as private link.

And this PR is to:

• Provide the doc to have the packet flow more well defined to address the unclear part of the pipeline.
  • nvgre parsing #406
  • Clarification on Service Tunnel Inbound Processing #428
  • Ensure we can decap double-encapsulated packets - Add to DASH HLD Section 2.3 #386
  • Add per ENI DSCP setting #448
  • NVGRE or VxLAN or both #117
• Propose some extension to today's DASH pipeline to make it more flexiable, so more scenarios can be onboarded without changing the underneath behavior model.

Change summary

This proposal is not indented to redesign the SAI API and DASH packet flow today, but mostly focusing on a few extensions in today's DASH model.

• Exposing routing type table and make routing actions as the new building block.
  • To transit to the model, we could have them both co-exist side by side, sharing the same name. Until we are ready to switched over.
• Simplify the pipeline as entry matching and metadata publishing and removing majority of the special logics for any routing actions.
• Adding port mapping stage to the existing pipeline and model the inbound pipeline the same way as outbound.

[KrisNey-MSFT]

I made a few suggestions

[KrisNey-MSFT]

Did a bit more...will finish later

[KrisNey-MSFT]

Last of my potential edits

[KrisNey-MSFT]

[like] Kristina Moore reacted to your message:

________________________________ From: Riff ***@***.***> Sent: Friday, November 3, 2023 7:13:20 PM To: sonic-net/DASH ***@***.***> Cc: Kristina Moore ***@***.***>; Comment ***@***.***> Subject: Re: [sonic-net/DASH] DASH pipeline packet flow update proposal. (PR #449) @r12f commented on this pull request.

________________________________ In documentation/general/dash-sai-pipeline-packet-flow.md<#449 (comment)>:

+| IP Mapping | Exact Match | Source IP or Destination IP | Publish metadata from matched VNET and VNET mapping entry |

+| Port Mapping | Range Match | Source Port + Destination Port | Publish metadata from matched port mapping entry | + +For more on the metadata publishing, please refer to the metadata publishing section below. + +#### 5.9.2. Pipeline profile and stage connections + +Ideally, when DASH initializes or whenever we create a new pipeline, by simply creating multiple numbers of different types of matching stages and connecting them in different ways, we can easily implement different pipeline and network functions. + +| Stage 0 | Stage 1 | Stage 2 | Stage 3 | Stage 4 | +| ------- | ------- | ------- | ------- | ------- | +| Routing 0 | IP Mapping 0 | Port Mapping | X | X | +| Routing 0 | Routing 1 | IP Mapping 0 | IP Mapping 1 | Port Mapping | +| Routing 0 | IP Mapping 0 | Port Mapping | Routing 1 | IP Mapping 1 | + +However, in reality, it might make the pipeline hard to implement, model, debug and validate or test at this moment. For example, changing matching fields, matching type and connection dynamically on pipeline creation is simply beyond the ability of P4, which is used by our behavior model today as well as many vendor's ASIC SDKs. p4 annotations will help generating the sai headers, but sadly, it won't be able to help much in this case. :( — Reply to this email directly, view it on GitHub<#449 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFJSI6DTD5FVGBOUDG5J5GTYCU65BAVCNFSM6AAAAAA5U5YA32VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTOMJTGM4DONJSGQ>. You are receiving this because you commented.Message ID: ***@***.***>

[KrisNey-MSFT]

approving