This section describes the scope of this high-level design document in SONiC.
This section covers the abbreviation if any, used in this high-level design document and its definitions.
The purpose of this section is to give an overview of high-level design document and its architecture implementation in SONiC.
This section list out all the requirements for the HLD coverage and exemptions (not supported) if any for this design.
This section covers the changes that are required in the SONiC architecture. In general, it is expected that the current architecture is not changed. This section should explain how the new feature/enhancement (module/sub-module) fits in the existing architecture.
If this feature is a SONiC Application Extension mention which changes (if any) needed in the Application Extension infrastructure to support new feature.
This section covers the high level design of the feature/enhancement. This section covers the following points in detail.
- Is it a built-in SONiC feature or a SONiC Application Extension?
- What are the modules and sub-modules that are modified for this design?
- What are the repositories that would be changed?
- Module/sub-module interfaces and dependencies.
- SWSS and Syncd changes in detail
- DB and Schema changes (APP_DB, ASIC_DB, COUNTERS_DB, LOGLEVEL_DB, CONFIG_DB, STATE_DB)
- Sequence diagram if required.
- Linux dependencies and interface
- Warm reboot requirements/dependencies
- Fastboot requirements/dependencies
- Scalability and performance requirements/impact
- Memory requirements
- Docker dependency
- Build dependency if any
- Management interfaces - SNMP, CLI, RestAPI, etc.,
- Serviceability and Debug (logging, counters, trace etc) related design
- Is this change specific to any platform? Are there dependencies for platforms to implement anything to make this feature work? If yes, explain in detail and inform community in advance.
- SAI API requirements, CLI requirements, ConfigDB requirements. Design is covered in following sections.
This section covers the changes made or new API added in SAI API for implementing this feature. If there is no change in SAI API for HLD feature, it should be explicitly mentioned in this section. This section should list the SAI APIs/objects used by the design so that silicon vendors can implement the required support in their SAI. Note that the SAI requirements should be discussed with SAI community during the design phase and ensure the required SAI support is implemented along with the feature/enhancement.
This section should have sub-sections for all types of configuration and management related design. Example sub-sections for "CLI" and "Config DB" are given below. Sub-sections related to data models (YANG, REST, gNMI, etc.,) should be added as required. If there is breaking change which may impact existing platforms, please call out in the design and get platform vendors reviewed.
Paste a preliminary manifest in a JSON format.
This sub-section covers the addition/deletion/modification of CLI changes and YANG model changes needed for the feature in detail. If there is no change in CLI for HLD feature, it should be explicitly mentioned in this section. Note that the CLI changes should ensure downward compatibility with the previous/existing CLI. i.e. Users should be able to save and restore the CLI from previous release even after the new CLI is implemented. This should also explain the CLICK and/or KLISH related configuration/show in detail. https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md needs be updated with the corresponding CLI change.
This sub-section covers the addition/deletion/modification of config DB changes needed for the feature. If there is no change in configuration for HLD feature, it should be explicitly mentioned in this section. This section should also ensure the downward compatibility for the change.
Mention whether this feature/enhancement has got any requirements/dependencies/impact w.r.t. warmboot and fastboot. Ensure that existing warmboot/fastboot feature is not affected due to this design and explain the same.
This sub-section covers the memory consumption analysis for the new feature: no memory consumption is expected when the feature is disabled via compilation and no growing memory consumption while feature is disabled by configuration.
Explain what kind of unit testing, system testing, regression testing, warmboot/fastboot testing, etc., Ensure that the existing warmboot/fastboot requirements are met. For example, if the current warmboot feature expects maximum of 1 second or zero second data disruption, the same should be met even after the new feature/enhancement is implemented. Explain the same here. Example sub-sections for unit test cases and system test cases are given below.
NOTE: All the sections and sub-sections given above are mandatory in the design document. Users can add additional sections/sub-sections if required.