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

New feature: Support SONiC VOQ in a disaggregated networks #17547

Open
VenkatCisco opened this issue Dec 18, 2023 · 5 comments
Open

New feature: Support SONiC VOQ in a disaggregated networks #17547

VenkatCisco opened this issue Dec 18, 2023 · 5 comments
Labels
Triaged this issue has been triaged

Comments

@VenkatCisco
Copy link
Contributor

VenkatCisco commented Dec 18, 2023

Description

Steps to reproduce the issue:

Describe the results you received:

Describe the results you expected:

Output of show version:

(paste your output here)

Output of show techsupport:

(paste your output here or download and attach the file here )

Additional information you deem important (e.g. issue happens only occasionally):

@VenkatCisco
Copy link
Contributor Author

Currently, SONiC VOQ forwarding in a distributed system consist of set of SONiC devices that are connected by internal fabric. The new design proposal extends SONiC VOQ forwarding to work in a disaggregated network.
Packet forwarding in the disaggregated network exhibits the following behavior:

  • Each SONiC instance is either configured as ‘voq’ or ‘fabric’ switch.
  • VOQ switch supports network interfaces (such as front panel ports), logical interfaces (such as LAGs) and fabric interfaces.
  • Fabric switch supports fabric interfaces and provides optical interconnect for multiple VOQ switches. Fabric switch does not support network interfaces.
  • Packet enters one of the network interfaces on the VOQ switch and exits through another network interface either on the same switch or through another switch, transiting across the fabric device.
  • A typical example of a disaggregated network is of that of a CLOS architecture.
    This PR tracks high level design for VOQ forwarding in a disaggregated system.
  • Scope: The ‘Chassis DB’ runs on each VOQ switch and is locally scoped. This means that orchagents running on remote SONiC devices will not have access to the local ‘Chassis DB’.
  • Initialization: The ‘Chassis DB’ is spawned by default at the time of switch bring-up. As such there is no chassisdb.conf dependency for a VOQ switch operating in a disaggregated network.
  • DB Updates: In the distributed system, the remote neighbor information is updated in the CHASSIS_APP_DB by the remote orchagent. In a disaggregated network, the remote neighbors are updated by the local orchagent. The method of learning ‘remote neighbors will remain out-of-scope of this design.
  • Organization: The initial phase of ‘Chassis DB’ deployment in the disaggregated network will mimic the format and structure employed in distributed system.
  • Management: The IP and mac-address of all the remote in-band recycle ports are generated on the local SONiC instance. The remote neighbors are learned through the north bound applications. The management of the network ports, system-ports and fabric ports remain similar as the distributed system.
    Extensions:
    The database behavior (i.e. global scope) and terminology (i.e. ‘chassis’) implemented in the distributed system, does not align with disaggregated networks. An appropriate convention representing the DB will be: ‘System DB’ or ‘Clos DB’ etc.
    The chassis DB runs in a separate Redis instance. This makes sense in the case of a distributed network when the database-chassis is a shared DB across multiple FSI’s. With SONiC running in a disaggregated network, there is an opportunity to consolidate the DB into single Redis instance.

Not in the scope:

  • There are multiple ways of ‘learning’ the remote neighbors on the local SONiC device. While the HLD briefly identifies couple of methods, the implementation is not in the scope of the HLD.

@VenkatCisco VenkatCisco reopened this Dec 18, 2023
@prabhataravind
Copy link
Contributor

@zhangyanzhao Do we create sonic-buildimage issues for new feature requests? Not sure how to handle this request. Could you please advise?

@prabhataravind prabhataravind added the Triaged this issue has been triaged label Dec 20, 2023
@rlhui
Copy link
Contributor

rlhui commented Dec 20, 2023

@VenkatCisco - great to see this! Let us move the reviews/discussions of this to the chassis workgroup? https://groups.google.com/g/sonic-chassis-subgroup

@zhangyanzhao zhangyanzhao moved this to 🏗 In Progress in SONiC 202405 Release Jan 1, 2024
@zhangyanzhao zhangyanzhao moved this from 🏗 In Progress to 📋 In Plan Features in SONiC 202405 Release Jan 1, 2024
@zhangyanzhao zhangyanzhao moved this from 📋 In Plan Features to MovedToBacklog in SONiC 202405 Release May 5, 2024
@zhangyanzhao
Copy link
Collaborator

HLD is not ready yet, move to backlog.

@VenkatCisco
Copy link
Contributor Author

VenkatCisco commented May 7, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Triaged this issue has been triaged
Projects
Status: MovedToBacklog
Development

No branches or pull requests

4 participants