Update hld_template.md by adding numbers to each section

doc/hld_template.md

@@ -2,32 +2,32 @@
 
 ## Table of Content 
 
-### Revision  
+### 1. Revision  
 
-### Scope  
+### 2. Scope  
 
 This section describes the scope of this high-level design document in SONiC.
 
-### Definitions/Abbreviations 
+### 3. Definitions/Abbreviations 
 
 This section covers the abbreviation if any, used in this high-level design document and its definitions.
 
-### Overview 
+### 4. Overview 
 
 The purpose of this section is to give an overview of high-level design document and its architecture implementation in SONiC. 
 
-### Requirements
+### 5. Requirements
 
 This section list out all the requirements for the HLD coverage and exemptions (not supported) if any for this design.
 
-### Architecture Design 
+### 6. Architecture 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.
 
-### High-Level Design 
+### 7. High-Level Design 
 
 This section covers the high level design of the feature/enhancement. This section covers the following points in detail.
 
@@ -50,46 +50,46 @@ This section covers the high level design of the feature/enhancement. This secti
 	- 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.
 
-### SAI API 
+### 8. SAI API 
 
 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.
 
-### Configuration and management 
+### 9. Configuration and management 
 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. 
 
-#### Manifest (if the feature is an Application Extension)
+#### 9.1. Manifest (if the feature is an Application Extension)
 
 Paste a preliminary manifest in a JSON format.
 
-#### CLI/YANG model Enhancements 
+#### 9.2. CLI/YANG model Enhancements 
 
 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.
 
-#### Config DB Enhancements  
+#### 9.3. Config DB Enhancements  
 
 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. 
 
-### Warmboot and Fastboot Design Impact  
+### 10. Warmboot and Fastboot Design Impact  
 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.
 
-### Memory Consumption
+### 11. Memory Consumption
 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. 
-### Restrictions/Limitations  
+### 12. Restrictions/Limitations  
 
-### Testing Requirements/Design  
+### 13. Testing Requirements/Design  
 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. 
 
-#### Unit Test cases  
+#### 13.1. Unit Test cases  
 
-#### System Test cases
+#### 13.2. System Test cases
 
-### Open/Action items - if any 
+### 14. Open/Action items - if any 
 
 
 NOTE: All the sections and sub-sections given above are mandatory in the design document. Users can add additional sections/sub-sections if required.