Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path Tracing Midpoint HLD #1456

Merged
merged 3 commits into from
Oct 31, 2023
Merged

Conversation

cscarpitta
Copy link
Contributor

@cscarpitta cscarpitta commented Aug 31, 2023

Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path.

Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline.

Path Tracing enjoys a very rich ecosystem both from Vendor and Open-Source point of view.

Path Tracing is supported across many HW ASIC including Cisco Silicon One, Cisco Light Speed, Broadcom Jericho, Broadcom Jericho2, Marvell and many others.

Path Tracing has also a very opensource ecosystem that includes the Linux Kernel, FD.io VPP, an open P4 implementation, and support in applications such as Wireshark and TCPDump.

The list routing of platforms that have successfully participated in the Path Tracing interop testing are reported in
draft-filsfils-spring-path-tracing.

This PR provides the HLD to support the PT Midpoint in SONiC.

The document that describes the HLD is available here:
https://github.com/cscarpitta/SONiC/blob/srv6_pt_midpoint_hld/doc/path_tracing/path_tracing_midpoint.md

Repo PR title State
sonic-utilities [config, show] Add CLI commands for Path Tracing Midpoint GitHub issue/pull request detail
sonic-swss [orchagent] Add support for Path Tracing Midpoint GitHub issue/pull request detail
sonic-buildimage [sonic-yang-models] Add Path Tracing attributes to SONiC Port YANG model GitHub issue/pull request detail
sonic-mgmt [tests] Add packet level tests for Path tracing Midpoint GitHub issue/pull request detail

Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The existing `config interface` command is extended by introducing a new subcommand `pt` that allows users to configure the Interface ID and Timestamp Template parameters required for the PT Midpoint functionality. The Timestamp Template is optional. The default template is *template3*.

```
admin@sonic:~# config interface pt <interface_name> <pt_interface_id> [pt_timestamp_template]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this enable PT for all the MYSIDs? Do we need to configure the PT instance and specify the list of MYSIDs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any PT enable/disable flag per port?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kperumalbfn Thanks for the comment. This comment has been addressed.

As suggested, we extended the CLI to have an explicit add/del.

The updated CLI is as follows:

  • Disable PT on the interface
    config interface path-tracing del Ethernet8
  • Enable PT on the interface and set its parameters
    config interface path-tracing add Ethernet8 --interface-id 128 --ts-template template2

**Example 1:**

```
admin@sonic:~# config interface pt Ethernet8 128
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of generic 'pt', should we have this as 'srpt' as this is only for SR

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggest to use full name path-tracing

Copy link
Contributor Author

@cscarpitta cscarpitta Oct 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kperumalbfn @lguohan Thanks for the comment. This comment has been addressed.

We used the full name path-tracing instead of the abbreviation pt, as suggested.

admin@sonic:~# config interface pt <interface_name> <pt_interface_id> [pt_timestamp_template]

<interface_name>: interface name
<pt_interface_id>: Path Tracing Interface ID (0-4095)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use path-tracing instead of "pt" keyword?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have explicit add/del option instead of assuming interface-ID is for the delete operation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@venkatmahalingam Many thanks for the comment. This comment has been addressed.

As suggested, we extended the CLI to have an explicit add/del and use the full name path-tracinginstead of pt.

The updated CLI is as follows:

  • Disable PT on the interface
    config interface path-tracing del Ethernet8
  • Enable PT on the interface and set its parameters
    config interface path-tracing add Ethernet8 --interface-id 128 --ts-template template2

@zhangyanzhao
Copy link
Collaborator

To validate PT Midpoint, two test cases are added to the existing `tests/test_port.py` (in the `sonic-swss` repository):

- `test_PortPtDefaultTimestampTemplate` writes a port configuration to the CONFIG_DB (with PT Interface ID non-zero and default PT Timestamp Template) and verifies that APPL_DB and ASIC_DB are updated correctly.
- `test_PortPtTimestampTemplate2` writes a port configuration to the CONFIG_DB (with PT Interface ID non-zero and PT Timestamp Template specified) and verifies that APPL_DB and ASIC_DB are updated correctly.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing packet level test for this HLD. sonic-mgmt tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lguohan Thanks for the comment. We are preparing the packet level tests for this HLD. We will submit them in the next few days.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lguohan I pushed the packet level tests.
Here is the link to the PR: sonic-net/sonic-mgmt#10486


The above command assigns Ethernet9 a Path Tracing Interface ID of 129 and a Timestamp Template template2.

#### CLI Show Commands
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please define the behavior when the underlying sai attribute is not support. we should query from sai and get the capability, put into state db, and cli will check the state db flag first, if not supported, then return error to the user.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lguohan This comment has been addressed.

We updated the orchagent code and HLD, as suggested.


## Open/Action items

The PT Midpoint feature proposed in this document depends on the following PRs:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can SRv6 midpoint pt feature records switchId addition to interface ?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@madhupalu, the Path Tracing midpoint records what is called Midpoint Compressed Data (MCD) [1]. The MCD contains Interface ID, Truncated Timestamp, and Interface Load. The MCD is recorded in the Path Tracing Hop-by-Hop header [2] which is optimzed for this MCD format. The switchId isn't recorded.

[1] https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing-04#name-midpoint-compressed-data
[2] https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing-04#name-ipv6-hop-by-hop-path-tracin

- [orchagent] Add support for SRv6 Path Tracing Midpoint: https://github.com/sonic-net/sonic-swss/pull/2903

## References

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion to add high level packet flow diagram how the SRv6 path-tracing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@madhupalu We added a packet flow diagram to the HLD, as suggested.

**Example 1** - Show PT Midpoint configuration for all interfaces:

```
admin@sonic:~$ show interfaces pt
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have provided CLI to validate SAI capabilities for this feature ?

Copy link

@ahsalam ahsalam Sep 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During the PortsOrch initialization, we query the SAI capabilities for Path Tracing:

  • IF supported, We set PATH_TRACING_CAPABLE = true in the SWITCH_CAPABILITY table of STATE DB
  • Else, We set PATH_TRACING_CAPABLE = false in the SWITCH_CAPABILITY table of STATE DB

When the user tries to configure Path Tracing Interface ID using the SONiC CL, We check PATH_TRACING_CAPABLE in the SWITCH_CAPABILITY table of STATE DB

  • IF PATH_TRACING_CAPABLE = TRUE, We config Path Tracing Interface ID and Timestamp Template in CONFIG DB
  • Else, we return an error

Ethernet9 fortyGigE0/0/9 up up 129 template2
```

**Example 2** - Show PT Midpoint configuration for interface Ethernet8:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CLI improvements -
pt recording happens at the egress interface. - config interface path-tracing egress <interface_name> <pt_id> --template template2

Copy link

@ahsalam ahsalam Sep 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are extending the CLI based on the feedback we got during the call to address the following:

  • have an explicit add/del
  • use path-tracing instead of pt

The updated CLI will be as follows

  • Disable PT on the interface
    Config interface path-tracing del Ethernet8
  • Enable PT on the interface and set its parameters
    Config interface path-tracing add Ethernet8 –interface-id 128 –ts-template template2

Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Changes requested by SONiC community

Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Copy link

@reshmaintel reshmaintel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. In the example section of this document, would it be possible to add 1-2 lines on how the Timestamp Template is used in the overall solution (in the PT Sink node). Also the reason why there are overlapping bits in each Timestamp Template ? And lastly info on why the Template 3 is chosen as default.

@ahsalam
Copy link

ahsalam commented Oct 11, 2023

Thank you. In the example section of this document, would it be possible to add 1-2 lines on how the Timestamp Template is used in the overall solution (in the PT Sink node). Also the reason why there are overlapping bits in each Timestamp Template ? And lastly info on why the Template 3 is chosen as default.

Hi Reshma, Each port in the device is configured with a timestamp template. The timestamp template defines the position of 8-bits to be selected from the timestamp.
The SAI header currently supports for the timestamp templates. Each template provides a certain time precision.
Template1 timestmap[08:15] Precision = 0,000256 ms
Template2 timestmap[12:19] Precision = 0,004096 ms
Template3 timestmap[16:23] Precision = 0,065536 ms
Template4 timestmap[20:27] precision = 1,048576 ms

Template3 is the default. This is inherited from the SAI header. We agreed to use template3 as the default in SAI as it provides a latency precision that can be good for many use-cases. However, you can always override the default template. Also in the future more timestamp templates can be added to the SAI header and according inherited in SONiC.

@cscarpitta cscarpitta changed the title SRv6 Path Tracing Midpoint HLD Path Tracing Midpoint HLD Oct 12, 2023
@ahsalam
Copy link

ahsalam commented Oct 14, 2023

@zhangyanzhao could you please have a look at this PR ?
@cscarpitta addressed the comments and it is ready for merge

@ahsalam
Copy link

ahsalam commented Oct 30, 2023

Hi @zhangyanzhao @kperumalbfn @lguohan

All the comments of this PR has been addressed and has been approved by two reviewers. Could we merge the PR ?

@lguohan lguohan merged commit c2022f4 into sonic-net:master Oct 31, 2023
1 check passed
prsunny pushed a commit to sonic-net/sonic-swss that referenced this pull request May 24, 2024
* [orchagent]: Add support for SRv6 Path Tracing Midpoint
What I did
Extended PortsOrch to process the attributes required for Path Tracing.

Why I did it
This PR is required for the SRv6 Path Tracing Midpoint feature.
HLD: sonic-net/SONiC#1456
@zhangyanzhao
Copy link
Collaborator

code PRs are still open, move to backlog for future release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: MovedToBacklog
Development

Successfully merging this pull request may close these issues.

8 participants