diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 36cd108f9d..46eb6e2ac7 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -7,4 +7,4 @@ assignees: '' --- -**We do not triage issue for this repo. All issues are triaged in Azure/sonic-buildimage repo** +**We do not triage issue for this repo. All issues are triaged in sonic-net/sonic-buildimage repo** diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0350e9959b..d9358ee8cd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -34,7 +34,7 @@ For example: * Use issues to keep track of what is going on ##Expectations for pull requests -Pull requests should be free of any known bugs and be accompanied by tests and appropriate documentation. Test coverage may include unit tests, integration tests such as [PTF tests](https://github.com/Azure/SONiC/wiki/HOWTO-write-a-PTF-Test) defined in the [sonic-mgmt repo](https://github.com/Azure/sonic-mgmt/tree/master/ansible/roles/test/tasks). +Pull requests should be free of any known bugs and be accompanied by tests and appropriate documentation. Test coverage may include unit tests, integration tests such as [PTF tests](https://github.com/sonic-net/SONiC/wiki/HOWTO-write-a-PTF-Test) defined in the [sonic-mgmt repo](https://github.com/sonic-net/sonic-mgmt/tree/master/ansible/roles/test/tasks). ## Commiting new test When commiting a new feature with a new test, please complete a [test plan from the template](doc/SONiC%20Test%20Plan%20Template.md) diff --git a/MoM.html b/MoM.html index 88c8870acb..066eb50377 100755 --- a/MoM.html +++ b/MoM.html @@ -151,7 +151,7 @@

SONiC community meeting minutes

  Mar 29 2022    - DSCP/TC Remapping for Tunnel traffic HLD + DSCP/TC Remapping for Tunnel traffic HLD MoM @@ -171,12 +171,12 @@

SONiC community meeting minutes

  Mar 01 2022    - Build-Enhancements + Build-Enhancements MoM   Feb 22 2022    - auto-techsupport + auto-techsupport MoM @@ -191,17 +191,17 @@

SONiC community meeting minutes

  Feb 01 2022    - Counter delay via config_db + Counter delay via config_db MoM   Jan 25 2021    - Add VLAN Stacking + Add VLAN Stacking MoM   Jan 18 2021    - Deterministic approach in SONiC for Interface Link bring-up sequence + Deterministic approach in SONiC for Interface Link bring-up sequence MoM @@ -236,7 +236,7 @@

SONiC community meeting minutes

  Nov 30 2021    - 202111 Release Tracking + 202111 Release Tracking MoM @@ -291,7 +291,7 @@

SONiC community meeting minutes

  Sep 14 2021    - ECMP Overlay BFD support + ECMP Overlay BFD support MoM @@ -301,12 +301,12 @@

SONiC community meeting minutes

  Aug 31 2021    - Show Running Command Enhancement + Show Running Command Enhancement MoM   Aug 24 2021    - SAG - Static Anycast Gateway + SAG - Static Anycast Gateway MoM @@ -316,12 +316,12 @@

SONiC community meeting minutes

  Aug 10 2021    - SONiC_SFP_refactoring HLD + SONiC_SFP_refactoring HLD MoM   Aug 03 2021    - Class Based Forwarding HLD + Class Based Forwarding HLD MoM @@ -331,7 +331,7 @@

SONiC community meeting minutes

  Jul 20 2021    - DHCPv6 Relay agent + DHCPv6 Relay agent MoM @@ -351,12 +351,12 @@

SONiC community meeting minutes

  Jun 22 2021    - 202106 release updates + 202106 release updates MoM   Jun 15 2021    - C-CMIS Support in SONiC + C-CMIS Support in SONiC MoM @@ -366,7 +366,7 @@

SONiC community meeting minutes

  Jun 01 2021    - SAI Failure Handling + SAI Failure Handling MoM @@ -376,7 +376,7 @@

SONiC community meeting minutes

  May 18 2021    - Debug dump utility HLD + Debug dump utility HLD MoM @@ -391,17 +391,17 @@

SONiC community meeting minutes

  April 27 2021    - Generalizing config.bcm support for BRCM silicons + Generalizing config.bcm support for BRCM silicons MoM   April 20 2021    - Event & Alarm Framework HLD + Event & Alarm Framework HLD MoM   April 13 2021    - Policy Based Hashing HLD + Policy Based Hashing HLD MoM @@ -416,32 +416,32 @@

SONiC community meeting minutes

  March 23 2021    - SONiC Generic Update and Rollback HLD + SONiC Generic Update and Rollback HLD MoM   March 16 2021    - Inband Mgmt via mgmt VRF + Inband Mgmt via mgmt VRF MoM   March 09 2021    - MPLS HLD initial revision + MPLS HLD initial revision MoM   March 02 2021    - Weighted ECMP HLD + Weighted ECMP HLD MoM   Febuary 23 2021    - SONiC Yang Model and related libraries + SONiC Yang Model and related libraries MoM   Febuary 16 2021    - cpu queue stats + cpu queue stats MoM @@ -451,7 +451,7 @@

SONiC community meeting minutes

  Febuary 02 2021    - Next hop group split HLD + Next hop group split HLD MoM @@ -461,7 +461,7 @@

SONiC community meeting minutes

  January 19 2021    - Port auto negotiation HLD + Port auto negotiation HLD MoM @@ -491,7 +491,7 @@

SONiC community meeting minutes

  December 08 2020    - PMON enhancements for Chassis HLD + PMON enhancements for Chassis HLD MoM @@ -501,7 +501,7 @@

SONiC community meeting minutes

  November 24 2020    - SONiC Application Extension HLD + SONiC Application Extension HLD MoM diff --git a/contact.html b/contact.html index b1024c516f..5516ebaa88 100644 --- a/contact.html +++ b/contact.html @@ -90,7 +90,7 @@

Contact

Send questions, bugs, comments and ideas to sonicproject@googlegroups.com

Join the mailing list

Join the Slack discussion group

-

Report issues here and provide the following:

+

Report issues here and provide the following:

-show version output

-SONiC support file generated by the sudo generate_dump command

@@ -143,4 +143,4 @@

Contact

- \ No newline at end of file + diff --git a/doc/SONiC 201904 Release Notes.md b/doc/SONiC 201904 Release Notes.md index 307a53f77c..49516ebbe0 100644 --- a/doc/SONiC 201904 Release Notes.md +++ b/doc/SONiC 201904 Release Notes.md @@ -2,7 +2,7 @@ # SONiC 201904 Release Notes # Branch Location -https://github.com/Azure/sonic-buildimage/tree/201904 +https://github.com/sonic-net/sonic-buildimage/tree/201904 # Dependency Version @@ -27,11 +27,11 @@ https://github.com/Azure/sonic-buildimage/tree/201904 | 1 | [FRR as default routing stack](http://docs.frrouting.org/en/latest/) | | | 2 | Upgrade each docker to stretch version | SNMPD, LLDPD, Teamd | | 3 | Upgrade docker engine to 18.09 | | -| 4 | [Everflow enhancement](https://github.com/Azure/SONiC/blob/bb4f4a3a85935a38ec7f9625ef62cbe58c0998b4/doc/SONiC_EVERFLOW_IPv6.pdf) | | -| 5 | [Egress ACL bug fix and ACL CLI enhancement](https://github.com/Azure/SONiC/blob/dfa7e58292deb4d7b10d1e0ca73f296cd206e9d2/doc/acl/egress-acl-bug-fix-description.md) | | -| 6 | [L3 RIF counter support](https://github.com/Azure/SONiC/blob/master/doc/RIF_counters.md) [PR](https://github.com/Azure/SONiC/pull/310) | | -| 7 | [PMon Refactoring](https://github.com/Azure/SONiC/tree/master/doc/pmon) | | -| 8 | BGP-EVPN support (type 5) (related HLD [Fpmsyncd](https://github.com/Azure/SONiC/pull/375), [vxlanmgr](https://github.com/Azure/SONiC/pull/369), [template](https://github.com/Azure/sonic-buildimage/pull/2838/files) ) | | +| 4 | [Everflow enhancement](https://github.com/sonic-net/SONiC/blob/bb4f4a3a85935a38ec7f9625ef62cbe58c0998b4/doc/SONiC_EVERFLOW_IPv6.pdf) | | +| 5 | [Egress ACL bug fix and ACL CLI enhancement](https://github.com/sonic-net/SONiC/blob/dfa7e58292deb4d7b10d1e0ca73f296cd206e9d2/doc/acl/egress-acl-bug-fix-description.md) | | +| 6 | [L3 RIF counter support](https://github.com/sonic-net/SONiC/blob/master/doc/RIF_counters.md) [PR](https://github.com/sonic-net/SONiC/pull/310) | | +| 7 | [PMon Refactoring](https://github.com/sonic-net/SONiC/tree/master/doc/pmon) | | +| 8 | BGP-EVPN support (type 5) (related HLD [Fpmsyncd](https://github.com/sonic-net/SONiC/pull/375), [vxlanmgr](https://github.com/sonic-net/SONiC/pull/369), [template](https://github.com/sonic-net/sonic-buildimage/pull/2838/files) ) | | # Security Updates diff --git a/doc/SONiC-User-Manual.md b/doc/SONiC-User-Manual.md index 68b2ac6f71..63ea9b77d4 100644 --- a/doc/SONiC-User-Manual.md +++ b/doc/SONiC-User-Manual.md @@ -43,15 +43,15 @@ Table of Contents # Introduction SONiC is an open source network operating system based on Linux that runs on switches from multiple vendors and ASICs. SONiC offers a full-suite of network functionality, like BGP and RDMA, that has been production-hardened in the data centers of some of the largest cloud-service providers. It offers teams the flexibility to create the network solutions they need while leveraging the collective strength of a large ecosystem and community. -SONiC software shall be loaded in these [supported devices](https://github.com/Azure/SONiC/wiki/Supported-Devices-and-Platforms) and this User guide explains the basic steps for using the SONiC in those platforms. +SONiC software shall be loaded in these [supported devices](https://github.com/sonic-net/SONiC/wiki/Supported-Devices-and-Platforms) and this User guide explains the basic steps for using the SONiC in those platforms. -Connect the console port of the device and use the 9600 baud rate to access the device. Follow the [Quick Start Guide](https://github.com/Azure/SONiC/wiki/Quick-Start) to boot the device in ONIE mode and install the SONiC software using the steps specified in the document and reboot the device. In some devices that are pre-loaded with SONiC software, this step can be skipped. +Connect the console port of the device and use the 9600 baud rate to access the device. Follow the [Quick Start Guide](https://github.com/sonic-net/SONiC/wiki/Quick-Start) to boot the device in ONIE mode and install the SONiC software using the steps specified in the document and reboot the device. In some devices that are pre-loaded with SONiC software, this step can be skipped. Users shall use the default username/password "admin/YourPaSsWoRd" to login to the device through the console port. After logging into the device, SONiC software can be configured in following three methods. - 1) [Command Line Interface](https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md) - 2) [config_db.json](https://github.com/Azure/SONiC/wiki/Configuration) - 3) [minigraph.xml](https://github.com/Azure/SONiC/wiki/Configuration-with-Minigraph-(~Sep-2017)) + 1) [Command Line Interface](https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md) + 2) [config_db.json](https://github.com/sonic-net/SONiC/wiki/Configuration) + 3) [minigraph.xml](https://github.com/sonic-net/SONiC/wiki/Configuration-with-Minigraph-(~Sep-2017)) Users can use all of the above methods or choose either one method to configure and to view the status of the device. This user manual explains the common commands & related configuration/show examples on how to use the SONiC device. Refer the above documents for more detailed information. @@ -78,9 +78,9 @@ This guide details the steps to install a SONiC image on your supported switch. ## 1.1 Download Image -We have one SONiC Image per ASIC vendor. You can download SONiC Image [here](https://github.com/Azure/SONiC/wiki/Supported-Devices-and-Platforms) +We have one SONiC Image per ASIC vendor. You can download SONiC Image [here](https://github.com/sonic-net/SONiC/wiki/Supported-Devices-and-Platforms) -You can also build SONiC from source and the instructions can be found [here](https://github.com/Azure/sonic-buildimage). +You can also build SONiC from source and the instructions can be found [here](https://github.com/sonic-net/sonic-buildimage). Once the image is available in your local machine, the image can be installed either by installing using a USB thumb drive or over the network as given in following sub-sections. In case if the device is already preloaded with SONiC image, the device can be booted without the installation process. @@ -241,19 +241,19 @@ This TSG gives the instruction of how to reset a SONiC switch password. 1. Edit Grub boot menu options 1.1 First you need to get into grub menu options. This menu is displayed right at the beginning of the boot. You should get something similar to this, but not the exactly the same. Choose the choice Start with SONiC-: - ![image.png](https://github.com/Azure/SONiC/blob/master/images/PW-1.png) + ![image.png](https://github.com/sonic-net/SONiC/blob/master/images/PW-1.png) 1.2 Now we attempt to edit grub's boot option. Press "e" to edit the first grub menu option and navigate to kernel line: - ![image.png](https://github.com/Azure/SONiC/blob/master/images/PW-2.png) + ![image.png](https://github.com/sonic-net/SONiC/blob/master/images/PW-2.png) 1.3 Remove quiet and add init=/bin/bash - ![image.png](https://github.com/Azure/SONiC/blob/master/images/PW-3.png) + ![image.png](https://github.com/sonic-net/SONiC/blob/master/images/PW-3.png) 1.4 Press Ctrl-x to boot 2. Remount / and /proc 2.1 After successfully boot you will be presented with bash command prompt: - ![image.png](https://github.com/Azure/SONiC/blob/master/images/PW-4.png) + ![image.png](https://github.com/sonic-net/SONiC/blob/master/images/PW-4.png) ``` mount -o remount,rw / @@ -264,7 +264,7 @@ mount -o remount,rw /proc 3.1 To reset an actual password is now simple as typing : `passwd admin` - ![image.png](https://github.com/Azure/SONiC/blob/master/images/PW-5.png) + ![image.png](https://github.com/sonic-net/SONiC/blob/master/images/PW-5.png) ``` sync @@ -279,13 +279,13 @@ sudo reboot -f SONiC is managing configuration in a single source of truth - a redisDB instance that we refer as ConfigDB. Applications subscribe to ConfigDB and generate their running configuration correspondingly. -Details about ConfigDB and schema design, please find it [here](https://github.com/Azure/SONiC/wiki/Configuration) +Details about ConfigDB and schema design, please find it [here](https://github.com/sonic-net/SONiC/wiki/Configuration) -Before Sep 2017, we were using an XML file named minigraph.xml to configure SONiC devices. For historical documentation, please refer to [Configuration with Minigraph](https://github.com/Azure/SONiC/wiki/Configuration-with-Minigraph-(~Sep-2017)) +Before Sep 2017, we were using an XML file named minigraph.xml to configure SONiC devices. For historical documentation, please refer to [Configuration with Minigraph](https://github.com/sonic-net/SONiC/wiki/Configuration-with-Minigraph-(~Sep-2017)) SONiC includes commands that allow user to show platform, transceivers, L2, IP, BGP status, etc. -- [Command Reference](https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md) +- [Command Reference](https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md) Note that all the configuration commands need root privileges to execute them and the commands are case-sensitive. Show commands can be executed by all users without the root privileges. @@ -305,7 +305,7 @@ SONiC does not provide a CLI to configure the static IP for the management inter ``` Note that SONiC does not support management VRF and hence it is not possible to differentiate data traffic and management traffic. Work is in progress to support the mgmtVRF in Aug2019 release. - 2) use config_db.json and configure the MGMT_INTERFACE key with the appropriate values. Refer [here](https://github.com/Azure/SONiC/wiki/Configuration#Management-Interface) + 2) use config_db.json and configure the MGMT_INTERFACE key with the appropriate values. Refer [here](https://github.com/sonic-net/SONiC/wiki/Configuration#Management-Interface) Add the following example configuration in a file (ex: mgmt_ip.json) and load it as follows. @@ -331,7 +331,7 @@ Note that SONiC does not support management VRF and hence it is not possible to After removing the key, users can load the new configuration using "config load mgmt_ip.json" command and then do "systemctl restart interfaces-config" to make it effective. Users shall verify the configured management interface IP address value using "ifconfig" linux command. - 3) use minigraph.xml and configure "ManagementIPInterfaces" tag inside "DpgDesc" tag as given at the [page](https://github.com/Azure/SONiC/wiki/Configuration-with-Minigraph-(~Sep-2017)) + 3) use minigraph.xml and configure "ManagementIPInterfaces" tag inside "DpgDesc" tag as given at the [page](https://github.com/sonic-net/SONiC/wiki/Configuration-with-Minigraph-(~Sep-2017)) Once the IP address is configured, the same can be verified using "/sbin/ifconfig eth0" linux command. Users can SSH login to this management interface IP address from their management network. @@ -403,7 +403,7 @@ Go Back To [Beginning of the document](#SONiC-COMMAND-LINE-INTERFACE-GUIDE) or [ ## 3.2.2 Check features available in this version -[SONiC roadmap planning](https://github.com/Azure/SONiC/wiki/Sonic-Roadmap-Planning) explains the various features that are added in every software release. +[SONiC roadmap planning](https://github.com/sonic-net/SONiC/wiki/Sonic-Roadmap-Planning) explains the various features that are added in every software release. TBD: Is this enough? Need information from Xin. @@ -579,11 +579,11 @@ Basic cable connectivity shall be verified by configuring the IP address for the | # | Module | CLI Link | ConfigDB Link | Remarks | | --- | --- | --- | --- | --- | -| 1 | Interface |[Interface CLI](https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md#Interface-Configuration-And-Show-Commands) | [Interface ConfigDB](Configuration.md)| To view the details about the interface | -| 2 | BGP |[BGP CLI](https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md#BGP-Configuration-And-Show-Commands) | [BGP ConfigDB](Configuration.md)| To view the details about the BGP | -| 3 | ACL |[ACL CLI](https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md#ACL-Configuration-And-Show) | [ACL ConfigDB](Configuration.md)| To view the details about the ACL | +| 1 | Interface |[Interface CLI](https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md#Interface-Configuration-And-Show-Commands) | [Interface ConfigDB](Configuration.md)| To view the details about the interface | +| 2 | BGP |[BGP CLI](https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md#BGP-Configuration-And-Show-Commands) | [BGP ConfigDB](Configuration.md)| To view the details about the BGP | +| 3 | ACL |[ACL CLI](https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md#ACL-Configuration-And-Show) | [ACL ConfigDB](Configuration.md)| To view the details about the ACL | | 4 | COPP |COPP CLI Not Available | [COPP ConfigDB](Configuration.md)| To view the details about the COPP | -| 5 | Mirroring |[Mirroring CLI](https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md#mirroring-configuration-and-show) | [Mirroring ConfigDB](Configuration.md)| To view the details about the Mirroring | +| 5 | Mirroring |[Mirroring CLI](https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md#mirroring-configuration-and-show) | [Mirroring ConfigDB](Configuration.md)| To view the details about the Mirroring | diff --git a/doc/SONiC_201911_Release_Notes.md b/doc/SONiC_201911_Release_Notes.md index 86440444b1..8f93e3ad15 100644 --- a/doc/SONiC_201911_Release_Notes.md +++ b/doc/SONiC_201911_Release_Notes.md @@ -16,7 +16,7 @@ This document captures the new features added and enhancements done on existing # Branch and Image Location -Branch : https://github.com/Azure/sonic-buildimage/tree/201911
+Branch : https://github.com/sonic-net/sonic-buildimage/tree/201911
Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for Broadcom based platforms is [here]( https://sonic-jenkins.westus2.cloudapp.azure.com/job/broadcom/job/buildimage-brcm-201911/lastSuccessfulBuild/artifact/target/)) # Dependency Version @@ -33,7 +33,7 @@ Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for | syncd | 1.0.0 | | swss | 1.0.0 | | radvd | 2.17-2~bpo9+1 | -| isc-dhcp | 4.3.5-2 ([PR2946](https://github.com/Azure/sonic-buildimage/pull/2946) ) | +| isc-dhcp | 4.3.5-2 ([PR2946](https://github.com/sonic-net/sonic-buildimage/pull/2946) ) | | sonic-telemetry | 0.1 | | redis-server/ redis-tools | 5.0.3-3~bpo9+2 | @@ -49,94 +49,94 @@ Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for #### Build time improvements This document describes few options to improve SONiC build time. To split the work we will consider that SONiC has two stages: 1. debian/python packages compilation <- relatively fast 2. docker images build <- slower espessially when several users are building in parallel. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/sonic-build-system/build_system_improvements.md) and below mentioned PR's for more details. -
**Pull Requests** : [911](https://github.com/Azure/sonic-swss/pull/911) ,[280](https://github.com/Azure/sonic-swss-common/pull/280) , [461](https://github.com/Azure/sonic-sairedis/pull/461) , [3048](https://github.com/Azure/sonic-buildimage/pull/3048) , [3049](https://github.com/Azure/sonic-buildimage/pull/3049) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/sonic-build-system/build_system_improvements.md) and below mentioned PR's for more details. +
**Pull Requests** : [911](https://github.com/sonic-net/sonic-swss/pull/911) ,[280](https://github.com/sonic-net/sonic-swss-common/pull/280) , [461](https://github.com/sonic-net/sonic-sairedis/pull/461) , [3048](https://github.com/sonic-net/sonic-buildimage/pull/3048) , [3049](https://github.com/sonic-net/sonic-buildimage/pull/3049) #### Configurable drop counters This feature is to provides better packet drop visibility in SONiC by providing a mechanism to count and classify packet drops that occur due to different reasons.This is done by adding support for SAI debug counters to SONiC. Supported counters are PORT_INGRESS_DROPS , PORT_EGRESS_DROPS, SWITCH_INGRESS_DROP & SWITCH_EGRESS_DROPS. A CLI tool will be provided for users to manage and configure their own drop counters. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/drop_counters/drop_counters_HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [308](https://github.com/Azure/sonic-swss-common/pull/308) , [520](https://github.com/Azure/sonic-sairedis/pull/520) , [1075](https://github.com/Azure/sonic-swss/pull/1075) , [1093](https://github.com/Azure/sonic-swss/pull/1093) , [688](https://github.com/Azure/sonic-utilities/pull/688) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/drop_counters/drop_counters_HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [308](https://github.com/sonic-net/sonic-swss-common/pull/308) , [520](https://github.com/sonic-net/sonic-sairedis/pull/520) , [1075](https://github.com/sonic-net/sonic-swss/pull/1075) , [1093](https://github.com/sonic-net/sonic-swss/pull/1093) , [688](https://github.com/sonic-net/sonic-utilities/pull/688) #### Egress mirroring support and ACL action capability check Added support for egress mirror action. To query ACL action list supported by ASIC per stage and put this information in STATE DB SWITCH_CAPABILITY table and to perform secondary query for ACL action attributes which parameters are enum values (e.g. for PACKET_ACTION - DROP,FORWARD). -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/acl/acl_stage_capability.md) and below mentioned PR's for more details. -
**Pull Requests** : [963](https://github.com/Azure/sonic-swss/pull/963) , [1019](https://github.com/Azure/sonic-swss/pull/1019) , [575](https://github.com/Azure/sonic-utilities/pull/575) , [481](https://github.com/Azure/sonic-sairedis/pull/481) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/acl/acl_stage_capability.md) and below mentioned PR's for more details. +
**Pull Requests** : [963](https://github.com/sonic-net/sonic-swss/pull/963) , [1019](https://github.com/sonic-net/sonic-swss/pull/1019) , [575](https://github.com/sonic-net/sonic-utilities/pull/575) , [481](https://github.com/sonic-net/sonic-sairedis/pull/481) #### HW resource monitor This document describes the high level design of verification the hardware resources consumed by a device. The hardware resources which are currently verified are CPU, RAM and HDD. This implementation will be integrated in test cases written on Pytest framework. -
Refer[HLD document](https://github.com/Azure/SONiC/blob/master/doc/DUT_monitor_HLD.md) and below mentioned PR for more details. -
**Pull Request** : [1121](https://github.com/Azure/sonic-mgmt/pull/1121) +
Refer[HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/DUT_monitor_HLD.md) and below mentioned PR for more details. +
**Pull Request** : [1121](https://github.com/sonic-net/sonic-mgmt/pull/1121) #### L3 performance and scaling enhancements When sending a lot of ARP/ND requests in a burst, ARP entries are getting purged from the kernel while the later set of ARP entries was still getting added. The sequence of add/remove is in such a way that we were never able to cross ~2400 entries. Currently the max rate for ARP/ND is 600 packets, we will be increasing it to higher number(8000) in CoPP file to improve the learning time. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/89abd4938d792215b75d801e87b47ccf2c22f111/doc/L3_performance_and_scaling_enchancements_HLD.md) and below mentioned PR's for more details. -
**Pull Request** : [1048](https://github.com/Azure/sonic-swss/pull/1048) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/89abd4938d792215b75d801e87b47ccf2c22f111/doc/L3_performance_and_scaling_enchancements_HLD.md) and below mentioned PR's for more details. +
**Pull Request** : [1048](https://github.com/sonic-net/sonic-swss/pull/1048) #### Log analyzer to pytest In the root conftest there is implemented "loganalyzer" pytest fixture, which starts automatically for all test cases.If loganalyzer find specified messages which corresponds to defined regular expressions, it will display found messages and pytest will generate 'error'. Refer [Loganalyzer API usage example](https://github.com/yvolynets-mlnx/sonic-mgmt/blob/78a71ebccdc44bd62e81ff4b12dd84cb2c0ea34d/tests/loganalyzer/README.md) for more details. -
**Pull Request** : [1048](https://github.com/Azure/sonic-mgmt/pull/1048) +
**Pull Request** : [1048](https://github.com/sonic-net/sonic-mgmt/pull/1048) #### Management Framework -Management framework is a SONiC application which is responsible for providing various common North Bound Interfaces (NBIs) for the purposes of managing configuration and status on SONiC switches. The application manages coordination of NBI’s to provide a coherent way to validate, apply and show configuration. Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/doc/mgmt/Management%20Framework.md) -
**Pull Requests** : [18](https://github.com/Azure/sonic-mgmt-framework/pull/18) , [23](https://github.com/Azure/sonic-telemetry/pull/23) , [3488](https://github.com/Azure/sonic-buildimage/pull/3488) , [659](https://github.com/Azure/sonic-utilities/pull/659) +Management framework is a SONiC application which is responsible for providing various common North Bound Interfaces (NBIs) for the purposes of managing configuration and status on SONiC switches. The application manages coordination of NBI’s to provide a coherent way to validate, apply and show configuration. Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/Management%20Framework.md) +
**Pull Requests** : [18](https://github.com/sonic-net/sonic-mgmt-framework/pull/18) , [23](https://github.com/sonic-net/sonic-gnmi/pull/23) , [3488](https://github.com/sonic-net/sonic-buildimage/pull/3488) , [659](https://github.com/sonic-net/sonic-utilities/pull/659) #### Management VRF Management VRF (mvrf) feature provides a separation between the management network traffic and the data plane network traffic using the linux CGROUPS based on l3mdev. Management interface (eth0) shall be enslaved in l3mdev. Management applications like SSH shall use the enslaved eth0 and corresponding mvrf routing table for management traffic.
Refer below PR's for more details. -
**Pull Requests** : [2585](https://github.com/Azure/sonic-buildimage/pull/2585) , [2608](https://github.com/Azure/sonic-buildimage/pull/2608) , [3204](https://github.com/Azure/sonic-buildimage/pull/3204) , [463](https://github.com/Azure/sonic-utilities/pull/463) , [472](https://github.com/Azure/sonic-utilities/pull/472) , [627](https://github.com/Azure/sonic-utilities/pull/627) , [3586](https://github.com/Azure/sonic-buildimage/pull/3586) +
**Pull Requests** : [2585](https://github.com/sonic-net/sonic-buildimage/pull/2585) , [2608](https://github.com/sonic-net/sonic-buildimage/pull/2608) , [3204](https://github.com/sonic-net/sonic-buildimage/pull/3204) , [463](https://github.com/sonic-net/sonic-utilities/pull/463) , [472](https://github.com/sonic-net/sonic-utilities/pull/472) , [627](https://github.com/sonic-net/sonic-utilities/pull/627) , [3586](https://github.com/sonic-net/sonic-buildimage/pull/3586) #### Multi-DB optimization Creating multiple database instances help us to separate the databases based on their operation frequency or their role in the whole SONiC system, for example, like state database and loglevel database are not key features, we can avoid them affecting read and write APPL_DB or ASIC_DB via multiple database instances. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/ed69d427dcf358299b2c1b812e59a1e26a4ef4a5/doc/database/multi_database_instances.md) for more details. -
**Pull Request** : [52](https://github.com/Azure/sonic-py-swsssdk/pull/52) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/ed69d427dcf358299b2c1b812e59a1e26a4ef4a5/doc/database/multi_database_instances.md) for more details. +
**Pull Request** : [52](https://github.com/sonic-net/sonic-py-swsssdk/pull/52) #### NAT Network Address Translation (NAT) router enables private IP networks to communicate to the public networks (internet) by translating the private IP address to globally unique IP address. It also provides security by hiding the identity of the host in private network. This feature supports Source NAT, Destination NAT ,Static NAT/NAPT, Dynamic NAT/NAPT, NAT zones, Twice NAT/NAPT nd support of VRF.
For more details refer [HLD Document](https://github.com/kirankella/SONiC/blob/nat_doc_changes/doc/nat/nat_design_spec.md). -
**Pull Requests** : [3494](https://github.com/Azure/sonic-buildimage/pull/3494) , [1059](https://github.com/Azure/sonic-swss/pull/1059) , [645](https://github.com/Azure/sonic-utilities/pull/645) , [100 ](https://github.com/Azure/sonic-linux-kernel/pull/100) , [304](https://github.com/Azure/sonic-swss-common/pull/304) , [519](https://github.com/Azure/sonic-sairedis/pull/519) +
**Pull Requests** : [3494](https://github.com/sonic-net/sonic-buildimage/pull/3494) , [1059](https://github.com/sonic-net/sonic-swss/pull/1059) , [645](https://github.com/sonic-net/sonic-utilities/pull/645) , [100 ](https://github.com/sonic-net/sonic-linux-kernel/pull/100) , [304](https://github.com/sonic-net/sonic-swss-common/pull/304) , [519](https://github.com/sonic-net/sonic-sairedis/pull/519) #### Platform test This test plan is to check the functionalities of platform related software components. These software components are for managing platform hardware, including FANs, thermal sensors, SFP, transceivers, pmon, etc.The software components for managing platform hardware on Mellanox platform is the hw-management package. -
Refer [Platform testplan](https://github.com/Azure/SONiC/blob/master/doc/pmon/sonic_platform_test_plan.md) for more details. -
**Pull Requests** : [915](https://github.com/Azure/sonic-mgmt/pull/915) , [980](https://github.com/Azure/sonic-mgmt/pull/980) , [1079](https://github.com/Azure/sonic-mgmt/pull/1079) +
Refer [Platform testplan](https://github.com/sonic-net/SONiC/blob/master/doc/pmon/sonic_platform_test_plan.md) for more details. +
**Pull Requests** : [915](https://github.com/sonic-net/sonic-mgmt/pull/915) , [980](https://github.com/sonic-net/sonic-mgmt/pull/980) , [1079](https://github.com/sonic-net/sonic-mgmt/pull/1079) #### Proxy ARP When an interface is enabled with "proxy_arp", the same is enabled in the kernel. ASIC ARP packet action is also updated to trap these packets to CPU in those interfaces. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/doc/arp/Proxy%20Arp.md) for more details. -
**Pull Requests** : [617](https://github.com/Azure/SONiC/pull/617) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/doc/arp/Proxy%20Arp.md) for more details. +
**Pull Requests** : [617](https://github.com/sonic-net/SONiC/pull/617) #### sFlow The CLI is enhanced to provide configuring and display of sFlow parameters including sflow collectors, agent IP, sampling rate for interfaces. The CLI configurations currently only interact with the CONFIG_DB. The newly introduced sflow container consists of an instantiation of the InMon's hsflowd daemon. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/doc/sflow/sflow_hld.md) for more details. -
**Pull Requests** : [94](https://github.com/Azure/sonic-linux-kernel/pull/94) , [299](https://github.com/Azure/sonic-swss-common/pull/299) , [498](https://github.com/Azure/sonic-sairedis/pull/498) , [1012](https://github.com/Azure/sonic-swss/pull/1012) , [1011](https://github.com/Azure/sonic-swss/pull/1011) , [3251](https://github.com/Azure/sonic-buildimage/pull/3251) , [592 ](https://github.com/Azure/sonic-utilities/pull/592) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/doc/sflow/sflow_hld.md) for more details. +
**Pull Requests** : [94](https://github.com/sonic-net/sonic-linux-kernel/pull/94) , [299](https://github.com/sonic-net/sonic-swss-common/pull/299) , [498](https://github.com/sonic-net/sonic-sairedis/pull/498) , [1012](https://github.com/sonic-net/sonic-swss/pull/1012) , [1011](https://github.com/sonic-net/sonic-swss/pull/1011) , [3251](https://github.com/sonic-net/sonic-buildimage/pull/3251) , [592 ](https://github.com/sonic-net/sonic-utilities/pull/592) #### SSD diagnostic tolling Add to SONiC an ability to check storage health state. Basic functionality will be implemented as a CLI command. Optionally pmon daemon could be added for constant disk state monitoring. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/doc/ssdhealth_design.md) for more details. -
**Pull Requests** : [587](https://github.com/Azure/sonic-utilities/pull/587) , [47](https://github.com/Azure/sonic-buildimage/pull/47) , [3218](https://github.com/Azure/sonic-buildimage/pull/3218) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/doc/ssdhealth_design.md) for more details. +
**Pull Requests** : [587](https://github.com/sonic-net/sonic-utilities/pull/587) , [47](https://github.com/sonic-net/sonic-buildimage/pull/47) , [3218](https://github.com/sonic-net/sonic-buildimage/pull/3218) #### Sub-port support A sub port interface is a logical interface that can be created on a physical port or a port channel.A sub port interface serves as an interface to either a .1D bridge or a VRF, but not both. This design focuses on the use case of creating a sub port interface on a physical port or a port channel and using it as a router interface to a VRF.
Refer [HLD Document](https://github.com/wendani/SONiC/blob/a3e669e6778c272fc571a8bf3bd78e7eb75a8ec7/doc/sonic-sub-port-intf-hld.md) for more details. -
**Pull Requests** : [998](https://github.com/opencomputeproject/SAI/pull/998) , [284](https://github.com/Azure/sonic-swss-common/pull/284) , [969](https://github.com/Azure/sonic-swss/pull/969) , [871](https://github.com/Azure/sonic-swss/pull/871) , [3412](https://github.com/Azure/sonic-buildimage/pull/3412) , [3422](https://github.com/Azure/sonic-buildimage/pull/3422) , [3413](https://github.com/Azure/sonic-buildimage/pull/3413) , [638](https://github.com/Azure/sonic-utilities/pull/638) , [642](https://github.com/Azure/sonic-utilities/pull/642) , [651](https://github.com/Azure/sonic-utilities/pull/651) | +
**Pull Requests** : [998](https://github.com/opencomputeproject/SAI/pull/998) , [284](https://github.com/sonic-net/sonic-swss-common/pull/284) , [969](https://github.com/sonic-net/sonic-swss/pull/969) , [871](https://github.com/sonic-net/sonic-swss/pull/871) , [3412](https://github.com/sonic-net/sonic-buildimage/pull/3412) , [3422](https://github.com/sonic-net/sonic-buildimage/pull/3422) , [3413](https://github.com/sonic-net/sonic-buildimage/pull/3413) , [638](https://github.com/sonic-net/sonic-utilities/pull/638) , [642](https://github.com/sonic-net/sonic-utilities/pull/642) , [651](https://github.com/sonic-net/sonic-utilities/pull/651) | #### Thermal control Thermal control daemon has been added to monitor the temperature of devices (CPU, ASIC, optical modules, etc) and the running status of fan. It retrieves the switch device temperatures via platform APIs and raises alarms when the high/low thresholds are hit.It also stores temperature values fetched from sensors and thermal device running status to the DB. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/thermal-control-design.md) for more details. -
**Pull Requests** : [73](https://github.com/Azure/sonic-platform-common/pull/73), [777](https://github.com/Azure/sonic-utilities/pull/777), [49](https://github.com/Azure/sonic-platform-daemons/pull/49), [3949](https://github.com/Azure/sonic-buildimage/pull/3949),[832](https://github.com/Azure/sonic-utilities/pull/832) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/thermal-control-design.md) for more details. +
**Pull Requests** : [73](https://github.com/sonic-net/sonic-platform-common/pull/73), [777](https://github.com/sonic-net/sonic-utilities/pull/777), [49](https://github.com/sonic-net/sonic-platform-daemons/pull/49), [3949](https://github.com/sonic-net/sonic-buildimage/pull/3949),[832](https://github.com/sonic-net/sonic-utilities/pull/832) #### VRF Sonic supports multiple loopback interfaces. Each loopback interfaces can belong to different VRF instances. In this feature we also support BGP and VRF support for FRR config template. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/doc/vrf/sonic-vrf-hld.md) for more details. -
**Pull Requests** : [3952](https://github.com/Azure/sonic-buildimage/pull/3952) , [943](https://github.com/Azure/sonic-swss/pull/943) , [1065](https://github.com/Azure/sonic-mgmt/pull/1065) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/doc/vrf/sonic-vrf-hld.md) for more details. +
**Pull Requests** : [3952](https://github.com/sonic-net/sonic-buildimage/pull/3952) , [943](https://github.com/sonic-net/sonic-swss/pull/943) , [1065](https://github.com/sonic-net/sonic-mgmt/pull/1065) #### ZTP Zero Touch Provisioning (ZTP) service can be used by users to configure a fleet of switches using common configuration templates. Switches booting from factory default state should be able to communicate with remote provisioning server and download relevant configuration files and scripts to kick start more complex configuration steps. ZTP service takes user input in JSON format. Some of the supported features are - Dynamically generate DHCP client configuration based on current ZTP state and Added support to request and process hostname when using DHCPv6. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/doc/ztp/ztp.md) for more details. -
**Pull Requests** : [3227](https://github.com/Azure/sonic-buildimage/pull/3227) , [3298](https://github.com/Azure/sonic-buildimage/pull/3298) , [1000](https://github.com/Azure/sonic-swss/pull/1000) , [3299](https://github.com/Azure/sonic-buildimage/pull/3299) , [12](https://github.com/Azure/sonic-ztp/pull/12), [599](https://github.com/Azure/sonic-utilities/pull/599) ,[715](https://github.com/Azure/sonic-utilities/pull/715) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/doc/ztp/ztp.md) for more details. +
**Pull Requests** : [3227](https://github.com/sonic-net/sonic-buildimage/pull/3227) , [3298](https://github.com/sonic-net/sonic-buildimage/pull/3298) , [1000](https://github.com/sonic-net/sonic-swss/pull/1000) , [3299](https://github.com/sonic-net/sonic-buildimage/pull/3299) , [12](https://github.com/sonic-net/sonic-ztp/pull/12), [599](https://github.com/sonic-net/sonic-utilities/pull/599) ,[715](https://github.com/sonic-net/sonic-utilities/pull/715)
diff --git a/doc/SONiC_202006_Release_Notes.md b/doc/SONiC_202006_Release_Notes.md index 6c22102412..e11fa3b06c 100644 --- a/doc/SONiC_202006_Release_Notes.md +++ b/doc/SONiC_202006_Release_Notes.md @@ -16,7 +16,7 @@ This document captures the new features added and enhancements done on existing # Branch and Image Location -Branch : https://github.com/Azure/sonic-buildimage/tree/202006
+Branch : https://github.com/sonic-net/sonic-buildimage/tree/202006
Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for Broadcom based platforms is [here]( https://sonic-jenkins.westus2.cloudapp.azure.com/job/broadcom/job/buildimage-brcm-202006/lastSuccessfulBuild/artifact/target/)) # Dependency Version @@ -33,7 +33,7 @@ Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for | syncd | 1.0.0 | | swss | 1.0.0 | | radvd | 2.17-2~bpo9+1 | -| isc-dhcp | 4.3.5-2 ([PR2946](https://github.com/Azure/sonic-buildimage/pull/2946) ) | +| isc-dhcp | 4.3.5-2 ([PR2946](https://github.com/sonic-net/sonic-buildimage/pull/2946) ) | | sonic-telemetry | 0.1 | | redis-server/ redis-tools | 5.0.3-3~bpo9+2 | @@ -49,72 +49,72 @@ Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for #### Build Improvements DPKG caching framework provides the infrastructure to cache the sonic module/target .deb files into a local cache by tracking the target dependency files.SONIC build infrastructure is designed as a plugin framework where any new source code can be easily integrated into sonic as a module and that generates output as a .deb file.This provides a huge improvement in build time and also supports the true incremental build by tracking the dependency files. -
**Pull Requests** : [3292](https://github.com/Azure/sonic-buildimage/pull/3292), [4117](https://github.com/Azure/sonic-buildimage/pull/4117), [4425](https://github.com/Azure/sonic-buildimage/pull/4425) +
**Pull Requests** : [3292](https://github.com/sonic-net/sonic-buildimage/pull/3292), [4117](https://github.com/sonic-net/sonic-buildimage/pull/4117), [4425](https://github.com/sonic-net/sonic-buildimage/pull/4425) #### Bulk API for route This feature provides bulk routes and next hop group members as coded in the PR mentioned below. -
**Pull Requests** : [1238](https://github.com/Azure/sonic-swss/pull/1238) +
**Pull Requests** : [1238](https://github.com/sonic-net/sonic-swss/pull/1238) #### D-Bus to Host Communications This document describes a means (framework) for an application executed inside a container to securely request the execution of an operation ("action") by the host OS.This framework is intended to be used by the SONiC management and telemetry containers, but can be extended for other application containers as well. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/mgmt/Docker%20to%20Host%20communication.md) and below mentioned PR's for more details. -
**Pull Requests** : [4840](https://github.com/Azure/sonic-buildimage/pull/4840) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/Docker%20to%20Host%20communication.md) and below mentioned PR's for more details. +
**Pull Requests** : [4840](https://github.com/sonic-net/sonic-buildimage/pull/4840) #### Debian 10 upgrade, base image,driver This feature provides change in kernel version. By changing the kernel ABI from version 6 to version 6-2, this will allow to disable the kernel ABI check which Debian performs at the very end of the kernel build. -
**Pull Requests** : [145](https://github.com/Azure/sonic-linux-kernel/pull/145), [4711](https://github.com/Azure/sonic-buildimage/pull/4711) +
**Pull Requests** : [145](https://github.com/sonic-net/sonic-linux-kernel/pull/145), [4711](https://github.com/sonic-net/sonic-buildimage/pull/4711) #### Dynamic port breakout Ports can be broken out to different speeds with various lanes in most HW today. However, on SONiC, before this release, the port breakout modes are hard-coded in the profiles and only loaded at initial time. In case we need to have a new port breakout mode, we would potentially need a new image or at least need to restart services which would impact the traffic of the box on irrelevant ports. The feature is to address the above issues. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [4235](https://github.com/Azure/sonic-buildimage/pull/4235), [3910](https://github.com/Azure/sonic-buildimage/pull/3910), [1242](https://github.com/Azure/sonic-swss/pull/1242), [1219](https://github.com/Azure/sonic-swss/pull/1219), [1151](https://github.com/Azure/sonic-swss/pull/1151), [1150](https://github.com/Azure/sonic-swss/pull/1150), [1148](https://github.com/Azure/sonic-swss/pull/1148), [1112](https://github.com/Azure/sonic-swss/pull/1112), [1085](https://github.com/Azure/sonic-swss/pull/1085), [766](https://github.com/Azure/sonic-utilities/pull/766), [72](https://github.com/Azure/sonic-platform-common/pull/72), [859](https://github.com/Azure/sonic-utilities/pull/859), [767](https://github.com/Azure/sonic-utilities/pull/767), [765](https://github.com/Azure/sonic-utilities/pull/765), [3912](https://github.com/Azure/sonic-buildimage/pull/3912), [3911](https://github.com/Azure/sonic-buildimage/pull/3911), [3909](https://github.com/Azure/sonic-buildimage/pull/3909), [3907](https://github.com/Azure/sonic-buildimage/pull/3907), [3891](https://github.com/Azure/sonic-buildimage/pull/3891), [3874](https://github.com/Azure/sonic-buildimage/pull/3874), [3861](https://github.com/Azure/sonic-buildimage/pull/3861), [3730](https://github.com/Azure/sonic-buildimage/pull/3730) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [4235](https://github.com/sonic-net/sonic-buildimage/pull/4235), [3910](https://github.com/sonic-net/sonic-buildimage/pull/3910), [1242](https://github.com/sonic-net/sonic-swss/pull/1242), [1219](https://github.com/sonic-net/sonic-swss/pull/1219), [1151](https://github.com/sonic-net/sonic-swss/pull/1151), [1150](https://github.com/sonic-net/sonic-swss/pull/1150), [1148](https://github.com/sonic-net/sonic-swss/pull/1148), [1112](https://github.com/sonic-net/sonic-swss/pull/1112), [1085](https://github.com/sonic-net/sonic-swss/pull/1085), [766](https://github.com/sonic-net/sonic-utilities/pull/766), [72](https://github.com/sonic-net/sonic-platform-common/pull/72), [859](https://github.com/sonic-net/sonic-utilities/pull/859), [767](https://github.com/sonic-net/sonic-utilities/pull/767), [765](https://github.com/sonic-net/sonic-utilities/pull/765), [3912](https://github.com/sonic-net/sonic-buildimage/pull/3912), [3911](https://github.com/sonic-net/sonic-buildimage/pull/3911), [3909](https://github.com/sonic-net/sonic-buildimage/pull/3909), [3907](https://github.com/sonic-net/sonic-buildimage/pull/3907), [3891](https://github.com/sonic-net/sonic-buildimage/pull/3891), [3874](https://github.com/sonic-net/sonic-buildimage/pull/3874), [3861](https://github.com/sonic-net/sonic-buildimage/pull/3861), [3730](https://github.com/sonic-net/sonic-buildimage/pull/3730) #### Egress shaping (port, queue) Quality of Service (QoS) scheduling and shaping features enable better service to certain traffic flows.Queue scheduling provides preferential treatment of traffic classes mapped to specific egress queues. SONiC supports SP, WRR, and DWRR scheduling disciplines.Queue shaping provides control of minimum and maximum bandwidth requirements per egress queue for more effective bandwidth utilization. Egress queues that exceed an average transmission rate beyond the shaper max bandwidth will stop being serviced. Additional ingress traffic will continue to be stored on the egress queue until the queue size is exceeded which results in tail drop. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/41e55d2762e9267454a4910b42a1eb7ad07acda8/doc/qos/scheduler/SONiC_QoS_Scheduler_Shaper.md) and below mentioned PR's for more details. -
**Pull Requests** : [1296](https://github.com/Azure/sonic-swss/pull/1296), [991](https://github.com/Azure/sonic-swss/pull/991) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/41e55d2762e9267454a4910b42a1eb7ad07acda8/doc/qos/scheduler/SONiC_QoS_Scheduler_Shaper.md) and below mentioned PR's for more details. +
**Pull Requests** : [1296](https://github.com/sonic-net/sonic-swss/pull/1296), [991](https://github.com/sonic-net/sonic-swss/pull/991) #### FW utils extension A modern network switch is a sophisticated equipment which consists of many auxiliary components which are responsible for managing different subsystems (e.g., PSU/FAN/QSFP/EEPROM/THERMAL) and providing necessary interfaces (e.g., I2C/SPI/JTAG).Basically these components are complex programmable logic devices with it's own HW architecture and software. It is very important to always have the latest recommended software version to improve device stability, security and performance. In order to make software update as simple as possible and to provide a nice user frindly interface for various maintenance operations (e.g., install a new FW or query current version) we might need a dedicated FW utility. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/fwutil/fwutil.md) and below mentioned PR's for more details. -
**Pull Requests** : [4764](https://github.com/Azure/sonic-buildimage/pull/4764), [4758](https://github.com/Azure/sonic-buildimage/pull/4758), [941](https://github.com/Azure/sonic-utilities/pull/941), [942](https://github.com/Azure/sonic-utilities/pull/942), [87](https://github.com/Azure/sonic-platform-common/pull/87), [82](https://github.com/Azure/sonic-platform-common/pull/82) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/fwutil/fwutil.md) and below mentioned PR's for more details. +
**Pull Requests** : [4764](https://github.com/sonic-net/sonic-buildimage/pull/4764), [4758](https://github.com/sonic-net/sonic-buildimage/pull/4758), [941](https://github.com/sonic-net/sonic-utilities/pull/941), [942](https://github.com/sonic-net/sonic-utilities/pull/942), [87](https://github.com/sonic-net/sonic-platform-common/pull/87), [82](https://github.com/sonic-net/sonic-platform-common/pull/82) #### Getting docker ready for Debian 10 This change adds support to build dockers using buster as base.sonic-mgmt-framework docker is updated to build using buster as base. -
**Pull Requests** : [4671](https://github.com/Azure/sonic-buildimage/pull/4671), [4727](https://github.com/Azure/sonic-buildimage/pull/4727), [4726](https://github.com/Azure/sonic-buildimage/pull/4726), [4665](https://github.com/Azure/sonic-buildimage/pull/4665), [4515](https://github.com/Azure/sonic-buildimage/pull/4515), [4598](https://github.com/Azure/sonic-buildimage/pull/4598), [4529](https://github.com/Azure/sonic-buildimage/pull/4529), [4480](https://github.com/Azure/sonic-buildimage/pull/4480) +
**Pull Requests** : [4671](https://github.com/sonic-net/sonic-buildimage/pull/4671), [4727](https://github.com/sonic-net/sonic-buildimage/pull/4727), [4726](https://github.com/sonic-net/sonic-buildimage/pull/4726), [4665](https://github.com/sonic-net/sonic-buildimage/pull/4665), [4515](https://github.com/sonic-net/sonic-buildimage/pull/4515), [4598](https://github.com/sonic-net/sonic-buildimage/pull/4598), [4529](https://github.com/sonic-net/sonic-buildimage/pull/4529), [4480](https://github.com/sonic-net/sonic-buildimage/pull/4480) #### Port Mirroring This feature describes the high level design details on Port/Port-channel mirroring support, dynamic session management, ACL rules can continue to use port/ERSPAN sessions as the action, Configuration CLI for mirror session. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/e8c86d1b3a03d6320727ff148966081869461e4a/doc/SONiC_Port_Mirroring_HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [1314](https://github.com/Azure/sonic-swss/pull/1314), [936](https://github.com/Azure/sonic-utilities/pull/936) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/e8c86d1b3a03d6320727ff148966081869461e4a/doc/SONiC_Port_Mirroring_HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [1314](https://github.com/sonic-net/sonic-swss/pull/1314), [936](https://github.com/sonic-net/sonic-utilities/pull/936) #### Proxy ARP When an interface is enabled with "proxy_arp", the same is enabled in the kernel. ASIC ARP packet action is also updated to trap these packets to CPU in those interfaces. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/doc/arp/Proxy%20Arp.md) for more details. -
**Pull Requests** : [617](https://github.com/Azure/SONiC/pull/617) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/doc/arp/Proxy%20Arp.md) for more details. +
**Pull Requests** : [617](https://github.com/sonic-net/SONiC/pull/617) #### Pytest 100% moved from ansible to Pytest #### SPytest This is an initial version of spytest framework and first set of test scripts for 202006 release. -
Refer [HLD Document](https://github.com/Azure/sonic-mgmt/blob/master/spytest/Doc/intro.md) for more details. -
**Pull Requests** : [1533](https://github.com/Azure/sonic-mgmt/pull/1533) +
Refer [HLD Document](https://github.com/sonic-net/sonic-mgmt/blob/master/spytest/Doc/intro.md) for more details. +
**Pull Requests** : [1533](https://github.com/sonic-net/sonic-mgmt/pull/1533) #### Thermal control Thermal control daemon has been added to monitor the temperature of devices (CPU, ASIC, optical modules, etc) and the running status of fan. It retrieves the switch device temperatures via platform APIs and raises alarms when the high/low thresholds are hit.It also stores temperature values fetched from sensors and thermal device running status to the DB.In addition it provides the policy based thermal control and fan speed tuning in configuration, and we are able to customize and/or add the platform specific policies as needed. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/thermal-control-design.md) for more details. -
**Pull Requests** : [73](https://github.com/Azure/sonic-platform-common/pull/73), [777](https://github.com/Azure/sonic-utilities/pull/777), [49](https://github.com/Azure/sonic-platform-daemons/pull/49), [3949](https://github.com/Azure/sonic-buildimage/pull/3949),[832](https://github.com/Azure/sonic-utilities/pull/832) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/thermal-control-design.md) for more details. +
**Pull Requests** : [73](https://github.com/sonic-net/sonic-platform-common/pull/73), [777](https://github.com/sonic-net/sonic-utilities/pull/777), [49](https://github.com/sonic-net/sonic-platform-daemons/pull/49), [3949](https://github.com/sonic-net/sonic-buildimage/pull/3949),[832](https://github.com/sonic-net/sonic-utilities/pull/832) #### PSU and FAN LED management The PSU and FAN LED on switch will be set according to PSU and FAN presence and running status, for example if there is a failure happening to PSU or FAN, the corresponding LED will be set to red. -
Refer [HLD Document](https://github.com/Azure/SONiC/blob/master/thermal-control-design.md) and [HLD Document](https://github.com/Azure/SONiC/pull/591) for more details. -
**Pull Requests** : [4437](https://github.com/Azure/sonic-buildimage/pull/4437);[1580](https://github.com/Azure/sonic-mgmt/pull/1580);[881](https://github.com/Azure/sonic-utilities/pull/881);[54](https://github.com/Azure/sonic-platform-daemons/pull/54);[83](https://github.com/Azure/sonic-platform-common/pull/83) +
Refer [HLD Document](https://github.com/sonic-net/SONiC/blob/master/thermal-control-design.md) and [HLD Document](https://github.com/sonic-net/SONiC/pull/591) for more details. +
**Pull Requests** : [4437](https://github.com/sonic-net/sonic-buildimage/pull/4437);[1580](https://github.com/sonic-net/sonic-mgmt/pull/1580);[881](https://github.com/sonic-net/sonic-utilities/pull/881);[54](https://github.com/sonic-net/sonic-platform-daemons/pull/54);[83](https://github.com/sonic-net/sonic-platform-common/pull/83) #### PSU, thermal and FAN plugin extension On new plugins for fan, thermal and PSU the PSU plugin was extended with voltage, current and power supported, and the fan and thermal plugins were introduced. -
**Pull Requests** : [4041](https://github.com/Azure/sonic-buildimage/pull/4041) +
**Pull Requests** : [4041](https://github.com/sonic-net/sonic-buildimage/pull/4041) diff --git a/doc/SONiC_202012_Release_Notes.md b/doc/SONiC_202012_Release_Notes.md index 9eb3aa306e..053c1c6d23 100644 --- a/doc/SONiC_202012_Release_Notes.md +++ b/doc/SONiC_202012_Release_Notes.md @@ -16,7 +16,7 @@ This document captures the new features added and enhancements done on existing # Branch and Image Location -Branch : https://github.com/Azure/sonic-buildimage/tree/202012
+Branch : https://github.com/sonic-net/sonic-buildimage/tree/202012
Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for Broadcom based platforms is [here]( https://sonic-jenkins.westus2.cloudapp.azure.com/job/broadcom/job/buildimage-brcm-202012/lastSuccessfulBuild/artifact/target/)) # Dependency Version @@ -50,56 +50,56 @@ Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for #### Consistent ECMP support (fine grain ECMP) This feature is to modify the behavior of ECMP to achieve fine grained handling of ECMP for a specifically identified prefix and associated next-hops in configuration.
Refer [HLD document](https://github.com/anish-n/SONiC/blob/e5cdb3d9337026a98d6be5d558126926a4e959e4/doc/ecmp/fine_grained_next_hop_hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [1315](https://github.com/Azure/sonic-swss/pull/1315), [623](https://github.com/Azure/SONiC/pull/623), [1788](https://github.com/Azure/sonic-mgmt/pull/1788), [4985](https://github.com/Azure/sonic-buildimage/pull/4985), [374](https://github.com/Azure/sonic-swss-common/pull/374), [659](https://github.com/Azure/SONiC/pull/659), [1056](https://github.com/Azure/sonic-utilities/pull/1056), [5518](https://github.com/Azure/sonic-buildimage/pull/5518), [5198](https://github.com/Azure/sonic-buildimage/pull/5198), [693](https://github.com/Azure/SONiC/pull/693). +
**Pull Requests** : [1315](https://github.com/sonic-net/sonic-swss/pull/1315), [623](https://github.com/sonic-net/SONiC/pull/623), [1788](https://github.com/sonic-net/sonic-mgmt/pull/1788), [4985](https://github.com/sonic-net/sonic-buildimage/pull/4985), [374](https://github.com/sonic-net/sonic-swss-common/pull/374), [659](https://github.com/sonic-net/SONiC/pull/659), [1056](https://github.com/sonic-net/sonic-utilities/pull/1056), [5518](https://github.com/sonic-net/sonic-buildimage/pull/5518), [5198](https://github.com/sonic-net/sonic-buildimage/pull/5198), [693](https://github.com/sonic-net/SONiC/pull/693). #### Container warm restart (BGP/TeamD/SWSS/SyncD) The goal of SONiC warm reboot is to be able restart and upgrade SONiC software without impacting the data plane. Warm restart of each individual process/docker is also part of the goal. Except for syncd and database docker, it is desired for all other network applications and dockers to support un-planned warm restart. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/0c177995044316b898fc355456d9b6e8df72b522/doc/warm-reboot/SONiC_Warmboot.md) and below mentioned PR's for more details. -
**Pull Requests** : [3992](https://github.com/Azure/sonic-buildimage/pull/3992), [5233](https://github.com/Azure/sonic-buildimage/pull/5233),[5163](https://github.com/Azure/sonic-buildimage/pull/5163/files), [5108](https://github.com/Azure/sonic-buildimage/pull/5108/files) & [1036](https://github.com/Azure/sonic-utilities/pull/1036/files). +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/0c177995044316b898fc355456d9b6e8df72b522/doc/warm-reboot/SONiC_Warmboot.md) and below mentioned PR's for more details. +
**Pull Requests** : [3992](https://github.com/sonic-net/sonic-buildimage/pull/3992), [5233](https://github.com/sonic-net/sonic-buildimage/pull/5233),[5163](https://github.com/sonic-net/sonic-buildimage/pull/5163/files), [5108](https://github.com/sonic-net/sonic-buildimage/pull/5108/files) & [1036](https://github.com/sonic-net/sonic-utilities/pull/1036/files). #### CoPP Config/Management During SWSS start, the prebuilt copp.json file is loaded as part of start script swssconfig.sh and written to APP_DB. CoppOrch then translates it to Host trap/policer tables and programmed to SAI. With this enhancement, the CoPP tables shall be loaded to Config_DB instead of APP_DB. The default CoPP json file shall be prebuilt to the image and loaded during initialization. Any Config_DB entries present shall be configured overwriting the default CoPP tables. This also ensures backward compatibility. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/fdc7cff16b7f42f1a1b01dd506279e3e9f9269cb/doc/copp/CoPP%20Config%20and%20Management.md) and below mentioned PR's for more details. -
**Pull Requests** : [358](https://github.com/Azure/sonic-swss-common/pull/358), [1333](https://github.com/Azure/sonic-swss/pull/1333), [4861](https://github.com/Azure/sonic-buildimage/pull/4861) & [1004](https://github.com/Azure/sonic-utilities/pull/1004) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/fdc7cff16b7f42f1a1b01dd506279e3e9f9269cb/doc/copp/CoPP%20Config%20and%20Management.md) and below mentioned PR's for more details. +
**Pull Requests** : [358](https://github.com/sonic-net/sonic-swss-common/pull/358), [1333](https://github.com/sonic-net/sonic-swss/pull/1333), [4861](https://github.com/sonic-net/sonic-buildimage/pull/4861) & [1004](https://github.com/sonic-net/sonic-utilities/pull/1004) #### Console Support for SONiC (Hardware) This is a feature to support SONiC for hardware console. -
**Pull Requests** :[5571](https://github.com/Azure/sonic-buildimage/pull/5571) & [1155](https://github.com/Azure/sonic-utilities/pull/1155) +
**Pull Requests** :[5571](https://github.com/sonic-net/sonic-buildimage/pull/5571) & [1155](https://github.com/sonic-net/sonic-utilities/pull/1155) #### Console Support for SONiC (SSH forwarding) This feature describes the persistent console configurations to control how to view/connect to a device via serial link. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/126a4f7af8cadd8451b22bd80227c07c11452a63/doc/console/SONiC-Console-Switch-High-Level-Design.md) and below mentioned PR's for more details. -
**Pull Requests** : [664](https://github.com/Azure/SONiC/pull/664), [673](https://github.com/Azure/SONiC/pull/673) ,[1117](https://github.com/Azure/sonic-utilities/pull/1117) , [1120](https://github.com/Azure/sonic-utilities/pull/1120), [1130](https://github.com/Azure/sonic-utilities/pull/1130) ,[1136](https://github.com/Azure/sonic-utilities/pull/1136) , [1166](https://github.com/Azure/sonic-utilities/pull/1166) , [1173](https://github.com/Azure/sonic-utilities/pull/1173), [1176](https://github.com/Azure/sonic-utilities/pull/1176) , [5438](https://github.com/Azure/sonic-buildimage/pull/5438) & [5717](https://github.com/Azure/sonic-buildimage/pull/5717). +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/126a4f7af8cadd8451b22bd80227c07c11452a63/doc/console/SONiC-Console-Switch-High-Level-Design.md) and below mentioned PR's for more details. +
**Pull Requests** : [664](https://github.com/sonic-net/SONiC/pull/664), [673](https://github.com/sonic-net/SONiC/pull/673) ,[1117](https://github.com/sonic-net/sonic-utilities/pull/1117) , [1120](https://github.com/sonic-net/sonic-utilities/pull/1120), [1130](https://github.com/sonic-net/sonic-utilities/pull/1130) ,[1136](https://github.com/sonic-net/sonic-utilities/pull/1136) , [1166](https://github.com/sonic-net/sonic-utilities/pull/1166) , [1173](https://github.com/sonic-net/sonic-utilities/pull/1173), [1176](https://github.com/sonic-net/sonic-utilities/pull/1176) , [5438](https://github.com/sonic-net/sonic-buildimage/pull/5438) & [5717](https://github.com/sonic-net/sonic-buildimage/pull/5717). #### Dynamic headroom calculation This feature defines the solution on how the headroom is calculated by the well known formula based upon with the cable length and speed as input. Arbitrary cable length will be supported. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/415f19931bccd900ac528b100aafffa6000e82e9/doc/qos/dynamically-headroom-calculation.md) and below mentioned PR's for more details. -
**Pull Requests** : [1338](https://github.com/Azure/sonic-swss/pull/1338), [973](https://github.com/Azure/sonic-utilities/pull/973), [4881](https://github.com/Azure/sonic-buildimage/pull/4881), [1971](https://github.com/Azure/sonic-mgmt/pull/1971), [361](https://github.com/Azure/sonic-swss-common/pull/361) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/415f19931bccd900ac528b100aafffa6000e82e9/doc/qos/dynamically-headroom-calculation.md) and below mentioned PR's for more details. +
**Pull Requests** : [1338](https://github.com/sonic-net/sonic-swss/pull/1338), [973](https://github.com/sonic-net/sonic-utilities/pull/973), [4881](https://github.com/sonic-net/sonic-buildimage/pull/4881), [1971](https://github.com/sonic-net/sonic-mgmt/pull/1971), [361](https://github.com/sonic-net/sonic-swss-common/pull/361) #### Enable synchronous SAI APIs (error handling) This feature enables the synchronous mode for a closed-loop execution, if SAI APIs are called from the orchagent. In contrast to the previous asynchronous mode which cannot properly handle SAI API failures, the synchronous mode can gracefully handle SAI API failures by conducting the proper actions in orchagent. Therefore, the synchronous mode can substantially improve the reliability of SONiC.
Refer [HLD document](https://github.com/shi-su/SONiC/blob/61762c8e709ead5f8ee7df83facea6ceee9de6f5/doc/synchronous-mode/synchronous-mode-cfg.md) and below mentioned PR's for more details. -
**Pull Requests** : [5237](https://github.com/Azure/sonic-buildimage/pull/5237) , [650](https://github.com/Azure/sonic-buildimage/pull/650) , [652](https://github.com/Azure/sonic-buildimage/pull/652) , [653](https://github.com/Azure/sonic-buildimage/pull/653), [1094](https://github.com/Azure/sonic-utilities/pull/1094) & [5308](https://github.com/Azure/sonic-buildimage/pull/5308). +
**Pull Requests** : [5237](https://github.com/sonic-net/sonic-buildimage/pull/5237) , [650](https://github.com/sonic-net/sonic-buildimage/pull/650) , [652](https://github.com/sonic-net/sonic-buildimage/pull/652) , [653](https://github.com/sonic-net/sonic-buildimage/pull/653), [1094](https://github.com/sonic-net/sonic-utilities/pull/1094) & [5308](https://github.com/sonic-net/sonic-buildimage/pull/5308). #### EVPN/VXLAN This feature provides information about the EVPN VXLAN feature implementation based on RFC 7432 BGP EVPN solution over VXLAN tunnels for SONiC, including support for L2 and L3 VPN services, auto discovery of remote VTEPs, auto provisioning of tunnels and VLANs over VXLAN tunnels, control plane MAC learning and ARP suppression for reduced flooding, and support for VM mobility. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/7fbda34ee3315960c164a0c202f39c2ec515cfc3/doc/vxlan/EVPN/EVPN_VXLAN_HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [339](https://github.com/Azure/sonic-swss-common/pull/339) ,[350](https://github.com/Azure/sonic-swss-common/pull/350) , [1264](https://github.com/Azure/sonic-swss/pull/1264) , [1266](https://github.com/Azure/sonic-swss/pull/1266) , [1318](https://github.com/Azure/sonic-swss/pull/1318) , [1267](https://github.com/Azure/sonic-swss/pull/1267) & [870](https://github.com/Azure/sonic-utilities/pull/870). +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/7fbda34ee3315960c164a0c202f39c2ec515cfc3/doc/vxlan/EVPN/EVPN_VXLAN_HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [339](https://github.com/sonic-net/sonic-swss-common/pull/339) ,[350](https://github.com/sonic-net/sonic-swss-common/pull/350) , [1264](https://github.com/sonic-net/sonic-swss/pull/1264) , [1266](https://github.com/sonic-net/sonic-swss/pull/1266) , [1318](https://github.com/sonic-net/sonic-swss/pull/1318) , [1267](https://github.com/sonic-net/sonic-swss/pull/1267) & [870](https://github.com/sonic-net/sonic-utilities/pull/870). #### SONiC entity MIB extensions The Entity MIB contains several groups of MIB objects: entityPhysical group, entityLogical group and so on. Previously, SONiC only implemented part of the entityPhysical group following RFC2737. Since entityPhysical group is most commonly used, this extension will focus on entityPhysical group and leave other groups for future implementation. The group entityPhysical contains a single table called "entPhysicalTable" to identify the physical components of the system. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/0e53548a8f1023d1be2a1dffd62737c7a1b18a2e/doc/snmp/extension-to-physical-entity-mib.md) and below mentioned PR's for more details. -
**Pull Requests** : [134](https://github.com/Azure/sonic-platform-common/pull/134), [102](https://github.com/Azure/sonic-platform-daemons/pull/102), [5645](https://github.com/Azure/sonic-buildimage/pull/5645), [168](https://github.com/Azure/sonic-snmpagent/pull/168) & [2379](https://github.com/Azure/sonic-mgmt/pull/2379) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/0e53548a8f1023d1be2a1dffd62737c7a1b18a2e/doc/snmp/extension-to-physical-entity-mib.md) and below mentioned PR's for more details. +
**Pull Requests** : [134](https://github.com/sonic-net/sonic-platform-common/pull/134), [102](https://github.com/sonic-net/sonic-platform-daemons/pull/102), [5645](https://github.com/sonic-net/sonic-buildimage/pull/5645), [168](https://github.com/sonic-net/sonic-snmpagent/pull/168) & [2379](https://github.com/sonic-net/sonic-mgmt/pull/2379) #### FRR BGP NBI This feature extends and provides unified configuration and management capability for FRR-BGP features used in SONiC.This enhancement is to load any BGP/route-map configurations from config-DB as well independent of mgmt-framework NBI, the main change here is to add CONFIB_DB entries for FRR management into SONiC, and the ability to apply this config to FRR. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/48e9012c548528b6528745bda9d75b4164e785eb/doc/mgmt/SONiC_Design_Doc_Unified_FRR_Mgmt_Interface.md) and below mentioned PR's for more details. -
**Pull Requests** : [5142](https://github.com/Azure/sonic-buildimage/pull/5142) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/48e9012c548528b6528745bda9d75b4164e785eb/doc/mgmt/SONiC_Design_Doc_Unified_FRR_Mgmt_Interface.md) and below mentioned PR's for more details. +
**Pull Requests** : [5142](https://github.com/sonic-net/sonic-buildimage/pull/5142) #### Gearbox This feature is a design change that allows the PHY drivers to be separated from the Switch driver (SAI) by introducing a new driver API for PHYs. This allows diverse, multi-vendor hardware to be more easily supported. This change adds usage capability of this new interface to SONiC. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/gearbox/gearbox_mgr_design.md) and below mentioned PR's for more details. -
**Pull Requests** : [347](https://github.com/Azure/sonic-swss-common/pull/347), [931](https://github.com/Azure/sonic-utilities/pull/931), [1321](https://github.com/Azure/sonic-swss/pull/1321), [624](https://github.com/Azure/sonic-sairedis/pull/624) & [4851](https://github.com/Azure/sonic-buildimage/pull/4851). +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/gearbox/gearbox_mgr_design.md) and below mentioned PR's for more details. +
**Pull Requests** : [347](https://github.com/sonic-net/sonic-swss-common/pull/347), [931](https://github.com/sonic-net/sonic-utilities/pull/931), [1321](https://github.com/sonic-net/sonic-swss/pull/1321), [624](https://github.com/sonic-net/sonic-sairedis/pull/624) & [4851](https://github.com/sonic-net/sonic-buildimage/pull/4851). #### Kubernetes (docker to be controlled by Kubernetes) This feature deals in depth with kubernetes-support. With this feature, an image could be downloaded from external repositaries and kubernetes does the deployment. The external Kubernetes masters could be used to deploy container image updates at a massive scale, through manifests. This new mode is referred as "kubernetes mode". @@ -119,7 +119,7 @@ If you have an infrastructure that runs kubernetes master cluster, then you coul - With image pull secrets provided - You may create secret to access your repo and make it default across all
Refer [HLD document](https://github.com/renukamanavalan/SONiC/blob/kube_systemd/doc/kubernetes/Kubernetes-support.md) and below mentioned PR's for more details. -
**Pull Requests** : [4825](https://github.com/Azure/sonic-buildimage/pull/4825), [4895](https://github.com/Azure/sonic-buildimage/pull/4895), [4926](https://github.com/Azure/sonic-buildimage/pull/4926), [4932](https://github.com/Azure/sonic-buildimage/pull/4932), [4959](https://github.com/Azure/sonic-buildimage/pull/4959), [4973](https://github.com/Azure/sonic-buildimage/pull/4973), [5022](https://github.com/Azure/sonic-buildimage/pull/5022), [5113](https://github.com/Azure/sonic-buildimage/pull/5113), [5121](https://github.com/Azure/sonic-buildimage/pull/5121), [5122](https://github.com/Azure/sonic-buildimage/pull/5122), [5202](https://github.com/Azure/sonic-buildimage/pull/5202), [5221](https://github.com/Azure/sonic-buildimage/pull/5221), [5224](https://github.com/Azure/sonic-buildimage/pull/5224), [5235](https://github.com/Azure/sonic-buildimage/pull/5235), [5316](https://github.com/Azure/sonic-buildimage/pull/5316), [5329](https://github.com/Azure/sonic-buildimage/pull/5329), [5357](https://github.com/Azure/sonic-buildimage/pull/5357), [5358](https://github.com/Azure/sonic-buildimage/pull/5358), [5364](https://github.com/Azure/sonic-buildimage/pull/5364),[5418](https://github.com/Azure/sonic-buildimage/pull/5418), [5420](https://github.com/Azure/sonic-buildimage/pull/5420), [5436](https://github.com/Azure/sonic-buildimage/pull/5436), [5437](https://github.com/Azure/sonic-buildimage/pull/5437), [5446](https://github.com/Azure/sonic-buildimage/pull/5446), [5460](https://github.com/Azure/sonic-buildimage/pull/5460), [5479](https://github.com/Azure/sonic-buildimage/pull/5479), [5503](https://github.com/Azure/sonic-buildimage/pull/5503), [5548](https://github.com/Azure/sonic-buildimage/pull/5548), [87](https://github.com/Azure/sonic-platform-daemons/pull/87), [81](https://github.com/Azure/sonic-py-swsssdk/pull/81), [138](https://github.com/Azure/sonic-snmpagent/pull/138), [140](https://github.com/Azure/sonic-snmpagent/pull/140), [141](https://github.com/Azure/sonic-snmpagent/pull/141), [145](https://github.com/Azure/sonic-snmpagent/pull/145), [154](https://github.com/Azure/sonic-snmpagent/pull/154), [155](https://github.com/Azure/sonic-snmpagent/pull/155), [158](https://github.com/Azure/sonic-snmpagent/pull/158), [161](https://github.com/Azure/sonic-snmpagent/pull/161), [166](https://github.com/Azure/sonic-snmpagent/pull/166), [376](https://github.com/Azure/sonic-swss-common/pull/376), [856](https://github.com/Azure/sonic-utilities/pull/856), [917](https://github.com/Azure/sonic-utilities/pull/917), [978](https://github.com/Azure/sonic-utilities/pull/978), [999](https://github.com/Azure/sonic-utilities/pull/999), [1005](https://github.com/Azure/sonic-utilities/pull/1005), [1006](https://github.com/Azure/sonic-utilities/pull/1006), [1013](https://github.com/Azure/sonic-utilities/pull/1013), [1057](https://github.com/Azure/sonic-utilities/pull/1057), [1064](https://github.com/Azure/sonic-utilities/pull/1064), [1079](https://github.com/Azure/sonic-utilities/pull/1079), [1080](https://github.com/Azure/sonic-utilities/pull/1080), [1081](https://github.com/Azure/sonic-utilities/pull/1081), [1123](https://github.com/Azure/sonic-utilities/pull/1123) & [1137](https://github.com/Azure/sonic-utilities/pull/1137) [1127](https://github.com/Azure/sonic-utilities/pull/1127) +
**Pull Requests** : [4825](https://github.com/sonic-net/sonic-buildimage/pull/4825), [4895](https://github.com/sonic-net/sonic-buildimage/pull/4895), [4926](https://github.com/sonic-net/sonic-buildimage/pull/4926), [4932](https://github.com/sonic-net/sonic-buildimage/pull/4932), [4959](https://github.com/sonic-net/sonic-buildimage/pull/4959), [4973](https://github.com/sonic-net/sonic-buildimage/pull/4973), [5022](https://github.com/sonic-net/sonic-buildimage/pull/5022), [5113](https://github.com/sonic-net/sonic-buildimage/pull/5113), [5121](https://github.com/sonic-net/sonic-buildimage/pull/5121), [5122](https://github.com/sonic-net/sonic-buildimage/pull/5122), [5202](https://github.com/sonic-net/sonic-buildimage/pull/5202), [5221](https://github.com/sonic-net/sonic-buildimage/pull/5221), [5224](https://github.com/sonic-net/sonic-buildimage/pull/5224), [5235](https://github.com/sonic-net/sonic-buildimage/pull/5235), [5316](https://github.com/sonic-net/sonic-buildimage/pull/5316), [5329](https://github.com/sonic-net/sonic-buildimage/pull/5329), [5357](https://github.com/sonic-net/sonic-buildimage/pull/5357), [5358](https://github.com/sonic-net/sonic-buildimage/pull/5358), [5364](https://github.com/sonic-net/sonic-buildimage/pull/5364),[5418](https://github.com/sonic-net/sonic-buildimage/pull/5418), [5420](https://github.com/sonic-net/sonic-buildimage/pull/5420), [5436](https://github.com/sonic-net/sonic-buildimage/pull/5436), [5437](https://github.com/sonic-net/sonic-buildimage/pull/5437), [5446](https://github.com/sonic-net/sonic-buildimage/pull/5446), [5460](https://github.com/sonic-net/sonic-buildimage/pull/5460), [5479](https://github.com/sonic-net/sonic-buildimage/pull/5479), [5503](https://github.com/sonic-net/sonic-buildimage/pull/5503), [5548](https://github.com/sonic-net/sonic-buildimage/pull/5548), [87](https://github.com/sonic-net/sonic-platform-daemons/pull/87), [81](https://github.com/sonic-net/sonic-py-swsssdk/pull/81), [138](https://github.com/sonic-net/sonic-snmpagent/pull/138), [140](https://github.com/sonic-net/sonic-snmpagent/pull/140), [141](https://github.com/sonic-net/sonic-snmpagent/pull/141), [145](https://github.com/sonic-net/sonic-snmpagent/pull/145), [154](https://github.com/sonic-net/sonic-snmpagent/pull/154), [155](https://github.com/sonic-net/sonic-snmpagent/pull/155), [158](https://github.com/sonic-net/sonic-snmpagent/pull/158), [161](https://github.com/sonic-net/sonic-snmpagent/pull/161), [166](https://github.com/sonic-net/sonic-snmpagent/pull/166), [376](https://github.com/sonic-net/sonic-swss-common/pull/376), [856](https://github.com/sonic-net/sonic-utilities/pull/856), [917](https://github.com/sonic-net/sonic-utilities/pull/917), [978](https://github.com/sonic-net/sonic-utilities/pull/978), [999](https://github.com/sonic-net/sonic-utilities/pull/999), [1005](https://github.com/sonic-net/sonic-utilities/pull/1005), [1006](https://github.com/sonic-net/sonic-utilities/pull/1006), [1013](https://github.com/sonic-net/sonic-utilities/pull/1013), [1057](https://github.com/sonic-net/sonic-utilities/pull/1057), [1064](https://github.com/sonic-net/sonic-utilities/pull/1064), [1079](https://github.com/sonic-net/sonic-utilities/pull/1079), [1080](https://github.com/sonic-net/sonic-utilities/pull/1080), [1081](https://github.com/sonic-net/sonic-utilities/pull/1081), [1123](https://github.com/sonic-net/sonic-utilities/pull/1123) & [1137](https://github.com/sonic-net/sonic-utilities/pull/1137) [1127](https://github.com/sonic-net/sonic-utilities/pull/1127) #### Management Framework (Phase 2) The SONiC Management Framework provides a unified UI stack, enabling SONiC to be managed through an Industry-standard CLI, RESTCONF and gNMI (using OpenConfig data models). It also offers a rapid development environment for these user-interfaces, based upon automatic code generation from YANG models. @@ -134,45 +134,45 @@ This set of enhancements extends the framework, including (but not limited to) t - Advance to Python 3.7 - Use of DBus for communication into the host - Build enhancements -
Refer [HLD document](https://github.com/Azure/SONiC/blob/34cac1aabdc865fc41cbe064a2ab2442645524b1/doc/mgmt/Management%20Framework.md) and below mentioned PR's for more details. -
**Pull Requests** : [4799](https://github.com/Azure/sonic-buildimage/pull/4799),[4765](https://github.com/Azure/sonic-buildimage/pull/4765),[4840](https://github.com/Azure/sonic-buildimage/pull/4840),[35](https://github.com/Azure/sonic-telemetry/pull/35), [38](https://github.com/Azure/sonic-telemetry/pull/38),[126](https://github.com/Azure/sonic-build-tools/pull/126), [170](https://github.com/Azure/sonic-build-tools/pull/170), [10](https://github.com/Azure/sonic-mgmt-common/pull/10),[11](https://github.com/Azure/sonic-mgmt-common/pull/11), [12](https://github.com/Azure/sonic-mgmt-common/pull/12), [13](https://github.com/Azure/sonic-mgmt-common/pull/13), [15](https://github.com/Azure/sonic-mgmt-common/pull/15), [16](https://github.com/Azure/sonic-mgmt-common/pull/16), [18](https://github.com/Azure/sonic-mgmt-common/pull/18), [19](https://github.com/Azure/sonic-mgmt-common/pull/19), [20](https://github.com/Azure/sonic-mgmt-common/pull/20), [21](https://github.com/Azure/sonic-mgmt-common/pull/21), [22](https://github.com/Azure/sonic-mgmt-common/pull/22), [23](https://github.com/Azure/sonic-mgmt-common/pull/23), [26](https://github.com/Azure/sonic-mgmt-common/pull/26), [27](https://github.com/Azure/sonic-mgmt-common/pull/27), [28](https://github.com/Azure/sonic-mgmt-common/pull/28), [31](https://github.com/Azure/sonic-mgmt-common/pull/31), [32](https://github.com/Azure/sonic-mgmt-common/pull/32), [34](https://github.com/Azure/sonic-mgmt-common/pull/34), [35](https://github.com/Azure/sonic-mgmt-common/pull/35), [50](https://github.com/Azure/sonic-mgmt-framework/pull/50), [51](https://github.com/Azure/sonic-mgmt-framework/pull/51),[52](https://github.com/Azure/sonic-mgmt-framework/pull/52), [53](https://github.com/Azure/sonic-mgmt-framework/pull/65), [57](https://github.com/Azure/sonic-mgmt-framework/pull/57), [60](https://github.com/Azure/sonic-mgmt-framework/pull/60),[65](https://github.com/Azure/sonic-mgmt-framework/pull/65), [66](https://github.com/Azure/sonic-mgmt-framework/pull/66), [67](https://github.com/Azure/sonic-mgmt-framework/pull/67), [68](https://github.com/Azure/sonic-mgmt-framework/pull/68), [69](https://github.com/Azure/sonic-mgmt-framework/pull/69),[71](https://github.com/Azure/sonic-mgmt-framework/pull/71), [5810](https://github.com/Azure/sonic-buildimage/pull/5810),[5920](https://github.com/Azure/sonic-buildimage/pull/5920),[72](https://github.com/Azure/sonic-mgmt-framework/pull/72), [73](https://github.com/Azure/sonic-mgmt-framework/pull/73), [5714](https://github.com/Azure/sonic-buildimage/pull/5714),[61](https://github.com/Azure/sonic-telemetry/pull/61) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/34cac1aabdc865fc41cbe064a2ab2442645524b1/doc/mgmt/Management%20Framework.md) and below mentioned PR's for more details. +
**Pull Requests** : [4799](https://github.com/sonic-net/sonic-buildimage/pull/4799),[4765](https://github.com/sonic-net/sonic-buildimage/pull/4765),[4840](https://github.com/sonic-net/sonic-buildimage/pull/4840),[35](https://github.com/sonic-net/sonic-gnmi/pull/35), [38](https://github.com/sonic-net/sonic-gnmi/pull/38),[126](https://github.com/Azure/sonic-build-tools/pull/126), [170](https://github.com/Azure/sonic-build-tools/pull/170), [10](https://github.com/sonic-net/sonic-mgmt-common/pull/10),[11](https://github.com/sonic-net/sonic-mgmt-common/pull/11), [12](https://github.com/sonic-net/sonic-mgmt-common/pull/12), [13](https://github.com/sonic-net/sonic-mgmt-common/pull/13), [15](https://github.com/sonic-net/sonic-mgmt-common/pull/15), [16](https://github.com/sonic-net/sonic-mgmt-common/pull/16), [18](https://github.com/sonic-net/sonic-mgmt-common/pull/18), [19](https://github.com/sonic-net/sonic-mgmt-common/pull/19), [20](https://github.com/sonic-net/sonic-mgmt-common/pull/20), [21](https://github.com/sonic-net/sonic-mgmt-common/pull/21), [22](https://github.com/sonic-net/sonic-mgmt-common/pull/22), [23](https://github.com/sonic-net/sonic-mgmt-common/pull/23), [26](https://github.com/sonic-net/sonic-mgmt-common/pull/26), [27](https://github.com/sonic-net/sonic-mgmt-common/pull/27), [28](https://github.com/sonic-net/sonic-mgmt-common/pull/28), [31](https://github.com/sonic-net/sonic-mgmt-common/pull/31), [32](https://github.com/sonic-net/sonic-mgmt-common/pull/32), [34](https://github.com/sonic-net/sonic-mgmt-common/pull/34), [35](https://github.com/sonic-net/sonic-mgmt-common/pull/35), [50](https://github.com/sonic-net/sonic-mgmt-framework/pull/50), [51](https://github.com/sonic-net/sonic-mgmt-framework/pull/51),[52](https://github.com/sonic-net/sonic-mgmt-framework/pull/52), [53](https://github.com/sonic-net/sonic-mgmt-framework/pull/65), [57](https://github.com/sonic-net/sonic-mgmt-framework/pull/57), [60](https://github.com/sonic-net/sonic-mgmt-framework/pull/60),[65](https://github.com/sonic-net/sonic-mgmt-framework/pull/65), [66](https://github.com/sonic-net/sonic-mgmt-framework/pull/66), [67](https://github.com/sonic-net/sonic-mgmt-framework/pull/67), [68](https://github.com/sonic-net/sonic-mgmt-framework/pull/68), [69](https://github.com/sonic-net/sonic-mgmt-framework/pull/69),[71](https://github.com/sonic-net/sonic-mgmt-framework/pull/71), [5810](https://github.com/sonic-net/sonic-buildimage/pull/5810),[5920](https://github.com/sonic-net/sonic-buildimage/pull/5920),[72](https://github.com/sonic-net/sonic-mgmt-framework/pull/72), [73](https://github.com/sonic-net/sonic-mgmt-framework/pull/73), [5714](https://github.com/sonic-net/sonic-buildimage/pull/5714),[61](https://github.com/sonic-net/sonic-gnmi/pull/61) #### Merge common lib for C++ and python (SWSS common lib) This is a fix for common lib and associated files. -
**Pull Requests** : [378](https://github.com/Azure/sonic-swss-common/pull/378) +
**Pull Requests** : [378](https://github.com/sonic-net/sonic-swss-common/pull/378) #### Move from Python2->python3 This is inline as part of moving all SONiC code from Python 2 (no longer supported) to Python 3. -
**Pull Requests** : [5886](https://github.com/Azure/sonic-buildimage/pull/5886), [6038](https://github.com/Azure/sonic-buildimage/pull/6038), [6162](https://github.com/Azure/sonic-buildimage/pull/6162), [6176](https://github.com/Azure/sonic-buildimage/pull/6176), [1542](https://github.com/Azure/sonic-swss/pull/1542) +
**Pull Requests** : [5886](https://github.com/sonic-net/sonic-buildimage/pull/5886), [6038](https://github.com/sonic-net/sonic-buildimage/pull/6038), [6162](https://github.com/sonic-net/sonic-buildimage/pull/6162), [6176](https://github.com/sonic-net/sonic-buildimage/pull/6176), [1542](https://github.com/sonic-net/sonic-swss/pull/1542) #### Multi-ASIC 202006 This feature is for a platform with more than one ASIC present on it, which is defined as a multi ASIC platform. SONiC so far supports platforms with single ASIC, we are enhancing SONiC to support multiple ASIC platforms. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/ebe4f4b695af5d2dbd23756d3cff03aef0a0c880/doc/multi_asic/SONiC_multi_asic_hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [4825](https://github.com/Azure/sonic-buildimage/pull/4825), [4895](https://github.com/Azure/sonic-buildimage/pull/4895), [4926](https://github.com/Azure/sonic-buildimage/pull/4926), [4932](https://github.com/Azure/sonic-buildimage/pull/4932), [4959](https://github.com/Azure/sonic-buildimage/pull/4959), [4973](https://github.com/Azure/sonic-buildimage/pull/4973), [5022](https://github.com/Azure/sonic-buildimage/pull/5022), [5113](https://github.com/Azure/sonic-buildimage/pull/5113), [5121](https://github.com/Azure/sonic-buildimage/pull/5121), [5122](https://github.com/Azure/sonic-buildimage/pull/5122), [5202](https://github.com/Azure/sonic-buildimage/pull/5202), [5221](https://github.com/Azure/sonic-buildimage/pull/5221), [5224](https://github.com/Azure/sonic-buildimage/pull/5224), [5235](https://github.com/Azure/sonic-buildimage/pull/5235), [5316](https://github.com/Azure/sonic-buildimage/pull/5316), [5329](https://github.com/Azure/sonic-buildimage/pull/5329), [5357](https://github.com/Azure/sonic-buildimage/pull/5357), [5358](https://github.com/Azure/sonic-buildimage/pull/5358), [5364](https://github.com/Azure/sonic-buildimage/pull/5364), [5418](https://github.com/Azure/sonic-buildimage/pull/5418), [5420](https://github.com/Azure/sonic-buildimage/pull/5420), [5436](https://github.com/Azure/sonic-buildimage/pull/5436), [5437](https://github.com/Azure/sonic-buildimage/pull/5437), [5446](https://github.com/Azure/sonic-buildimage/pull/5446), [5460](https://github.com/Azure/sonic-buildimage/pull/5460), [5479](https://github.com/Azure/sonic-buildimage/pull/5479), [5503](https://github.com/Azure/sonic-buildimage/pull/5503), [5548](https://github.com/Azure/sonic-buildimage/pull/5548), [87](https://github.com/Azure/sonic-platform-daemons/pull/87), [81](https://github.com/Azure/sonic-py-swsssdk/pull/81), [138](https://github.com/Azure/sonic-snmpagent/pull/138), [140](https://github.com/Azure/sonic-snmpagent/pull/140), [141](https://github.com/Azure/sonic-snmpagent/pull/141), [145](https://github.com/Azure/sonic-snmpagent/pull/145), [154](https://github.com/Azure/sonic-snmpagent/pull/154), [155](https://github.com/Azure/sonic-snmpagent/pull/155), [158](https://github.com/Azure/sonic-snmpagent/pull/158), [161](https://github.com/Azure/sonic-snmpagent/pull/161), [166](https://github.com/Azure/sonic-snmpagent/pull/166), [376](https://github.com/Azure/sonic-swss-common/pull/376), [856](https://github.com/Azure/sonic-utilities/pull/856), [917](https://github.com/Azure/sonic-utilities/pull/917), [978](https://github.com/Azure/sonic-utilities/pull/978), [999](https://github.com/Azure/sonic-utilities/pull/999), [1005](https://github.com/Azure/sonic-utilities/pull/1005), [1006](https://github.com/Azure/sonic-utilities/pull/1006), [1013](https://github.com/Azure/sonic-utilities/pull/1013), [1057](https://github.com/Azure/sonic-utilities/pull/1057), [1064](https://github.com/Azure/sonic-utilities/pull/1064), [1079](https://github.com/Azure/sonic-utilities/pull/1079), [1080](https://github.com/Azure/sonic-utilities/pull/1080), [1081](https://github.com/Azure/sonic-utilities/pull/1081), [1123](https://github.com/Azure/sonic-utilities/pull/1123), [1137](https://github.com/Azure/sonic-utilities/pull/1137) & [1127](https://github.com/Azure/sonic-utilities/pull/1127) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/ebe4f4b695af5d2dbd23756d3cff03aef0a0c880/doc/multi_asic/SONiC_multi_asic_hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [4825](https://github.com/sonic-net/sonic-buildimage/pull/4825), [4895](https://github.com/sonic-net/sonic-buildimage/pull/4895), [4926](https://github.com/sonic-net/sonic-buildimage/pull/4926), [4932](https://github.com/sonic-net/sonic-buildimage/pull/4932), [4959](https://github.com/sonic-net/sonic-buildimage/pull/4959), [4973](https://github.com/sonic-net/sonic-buildimage/pull/4973), [5022](https://github.com/sonic-net/sonic-buildimage/pull/5022), [5113](https://github.com/sonic-net/sonic-buildimage/pull/5113), [5121](https://github.com/sonic-net/sonic-buildimage/pull/5121), [5122](https://github.com/sonic-net/sonic-buildimage/pull/5122), [5202](https://github.com/sonic-net/sonic-buildimage/pull/5202), [5221](https://github.com/sonic-net/sonic-buildimage/pull/5221), [5224](https://github.com/sonic-net/sonic-buildimage/pull/5224), [5235](https://github.com/sonic-net/sonic-buildimage/pull/5235), [5316](https://github.com/sonic-net/sonic-buildimage/pull/5316), [5329](https://github.com/sonic-net/sonic-buildimage/pull/5329), [5357](https://github.com/sonic-net/sonic-buildimage/pull/5357), [5358](https://github.com/sonic-net/sonic-buildimage/pull/5358), [5364](https://github.com/sonic-net/sonic-buildimage/pull/5364), [5418](https://github.com/sonic-net/sonic-buildimage/pull/5418), [5420](https://github.com/sonic-net/sonic-buildimage/pull/5420), [5436](https://github.com/sonic-net/sonic-buildimage/pull/5436), [5437](https://github.com/sonic-net/sonic-buildimage/pull/5437), [5446](https://github.com/sonic-net/sonic-buildimage/pull/5446), [5460](https://github.com/sonic-net/sonic-buildimage/pull/5460), [5479](https://github.com/sonic-net/sonic-buildimage/pull/5479), [5503](https://github.com/sonic-net/sonic-buildimage/pull/5503), [5548](https://github.com/sonic-net/sonic-buildimage/pull/5548), [87](https://github.com/sonic-net/sonic-platform-daemons/pull/87), [81](https://github.com/sonic-net/sonic-py-swsssdk/pull/81), [138](https://github.com/sonic-net/sonic-snmpagent/pull/138), [140](https://github.com/sonic-net/sonic-snmpagent/pull/140), [141](https://github.com/sonic-net/sonic-snmpagent/pull/141), [145](https://github.com/sonic-net/sonic-snmpagent/pull/145), [154](https://github.com/sonic-net/sonic-snmpagent/pull/154), [155](https://github.com/sonic-net/sonic-snmpagent/pull/155), [158](https://github.com/sonic-net/sonic-snmpagent/pull/158), [161](https://github.com/sonic-net/sonic-snmpagent/pull/161), [166](https://github.com/sonic-net/sonic-snmpagent/pull/166), [376](https://github.com/sonic-net/sonic-swss-common/pull/376), [856](https://github.com/sonic-net/sonic-utilities/pull/856), [917](https://github.com/sonic-net/sonic-utilities/pull/917), [978](https://github.com/sonic-net/sonic-utilities/pull/978), [999](https://github.com/sonic-net/sonic-utilities/pull/999), [1005](https://github.com/sonic-net/sonic-utilities/pull/1005), [1006](https://github.com/sonic-net/sonic-utilities/pull/1006), [1013](https://github.com/sonic-net/sonic-utilities/pull/1013), [1057](https://github.com/sonic-net/sonic-utilities/pull/1057), [1064](https://github.com/sonic-net/sonic-utilities/pull/1064), [1079](https://github.com/sonic-net/sonic-utilities/pull/1079), [1080](https://github.com/sonic-net/sonic-utilities/pull/1080), [1081](https://github.com/sonic-net/sonic-utilities/pull/1081), [1123](https://github.com/sonic-net/sonic-utilities/pull/1123), [1137](https://github.com/sonic-net/sonic-utilities/pull/1137) & [1127](https://github.com/sonic-net/sonic-utilities/pull/1127) #### Multi-DB enhancement-Part 2 This feature is for restoring each database with all data before warmboot and then flush unused data in each instance.Restore needs to be done in database docker since we need to know the database_config.json in new version. Need to copy all data rdb file into each instance restoration location and then flush unused database. All other logic remains the same as before. -
**Pull Requests** : [5773](https://github.com/Azure/sonic-buildimage/pull/5773) & [1205](https://github.com/Azure/sonic-utilities/pull/1205) +
**Pull Requests** : [5773](https://github.com/sonic-net/sonic-buildimage/pull/5773) & [1205](https://github.com/sonic-net/sonic-utilities/pull/1205) #### ONIE FW tools SONiC FW utility uses platform API to interact with the various platform components. SONiC FW utility extends to support for the automatic firmware update based on "platform_components.json" under platform directory and next reboot option which is passed as a option for fwutil update all fw command. SONiC FW utility also extends to support for the automatic firmware update with a custom firmware package that can include any firmware update tool and the firmware update tool will be used for the firmware update if it's specified in the "platform_components.json".
Refer [HLD document](https://github.com/sujinmkang/SONiC/blob/357485991d768a9fa78873bb083e3979fbc5cf71/doc/fwutil/fwutil.md) and below mentioned PR's for more details. -
**Pull Requests** : [1165](https://github.com/Azure/sonic-utilities/pull/1165), [106](https://github.com/Azure/sonic-platform-common/pull/106) +
**Pull Requests** : [1165](https://github.com/sonic-net/sonic-utilities/pull/1165), [106](https://github.com/sonic-net/sonic-platform-common/pull/106) #### PDDF advance to SONiC Platform 2.0, BMC PDDF is a rapid platform development environment for SONiC, enabling new platforms to be quickly integrated into the SONiC eco-system by automating much of the routine development using simple description files. It supports both the SONiC Platform 1.0 and 2.0 designs (though 2.0 is preferred). Also supports BMC. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/platform/brcm_pdk_pddf.md) and below mentioned PR's for more details. -
**Pull Requests** : [4756](https://github.com/Azure/sonic-buildimage/pull/4756), [940](https://github.com/Azure/sonic-utilities/pull/940), [92](https://github.com/Azure/sonic-platform-common/pull/92), [3387](https://github.com/Azure/sonic-buildimage/pull/3387), [624](https://github.com/Azure/sonic-utilities/pull/624), [62](https://github.com/Azure/sonic-platform-common/pull/62) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/platform/brcm_pdk_pddf.md) and below mentioned PR's for more details. +
**Pull Requests** : [4756](https://github.com/sonic-net/sonic-buildimage/pull/4756), [940](https://github.com/sonic-net/sonic-utilities/pull/940), [92](https://github.com/sonic-net/sonic-platform-common/pull/92), [3387](https://github.com/sonic-net/sonic-buildimage/pull/3387), [624](https://github.com/sonic-net/sonic-utilities/pull/624), [62](https://github.com/sonic-net/sonic-platform-common/pull/62) #### Support hardware reboot/reload reason (Streaming Telemetry) This feature enables SONiC streaming telemetry agent to send Reboot-cause information. During the boot, the determine-reboot-cause service ( previously process-reboot-cause) determines the last reboot-cause, based on the hardware reboot-cause. And the software reboot-cause information and determine-reboot-cause service will save the JSON-formatted last previous reboot cause. Information is "/host/reboot-cause/history/" by adding timestamp at the end of file name.
Refer [HLD document](https://github.com/sujinmkang/SONiC/blob/6ed19e88c6f7aac74640d3d343210d840af70a23/doc/system-telemetry/reboot-cause.md) and below mentioned PR's for more details. -
**Pull Requests** : [5562](https://github.com/Azure/sonic-buildimage/pull/5562), [1154](https://github.com/Azure/sonic-utilities/pull/1154), [5933](https://github.com/Azure/sonic-buildimage/pull/5933) & [1210](https://github.com/Azure/sonic-utilities/pull/1210) +
**Pull Requests** : [5562](https://github.com/sonic-net/sonic-buildimage/pull/5562), [1154](https://github.com/sonic-net/sonic-utilities/pull/1154), [5933](https://github.com/sonic-net/sonic-buildimage/pull/5933) & [1210](https://github.com/sonic-net/sonic-utilities/pull/1210) #### System health and system LED System health monitor is intended to monitor both critical services and peripheral device status and leverage system log, system status LED to and CLI command output to indicate the system status.In current SONiC implementation, we already have Monit which is monitoring the critical services status and also have a set of daemons.System health monitoring service will not monitor the critical services or devices directly, it will reuse the result of Monit and PMON daemons to summarize the current status and decide the color of the system health LED. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/system_health_monitoring/system-health-HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [4835](https://github.com/Azure/sonic-buildimage/pull/4835) & [4829](https://github.com/Azure/sonic-buildimage/pull/4829) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/system_health_monitoring/system-health-HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [4835](https://github.com/sonic-net/sonic-buildimage/pull/4835) & [4829](https://github.com/sonic-net/sonic-buildimage/pull/4829) # SAI APIs diff --git a/doc/SONiC_202106_Release_Notes.md b/doc/SONiC_202106_Release_Notes.md index c86ca3e1d3..895cb1f2cd 100644 --- a/doc/SONiC_202106_Release_Notes.md +++ b/doc/SONiC_202106_Release_Notes.md @@ -1,6 +1,6 @@ # SONiC 202106 Release Notes -This document captures the new features added and enhancements done on existing features/sub-features for the SONiC [202106](https://github.com/Azure/SONiC/wiki/Release-Progress-Tracking-202106) release. +This document captures the new features added and enhancements done on existing features/sub-features for the SONiC [202106](https://github.com/sonic-net/SONiC/wiki/Release-Progress-Tracking-202106) release. @@ -16,7 +16,7 @@ This document captures the new features added and enhancements done on existing # Branch and Image Location -Branch : https://github.com/Azure/sonic-buildimage/tree/202106
+Branch : https://github.com/sonic-net/sonic-buildimage/tree/202106
Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for Broadcom based platforms is [here]( https://sonic-jenkins.westus2.cloudapp.azure.com/job/broadcom/job/buildimage-brcm-202106/lastSuccessfulBuild/artifact/target/)) # Dependency Version @@ -50,8 +50,8 @@ Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for #### 1. Telemetry for Multi-ASIC This feature is an enhancement on sonic_db_config package for multi-asic to read different namespace redis configuration. And enhanced V2R Lookup for multi-asic, enhanced gNMI Server to initiate redis connection, enhanced gNMI Server Get and enhanced the parsing of target in gNMI Request.
-
Refer [HLD document](https://github.com/Azure/sonic-telemetry/pull/77) and below mentioned PR's for more details. -
**Pull Requests** : [77](https://github.com/Azure/sonic-telemetry/pull/77) +
Refer [HLD document](https://github.com/sonic-net/sonic-telemetry/pull/77) and below mentioned PR's for more details. +
**Pull Requests** : [77](https://github.com/sonic-net/sonic-telemetry/pull/77) #### 2. Add FRR running configuration to tech support @@ -63,25 +63,25 @@ This implementation is an enhancement on tech support as mentioned below. * Sometimes syncd docker is down and bcmshell is unavailable. In such cases all the bcmcmd commands would timeout and result in tremendous increase in the total techsupport collection time. We provided an option to skip rest of the bcmcmd commands once one command times out. * Added show services, show reboot-cause and various BGP, BFD, bcm shell and other commands -Refer [HLD document](https://github.com/Azure/sonic-utilities/pull/1249) and below mentioned PR's for more details. -
**Pull Requests** : [5067](https://github.com/Azure/sonic-buildimage/issues/5067) , [1193](https://github.com/Azure/sonic-utilities/pull/1193) +Refer [HLD document](https://github.com/sonic-net/sonic-utilities/pull/1249) and below mentioned PR's for more details. +
**Pull Requests** : [5067](https://github.com/sonic-net/sonic-buildimage/issues/5067) , [1193](https://github.com/sonic-net/sonic-utilities/pull/1193) #### 3. App extension with warmboot awareness SONiC Application Extension Infrastructure is a SONiC infrastructure and framework for managing SONiC Application Packages which in this scope are SONiC compatible Docker images distributed individually from one another and from the base SONiC image. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/sonic-application-extention/sonic-application-extention-hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [682](https://github.com/Azure/SONiC/pull/682), [6398](https://github.com/Azure/sonic-buildimage/issues/6398) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/sonic-application-extention/sonic-application-extention-hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [682](https://github.com/sonic-net/SONiC/pull/682), [6398](https://github.com/sonic-net/sonic-buildimage/issues/6398) #### 4. Enable/Disable auto negotiation and speed setting with number of lanes This feature introduces a few new CLI commands which will fit in sonic-utilities. And this feature also requires to change the configuration flow for port auto negotiation attributes which will be covered in orchagent.
-
Refer [HLD document](https://github.com/Azure/SONiC/blob/9b58ef06ab49b489e3aed287659100ce7be8c76a/doc/port_auto_neg/port-auto-negotiation-design.md#cli-enhancements) and below mentioned PR's for more details. -
**Pull Requests** : [732](https://github.com/Azure/SONiC/pull/732), [6948](https://github.com/Azure/sonic-buildimage/pull/6948), [1568](https://github.com/Azure/sonic-utilities/pull/1568), [1714](https://github.com/Azure/sonic-swss/pull/1714), [3376](https://github.com/Azure/sonic-mgmt/pull/3376) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/9b58ef06ab49b489e3aed287659100ce7be8c76a/doc/port_auto_neg/port-auto-negotiation-design.md#cli-enhancements) and below mentioned PR's for more details. +
**Pull Requests** : [732](https://github.com/sonic-net/SONiC/pull/732), [6948](https://github.com/sonic-net/sonic-buildimage/pull/6948), [1568](https://github.com/sonic-net/sonic-utilities/pull/1568), [1714](https://github.com/sonic-net/sonic-swss/pull/1714), [3376](https://github.com/sonic-net/sonic-mgmt/pull/3376) #### 5. TPID config support Currently SONiC Testbed setup uses fanout switches to connect to the testbed server and running the PTF test cases. The fanout switch ports connecting to the DUT are configured as access ports. The fanout switch is configured with 802.1Q tunnel on the DUT facing ports side so that tagged packets are not to be used for service delimiting purpose. With this TPID configuration capability, these fanout switches can be converted to run in SONiC.

Refer [HLD document](https://github.com/gechiang/SONiC/blob/3f57d0304bda22222b01f2b90098e4d4d3b88f68/doc/tpid/SonicTPIDSettingHLD1.md) and below mentioned PR's for more details. -
**Pull Requests** : [681](https://github.com/Azure/SONiC/pull/681), [7630](https://github.com/Azure/sonic-buildimage/pull/7630), [1747](https://github.com/Azure/sonic-swss/pull/1747), [1618](https://github.com/Azure/sonic-utilities/pull/1618) +
**Pull Requests** : [681](https://github.com/sonic-net/SONiC/pull/681), [7630](https://github.com/sonic-net/sonic-buildimage/pull/7630), [1747](https://github.com/sonic-net/sonic-swss/pull/1747), [1618](https://github.com/sonic-net/sonic-utilities/pull/1618) #### 6. Error handling (swss) @@ -92,32 +92,32 @@ This feature impliments the orchagent in handling SAI failures. below are the fa * Adapt handling logic based on SAI API type and SAI status. * Escalate the failure to upper layers when the failure cannot be handled in orchagent. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/SAI_failure_handling/SAI_failure_handling.md) and below mentioned PR's for more details. -
**Pull Requests** : [1596](https://github.com/Azure/sonic-swss/pull/1596), [1815](https://github.com/Azure/sonic-swss/pull/1815), [1768](https://github.com/Azure/sonic-swss/pull/1768), [1786](https://github.com/Azure/sonic-swss/pull/1786), [1665](https://github.com/Azure/sonic-swss/pull/1665) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/SAI_failure_handling/SAI_failure_handling.md) and below mentioned PR's for more details. +
**Pull Requests** : [1596](https://github.com/sonic-net/sonic-swss/pull/1596), [1815](https://github.com/sonic-net/sonic-swss/pull/1815), [1768](https://github.com/sonic-net/sonic-swss/pull/1768), [1786](https://github.com/sonic-net/sonic-swss/pull/1786), [1665](https://github.com/sonic-net/sonic-swss/pull/1665) #### 7.Inband mgmt VRF This feature design is intended to have a generic approach for in-band management via mgmt VRF feature. A user can set an attribute "in_band_mgmt_enabled" to the config_db for MGMT_VRF_CONFIG table entry. The default value if not specified would be "false"

Refer [HLD document](https://github.com/venkatmahalingam/SONiC/blob/7781c097a92d9fbac3fc2fe2f8c6ce175839f473/doc/vrf/SONiC_in_band_mgmt_via_mgmt_Vrf_HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [1726](https://github.com/Azure/sonic-swss/pull/1726) +
**Pull Requests** : [1726](https://github.com/sonic-net/sonic-swss/pull/1726) #### 8.SONiC for MPLS Dataplane This feature provides general information about the initial support for MPLS in SONiC infrastructure. The focus of this initial MPLS support is to expand existing SONiC infrastructure for IPv4/IPv6 routing to include equivalent MPLS functionality. The expected use case for this initial MPLS support is static LSP routing.
-
Refer [HLD document](https://github.com/Azure/SONiC/blob/364fcae0438ed583270b56319dcfcb91e20b918a/doc/mpls/MPLS_hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [1537](https://github.com/Azure/sonic-utilities/pull/1537), [469](https://github.com/Azure/sonic-swss-common/pull/469), [824](https://github.com/Azure/sonic-sairedis/pull/824), [7195](https://github.com/Azure/sonic-buildimage/pull/7195), [1686](https://github.com/Azure/sonic-swss/pull/1686) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/364fcae0438ed583270b56319dcfcb91e20b918a/doc/mpls/MPLS_hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [1537](https://github.com/sonic-net/sonic-utilities/pull/1537), [469](https://github.com/sonic-net/sonic-swss-common/pull/469), [824](https://github.com/sonic-net/sonic-sairedis/pull/824), [7195](https://github.com/sonic-net/sonic-buildimage/pull/7195), [1686](https://github.com/sonic-net/sonic-swss/pull/1686) #### 9.IPv6 Link Local and BGP Unnumbered This feature provides the implementation of IPv6 link-local enhancements in SONiC.
Refer [HLD document](https://github.com/kirankella/SONiC/blob/d17a977f88ed623c8367eaac747040796d7a7c3f/doc/ipv6/ipv6_link_local.md) and below mentioned PR's for more details. -
**Pull Requests** : [5584](https://github.com/Azure/sonic-buildimage/pull/5584), [1463](https://github.com/Azure/sonic-swss/pull/1463), [1159](https://github.com/Azure/sonic-utilities/pull/1159) +
**Pull Requests** : [5584](https://github.com/sonic-net/sonic-buildimage/pull/5584), [1463](https://github.com/sonic-net/sonic-swss/pull/1463), [1159](https://github.com/sonic-net/sonic-utilities/pull/1159) #### 10. MC-LAG (L2) This feature is an enhancements of SONiC ICCP MCLAG. This includes MCLAG configuration support, data structure changes, MAC event handling optimizations for scaling performance, support of static MAC address over MCLAG, support bridge-port isolation group for BUM control to MCLAG, and traffic recovery sequencing for traffic loop prevention. -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/mclag/MCLAG_Enhancements_HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [596](https://github.com/Azure/SONiC/pull/596), [885](https://github.com/Azure/sonic-swss/pull/885), [4819](https://github.com/Azure/sonic-buildimage/pull/4819), [1331](https://github.com/Azure/sonic-swss/pull/1331), [1349](https://github.com/Azure/sonic-swss/pull/1349), [529](https://github.com/Azure/sonic-utilities/pull/529), [405](https://github.com/Azure/sonic-swss-common/pull/405), [59](https://github.com/Azure/sonic-mgmt-framework/pull/59), [25](https://github.com/Azure/sonic-mgmt-common/pull/25) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/mclag/MCLAG_Enhancements_HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [596](https://github.com/sonic-net/SONiC/pull/596), [885](https://github.com/sonic-net/sonic-swss/pull/885), [4819](https://github.com/sonic-net/sonic-buildimage/pull/4819), [1331](https://github.com/sonic-net/sonic-swss/pull/1331), [1349](https://github.com/sonic-net/sonic-swss/pull/1349), [529](https://github.com/sonic-net/sonic-utilities/pull/529), [405](https://github.com/sonic-net/sonic-swss-common/pull/405), [59](https://github.com/sonic-net/sonic-mgmt-framework/pull/59), [25](https://github.com/sonic-net/sonic-mgmt-common/pull/25) #### 11. DHCP relay IPv6 support This DHCP Relay for IPv6 feature in SONiC impliments the following functionalities, @@ -126,49 +126,49 @@ This DHCP Relay for IPv6 feature in SONiC impliments the following functionaliti * To provide the functionality as a seperate process running on dhcp-relay docker container. * To relay messages to multiple unicast and multicast addresses. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/DHCPv6_Relay/DHCPv6_Relay_HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [7772](https://github.com/Azure/sonic-buildimage/pull/7772), [6531](https://github.com/Azure/sonic-buildimage/pull/6531), [7789](https://github.com/Azure/sonic-buildimage/pull/7789), [3565](https://github.com/Azure/sonic-mgmt/pull/3565) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/DHCPv6_Relay/DHCPv6_Relay_HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [7772](https://github.com/sonic-net/sonic-buildimage/pull/7772), [6531](https://github.com/sonic-net/sonic-buildimage/pull/6531), [7789](https://github.com/sonic-net/sonic-buildimage/pull/7789), [3565](https://github.com/sonic-net/sonic-mgmt/pull/3565) #### 12. RADIUS AAA This implementation describes the high level design of RADIUS management user authentication feature in SONiC.

Refer [HLD document](https://github.com/a-barboza/SONiC/blob/8d31c4014e27f422f4c522d2891fa9d9a4fff606/doc/aaa/radius_authentication.md) and below mentioned PR's for more details. -
**Pull Requests** : [500](https://github.com/Azure/SONiC/pull/500), [1521](https://github.com/Azure/sonic-utilities/pull/1521), [7284](https://github.com/Azure/sonic-buildimage/pull/7284), [4220](https://github.com/Azure/sonic-buildimage/pull/4220) +
**Pull Requests** : [500](https://github.com/sonic-net/SONiC/pull/500), [1521](https://github.com/sonic-net/sonic-utilities/pull/1521), [7284](https://github.com/sonic-net/sonic-buildimage/pull/7284), [4220](https://github.com/sonic-net/sonic-buildimage/pull/4220) #### 13. PDK - Platform Development Environment The SONiC PDE is part of the SONiC Platform Development Kit (PDK) which optimizes platform development. The SONiC PDK consists of PDDF (Platform Driver Development Framework) and PDE (Platform Development Environment) -
Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/platform/pde.md) and below mentioned PR's for more details. -
**Pull Requests** : [3778](https://github.com/Azure/sonic-buildimage/pull/3778) [28](https://github.com/Azure/sonic-platform-pdk-pde/pull/28), [107](https://github.com/Azure/sonic-build-tools/pull/107). +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/platform/pde.md) and below mentioned PR's for more details. +
**Pull Requests** : [3778](https://github.com/sonic-net/sonic-buildimage/pull/3778) [28](https://github.com/sonic-net/sonic-platform-pdk-pde/pull/28), [107](https://github.com/Azure/sonic-build-tools/pull/107). #### 14. Broadcom silicon common config This feature supports the per-switching silicon common config.bcm file to assist with silicon-wide application configuration settings for all affected Broadcom platforms. The infrastructure saves development time by allowing applications to refactor common settings in a single location, and allows for platform-specific overrides.

Refer [HLD document](https://github.com/geans-pin/SONiC/blob/ff5ad50dfd770242d4fdac97f2e4c803b2425dde/doc/platform/common_config.md) and below mentioned PR's for more details. -
**Pull Requests** : [693](https://github.com/Azure/sonic-sairedis/pull/693), [699](https://github.com/Azure/SONiC/pull/699), [5818](https://github.com/Azure/sonic-buildimage/pull/5818), [7493](https://github.com/Azure/sonic-buildimage/pull/7493) +
**Pull Requests** : [693](https://github.com/sonic-net/sonic-sairedis/pull/693), [699](https://github.com/sonic-net/SONiC/pull/699), [5818](https://github.com/sonic-net/sonic-buildimage/pull/5818), [7493](https://github.com/sonic-net/sonic-buildimage/pull/7493) #### 15. PCIe Monitoring This feature is intended to give the idea of how to monitor the platform PCIe devices and alert of any problems on PCIe buses and devices on SONiC using pcie-check service and pcied on PMON container.New PCIe Monitor service is designed to use the PcieUtil utility to check the current status of PCIe devices and buses and alert if there is any missing devices or any error while communicating on the PCIe buses.PCIe device monitoring will be done in two separate services, pcie-check.service which is a systemd service, will check the PCIe device during the boot time and pcied which is a daemon in PMON container will monitor during the runtime.

Refer [HLD document](https://github.com/sujinmkang/SONiC/blob/4e93b8b30609ffc698ac801cd12740c35d2ea284/doc/pcie-mon/pcie-monitoring-services-hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [60](https://github.com/Azure/sonic-platform-daemons/pull/60), [100](https://github.com/Azure/sonic-platform-daemons/pull/100), [144](https://github.com/Azure/sonic-platform-common/pull/144), [634](https://github.com/Azure/SONiC/pull/634), [678](https://github.com/Azure/SONiC/pull/678), [1169](https://github.com/Azure/sonic-utilities/pull/1169), [5000](https://github.com/Azure/sonic-buildimage/pull/5000) +
**Pull Requests** : [60](https://github.com/sonic-net/sonic-platform-daemons/pull/60), [100](https://github.com/sonic-net/sonic-platform-daemons/pull/100), [144](https://github.com/sonic-net/sonic-platform-common/pull/144), [634](https://github.com/sonic-net/SONiC/pull/634), [678](https://github.com/sonic-net/SONiC/pull/678), [1169](https://github.com/sonic-net/sonic-utilities/pull/1169), [5000](https://github.com/sonic-net/sonic-buildimage/pull/5000) #### 16. Enhanced xcrvd SFP error flow HLD This feature reflects the current implementation of xcvrd to the HLD.Added new SFP error event handling procedure and added a CLI to retrieve the SFP error status.
-
Refer [HLD document](https://github.com/Azure/SONiC/blob/f8893cf5d7492c92e9e613c1eb525778ab60f6cb/doc/xrcvd/transceiver-monitor-hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [184](https://github.com/Azure/sonic-platform-daemons/pull/184), [194](https://github.com/Azure/sonic-platform-common/pull/194), [586](https://github.com/Azure/SONiC/pull/586), [1658](https://github.com/Azure/sonic-utilities/pull/1658), [3648](https://github.com/Azure/sonic-mgmt/pull/3648), [7605](https://github.com/Azure/sonic-buildimage/pull/7605) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/f8893cf5d7492c92e9e613c1eb525778ab60f6cb/doc/xrcvd/transceiver-monitor-hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [184](https://github.com/sonic-net/sonic-platform-daemons/pull/184), [194](https://github.com/sonic-net/sonic-platform-common/pull/194), [586](https://github.com/sonic-net/SONiC/pull/586), [1658](https://github.com/sonic-net/sonic-utilities/pull/1658), [3648](https://github.com/sonic-net/sonic-mgmt/pull/3648), [7605](https://github.com/sonic-net/sonic-buildimage/pull/7605) #### 17. Entity sensor MIB extension The Entity MIB contains several groups of MIB objects: entityPhysical group, entityLogical group and so on. Currently SONiC only implemented part of the entityPhysical group following RFC2737. Since entityPhysical group is mostly common used, this extension will focus on entityPhysical group and leave other groups for future implementation.
-
Refer [HLD document](https://github.com/Azure/SONiC/blob/90731187a760b604870a2f3fc6868530f5427937/doc/snmp/extension-to-physical-entity-mib.md) and below mentioned PR's for more details. -
**Pull Requests** : [211](https://github.com/Azure/sonic-snmpagent/pull/211), [766](https://github.com/Azure/SONiC/pull/766), [3357](https://github.com/Azure/sonic-mgmt/pull/3357) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/90731187a760b604870a2f3fc6868530f5427937/doc/snmp/extension-to-physical-entity-mib.md) and below mentioned PR's for more details. +
**Pull Requests** : [211](https://github.com/sonic-net/sonic-snmpagent/pull/211), [766](https://github.com/sonic-net/SONiC/pull/766), [3357](https://github.com/sonic-net/sonic-mgmt/pull/3357) #### 18. Enable/Disable auto negotiation and speed setting with number of lanes Add new CLIs to enable/disable auto negotiation per interface as well as setting the number of lanes per requested speed
-
Refer [HLD document](https://github.com/Azure/SONiC/blob/9b58ef06ab49b489e3aed287659100ce7be8c76a/doc/port_auto_neg/port-auto-negotiation-design.md) and below mentioned PR's for more details. -
**Pull Requests** : [732] (https://github.com/Azure/SONiC/pull/732) +
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/9b58ef06ab49b489e3aed287659100ce7be8c76a/doc/port_auto_neg/port-auto-negotiation-design.md) and below mentioned PR's for more details. +
**Pull Requests** : [732] (https://github.com/sonic-net/SONiC/pull/732) # SAI APIs diff --git a/doc/SONiC_202111_Release_Notes.md b/doc/SONiC_202111_Release_Notes.md index 8f9eb55947..dcf90c339b 100644 --- a/doc/SONiC_202111_Release_Notes.md +++ b/doc/SONiC_202111_Release_Notes.md @@ -1,6 +1,6 @@ # SONiC 202111 Release Notes -This document captures the new features added and enhancements done on existing features/sub-features for the SONiC [202111](https://github.com/Azure/SONiC/wiki/Release-Progress-Tracking-202111) release. +This document captures the new features added and enhancements done on existing features/sub-features for the SONiC [202111](https://github.com/sonic-net/SONiC/wiki/Release-Progress-Tracking-202111) release. @@ -16,7 +16,7 @@ This document captures the new features added and enhancements done on existing # Branch and Image Location -Branch : https://github.com/Azure/sonic-buildimage/tree/202111
+Branch : https://github.com/sonic-net/sonic-buildimage/tree/202111
Image : https://sonic-build.azurewebsites.net/ui/sonic/pipelines (Example - Image for Broadcom based platforms is [here](https://sonic-build.azurewebsites.net/ui/sonic/pipelines/138/builds/51255/artifacts/98637?branchName=master&artifactName=sonic-buildimage.broadcom)) # Dependency Version @@ -52,32 +52,32 @@ Image : https://sonic-build.azurewebsites.net/ui/sonic/pipelines (Example - Im #### ACL orch redesign This feature covers ACL rule counters support and enhancements in that area. The current design of ACL rule counters implements polling at orchagent side at a constant hardcoded interval of 10 seconds. While it is a simpler approach comparing to Flex Counters infrastructure it comes at a cost of scalability and performance issues.Flex counters infrastructure on another hand already used for port, PG, queue, watermark counters solves this issue by delegating counter polling to a separate thread in syncd and allowing to configure polling interval as well. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/acl/ACL-Flex-Counters.md) and below mentioned PR's for more details. -
**Pull Requests** : [533](https://github.com/Azure/sonic-swss-common/pull/533), [953](https://github.com/Azure/sonic-sairedis/pull/953), [1943](https://github.com/Azure/sonic-swss/pull/1943), [1858](https://github.com/Azure/sonic-utilities/pull/1858), [8908](https://github.com/Azure/sonic-buildimage/pull/8908) & [8909](https://github.com/Azure/sonic-buildimage/pull/8909) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/acl/ACL-Flex-Counters.md) and below mentioned PR's for more details. +
**Pull Requests** : [533](https://github.com/sonic-net/sonic-swss-common/pull/533), [953](https://github.com/sonic-net/sonic-sairedis/pull/953), [1943](https://github.com/sonic-net/sonic-swss/pull/1943), [1858](https://github.com/sonic-net/sonic-utilities/pull/1858), [8908](https://github.com/sonic-net/sonic-buildimage/pull/8908) & [8909](https://github.com/sonic-net/sonic-buildimage/pull/8909) #### App extension CLI generation tool The SONiC CLI Auto-generation tool - is a utility for generating the command-line interface for third-party features, called application extensions, that provide their functionality as separate docker containers. The YANG model will be used to describe the CONFIG DB schema and CLI will be generated according to CONFIG DB schema. The YANG model will serve as an input parameter for the SONiC Auto-generation utility. The CLI should be a part of SONiC utilities and support - show, config operations. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/sonic-application-extention/sonic-application-extention-hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [780](https://github.com/Azure/SONiC/pull/780), [1644](https://github.com/Azure/sonic-utilities/pull/1644) & [1650](https://github.com/Azure/sonic-utilities/pull/1650) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/sonic-application-extention/sonic-application-extention-hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [780](https://github.com/sonic-net/SONiC/pull/780), [1644](https://github.com/sonic-net/sonic-utilities/pull/1644) & [1650](https://github.com/sonic-net/sonic-utilities/pull/1650) #### Automatic techsupport and core dump creation Currently, techsupport is run by invoking show techsupport either by orchestration tools like Jenkins or manually. The techsupport dump also collects any core dump files available in the /var/core/ directory. However if the techsupport invocation can be made event-driven based on core dump generation, that would definitely improve the debuggability. -Refer [HLD document](https://github.com/Azure/SONiC/blob/61a07b416d0ecab85833337944928dca5d64150e/doc/auto_techsupport_and_coredump_mgmt.md) and below mentioned PR's for more details. -
**Pull Requests** : [818](https://github.com/Azure/SONiC/pull/818), [8670](https://github.com/Azure/sonic-buildimage/pull/8670) & [1796](https://github.com/Azure/sonic-utilities/pull/1796) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/61a07b416d0ecab85833337944928dca5d64150e/doc/auto_techsupport_and_coredump_mgmt.md) and below mentioned PR's for more details. +
**Pull Requests** : [818](https://github.com/sonic-net/SONiC/pull/818), [8670](https://github.com/sonic-net/sonic-buildimage/pull/8670) & [1796](https://github.com/sonic-net/sonic-utilities/pull/1796) #### Better route scalability with multiple next-hops Currently the route table within APP_DB contains all next hop information for a route embedded in that route's entry in the table. At high scale (particularly when handling millions of routes all routed over multiple next hops) this is inefficient both in terms of performance and occupancy. A more efficient system would involve managing the next hop groups in use by the route table separately, and simply have the route table specify a reference to which next hop group to use. Since at scale many routes will use the same next hop groups, this requires much smaller occupancy per route, and so more efficient building, transmission and parsing of per-route information. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/ip/next_hop_group_hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [712](https://github.com/Azure/SONiC/pull/712), [475](https://github.com/Azure/sonic-swss-common/pull/475) & [1702](https://github.com/Azure/sonic-swss/pull/1702) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/ip/next_hop_group_hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [712](https://github.com/sonic-net/SONiC/pull/712), [475](https://github.com/sonic-net/sonic-swss-common/pull/475) & [1702](https://github.com/sonic-net/sonic-swss/pull/1702) #### Class-Based Forwarding Class Based Forwarding which allows traffic to be steered through the network by policy, adding a layer of traffic engineering based on a Forwarding Class value which allows custom paths to be configured for a destination based on this value. -Refer [HLD document](https://github.com/Azure/SONiC/blob/e65d05a32761ea1c50c170008b22410879dce300/doc/cbf/cbf_hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [796](https://github.com/Azure/SONiC/pull/796), [525](https://github.com/Azure/sonic-swss-common/pull/525), [909](https://github.com/Azure/sonic-sairedis/pull/909), [1963](https://github.com/Azure/sonic-swss/pull/1963), [8689](https://github.com/Azure/sonic-buildimage/pull/8689) & [1799](https://github.com/Azure/sonic-utilities/pull/1799) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/e65d05a32761ea1c50c170008b22410879dce300/doc/cbf/cbf_hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [796](https://github.com/sonic-net/SONiC/pull/796), [525](https://github.com/sonic-net/sonic-swss-common/pull/525), [909](https://github.com/sonic-net/sonic-sairedis/pull/909), [1963](https://github.com/sonic-net/sonic-swss/pull/1963), [8689](https://github.com/sonic-net/sonic-buildimage/pull/8689) & [1799](https://github.com/sonic-net/sonic-utilities/pull/1799) #### CLI level authorization This feature is based on TACACS+ Authentication, and provides a detailed description for improved TACACS+ support. @@ -95,121 +95,121 @@ SONiC currently supported TACACS+ features: * User command authorization with TACACS+ server. * User command accounting with TACACS+ server. -Refer [HLD document](https://github.com/Azure/SONiC/blob/4d1660cc88002aff64e6228b63b5f2d6b59d6031/doc/aaa/TACACS%2B%20Design.md) and below mentioned PR's for more details. -
**Pull Requests** : [813](https://github.com/Azure/SONiC/pull/813), [8660](https://github.com/Azure/sonic-buildimage/pull/8660), [8659](https://github.com/Azure/sonic-buildimage/pull/8659), [8715](https://github.com/Azure/sonic-buildimage/pull/8715), [9029](https://github.com/Azure/sonic-buildimage/pull/9029), [1889](https://github.com/Azure/sonic-utilities/pull/1889), [4605](https://github.com/Azure/sonic-mgmt/pull/4605) & [8750](https://github.com/Azure/sonic-buildimage/pull/8750) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/4d1660cc88002aff64e6228b63b5f2d6b59d6031/doc/aaa/TACACS%2B%20Design.md) and below mentioned PR's for more details. +
**Pull Requests** : [813](https://github.com/sonic-net/SONiC/pull/813), [8660](https://github.com/sonic-net/sonic-buildimage/pull/8660), [8659](https://github.com/sonic-net/sonic-buildimage/pull/8659), [8715](https://github.com/sonic-net/sonic-buildimage/pull/8715), [9029](https://github.com/sonic-net/sonic-buildimage/pull/9029), [1889](https://github.com/sonic-net/sonic-utilities/pull/1889), [4605](https://github.com/sonic-net/sonic-mgmt/pull/4605) & [8750](https://github.com/sonic-net/sonic-buildimage/pull/8750) #### DHCP support IPv6 SONiC currently supports DHCPv4 Relay via the use of open source ISC DHCP package. However, DHCPv6 specification does not define a way to communicate client link-layer address to the DHCP server where DHCP server is not connected to the same network link as DHCP client. DHCPv6 requires all clients prepare and send a DUID as the client identifier in all DHCPv6 message exchanges. -Refer [HLD document](https://github.com/Azure/SONiC/blob/92acec6cc29165382e0b40d1ff528a6f409de572/doc/DHCPv6_relay/DHCPv6-relay-agent-High-Level-Design.md) and below mentioned PR's for more details. -
**Pull Requests** : [787](https://github.com/Azure/SONiC/pull/787) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/92acec6cc29165382e0b40d1ff528a6f409de572/doc/DHCPv6_relay/DHCPv6-relay-agent-High-Level-Design.md) and below mentioned PR's for more details. +
**Pull Requests** : [787](https://github.com/sonic-net/SONiC/pull/787) #### Dynamic Policy Based Hashing This feature will support policy based hashing for NVGRE/VxLAN packets based on inner 5-tuple (IP proto, L4 dst/src port, IPv4/IPv6 dst/src) -Refer [HLD document](https://github.com/Azure/SONiC/blob/91eee7f952b4ad4679ada1b5b5f3b95ad39e2431/doc/pbh/pbh-design.md) and below mentioned PR's for more details. -
**Pull Requests** : [773](https://github.com/Azure/SONiC/pull/773), [7461](https://github.com/Azure/sonic-buildimage/pull/7461), [495](https://github.com/Azure/sonic-swss-common/pull/495), [1782](https://github.com/Azure/sonic-swss/pull/1782) & [1701](https://github.com/Azure/sonic-utilities/pull/1701) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/91eee7f952b4ad4679ada1b5b5f3b95ad39e2431/doc/pbh/pbh-design.md) and below mentioned PR's for more details. +
**Pull Requests** : [773](https://github.com/sonic-net/SONiC/pull/773), [7461](https://github.com/sonic-net/sonic-buildimage/pull/7461), [495](https://github.com/sonic-net/sonic-swss-common/pull/495), [1782](https://github.com/sonic-net/sonic-swss/pull/1782) & [1701](https://github.com/sonic-net/sonic-utilities/pull/1701) #### Dynamic port breakout This feature is to support port breakout dynamically. We should be able to change port breakout mode at run time without affecting the unrelated port activities. Configuration dependencies on the ports to be changed with breakout mode should be reported or removed automatically. Run time dependencies and resources should be cleared on the ports to be changed with breakout mode. Optionally, we provide a way to automatically add the configuration back to the port if operators can specify in advance. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [4235](https://github.com/Azure/sonic-buildimage/pull/4235), [3910](https://github.com/Azure/sonic-buildimage/pull/3910), [1242](https://github.com/Azure/sonic-swss/pull/1242), [1219](https://github.com/Azure/sonic-swss/pull/1219), [1148](https://github.com/Azure/sonic-swss/pull/1148), [1112](https://github.com/Azure/sonic-swss/pull/1112), [766](https://github.com/Azure/sonic-utilities/pull/766), [72](https://github.com/Azure/sonic-platform-common/pull/72), [859](https://github.com/Azure/sonic-utilities/pull/859), [767](https://github.com/Azure/sonic-utilities/pull/767), [765](https://github.com/Azure/sonic-utilities/pull/765), [3912](https://github.com/Azure/sonic-buildimage/pull/3912), [3911](https://github.com/Azure/sonic-buildimage/pull/3911), [3909](https://github.com/Azure/sonic-buildimage/pull/3909), [3861](https://github.com/Azure/sonic-buildimage/pull/3861), [3730](https://github.com/Azure/sonic-buildimage/pull/3730), [3907](https://github.com/Azure/sonic-buildimage/pull/3907), [3891](https://github.com/Azure/sonic-buildimage/pull/3891), [3874](https://github.com/Azure/sonic-buildimage/pull/3874), [1085](https://github.com/Azure/sonic-swss/pull/1085), [1151](https://github.com/Azure/sonic-swss/pull/1151) & [1150](https://github.com/Azure/sonic-swss/pull/1150) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [4235](https://github.com/sonic-net/sonic-buildimage/pull/4235), [3910](https://github.com/sonic-net/sonic-buildimage/pull/3910), [1242](https://github.com/sonic-net/sonic-swss/pull/1242), [1219](https://github.com/sonic-net/sonic-swss/pull/1219), [1148](https://github.com/sonic-net/sonic-swss/pull/1148), [1112](https://github.com/sonic-net/sonic-swss/pull/1112), [766](https://github.com/sonic-net/sonic-utilities/pull/766), [72](https://github.com/sonic-net/sonic-platform-common/pull/72), [859](https://github.com/sonic-net/sonic-utilities/pull/859), [767](https://github.com/sonic-net/sonic-utilities/pull/767), [765](https://github.com/sonic-net/sonic-utilities/pull/765), [3912](https://github.com/sonic-net/sonic-buildimage/pull/3912), [3911](https://github.com/sonic-net/sonic-buildimage/pull/3911), [3909](https://github.com/sonic-net/sonic-buildimage/pull/3909), [3861](https://github.com/sonic-net/sonic-buildimage/pull/3861), [3730](https://github.com/sonic-net/sonic-buildimage/pull/3730), [3907](https://github.com/sonic-net/sonic-buildimage/pull/3907), [3891](https://github.com/sonic-net/sonic-buildimage/pull/3891), [3874](https://github.com/sonic-net/sonic-buildimage/pull/3874), [1085](https://github.com/sonic-net/sonic-swss/pull/1085), [1151](https://github.com/sonic-net/sonic-swss/pull/1151) & [1150](https://github.com/sonic-net/sonic-swss/pull/1150) #### EXP to TC QoS maps This feature extends SONiC to support MPLS TC to TC mappings. This new enhancement adds support to SONiC for MPLS TC to TC map which allows QoS to work on MPLS packets. User can configure MPLS TC to TC map at start-of-day via configuration file. CLI support will exist to offer the same amount of support as for DSCP to TC map. -Refer [HLD document](https://github.com/Azure/SONiC/blob/bb476c589a6ac5a7e3ea66a0a84caab6264dc7a9/doc/qos/mpls_tc_to_tc_map.md) and below mentioned PR's for more details. -
**Pull Requests** : [844](https://github.com/Azure/SONiC/pull/844), [537](https://github.com/Azure/sonic-swss-common/pull/537), [1954](https://github.com/Azure/sonic-swss/pull/1954) & [1875](https://github.com/Azure/sonic-utilities/pull/1875) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/bb476c589a6ac5a7e3ea66a0a84caab6264dc7a9/doc/qos/mpls_tc_to_tc_map.md) and below mentioned PR's for more details. +
**Pull Requests** : [844](https://github.com/sonic-net/SONiC/pull/844), [537](https://github.com/sonic-net/sonic-swss-common/pull/537), [1954](https://github.com/sonic-net/sonic-swss/pull/1954) & [1875](https://github.com/sonic-net/sonic-utilities/pull/1875) #### EVPN VXLAN for platforms using P2MP tunnel based L2 forwarding The EVPN VXLAN feature implementation is based on RFC 7432 and 8365 in SONiC. This feature is incremental to the SONiC.201911 release. -Refer [HLD document](https://github.com/Azure/SONiC/blob/17583e3eae8e06cf9e15df9806ab97ab4db76082/doc/vxlan/EVPN/EVPN_VXLAN_HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [806](https://github.com/Azure/SONiC/pull/806), [1858](https://github.com/Azure/sonic-swss/pull/1858), [8685](https://github.com/Azure/sonic-buildimage/pull/8685), [920](https://github.com/Azure/sonic-sairedis/pull/920), [1859](https://github.com/Azure/sonic-swss/pull/1859), [886](https://github.com/Azure/sonic-sairedis/pull/886), [519](https://github.com/Azure/sonic-swss-common/pull/519), [1748](https://github.com/Azure/sonic-utilities/pull/1748) & [8369](https://github.com/Azure/sonic-buildimage/pull/8369) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/17583e3eae8e06cf9e15df9806ab97ab4db76082/doc/vxlan/EVPN/EVPN_VXLAN_HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [806](https://github.com/sonic-net/SONiC/pull/806), [1858](https://github.com/sonic-net/sonic-swss/pull/1858), [8685](https://github.com/sonic-net/sonic-buildimage/pull/8685), [920](https://github.com/sonic-net/sonic-sairedis/pull/920), [1859](https://github.com/sonic-net/sonic-swss/pull/1859), [886](https://github.com/sonic-net/sonic-sairedis/pull/886), [519](https://github.com/sonic-net/sonic-swss-common/pull/519), [1748](https://github.com/sonic-net/sonic-utilities/pull/1748) & [8369](https://github.com/sonic-net/sonic-buildimage/pull/8369) #### Handle port config change on fly in xcvrd The current xcvrd assumes that port mapping information is never changed, so it always read static port mapping information from platform.json/port_config.ini and save it to a global data structure. However, things changed since dynamic port breakout feature introduced. Port can be added/created on the fly, xcvrd cannot update transceiver information, DOM information and transceiver status information without knowing the ports change. This implementation introduces a way to handle port configuration change on fly in xcvrd. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/xrcvd/transceiver-monitor-hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [839](https://github.com/Azure/SONiC/pull/839) & [212](https://github.com/Azure/sonic-platform-daemons/pull/212) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/xrcvd/transceiver-monitor-hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [839](https://github.com/sonic-net/SONiC/pull/839) & [212](https://github.com/sonic-net/sonic-platform-daemons/pull/212) #### Host interface trap counter Flow counters are usually used for debugging, troubleshooting and performance enhancement processes. Flow counters could cover cases like, Host interface traps (number of received traps per Trap ID), Routes matching the configured prefix pattern (number of hits and number of bytes), FDB entries matching the configured VXLAN tunnel or using the VLAN ID as pattern, Next-Hop/Next-Hop Group/Next-Hop Group Member, & This document focus on host interface traps counter. -Refer [HLD document](https://github.com/Azure/SONiC/blob/434a5fcc8a5c7f0fe13e163d89ee9af61a06dbd1/doc/flow_counters/flow_counters.md) and below mentioned PR's for more details. -
**Pull Requests** : [858](https://github.com/Azure/SONiC/pull/858), [8940](https://github.com/Azure/sonic-buildimage/pull/8940), [1951](https://github.com/Azure/sonic-swss/pull/1951), [4456](https://github.com/Azure/sonic-mgmt/pull/4456), [1868](https://github.com/Azure/sonic-utilities/pull/1868), [954](https://github.com/Azure/sonic-sairedis/pull/954), [534](https://github.com/Azure/sonic-swss-common/pull/534), [1876](https://github.com/Azure/sonic-utilities/pull/1876) & [9353](https://github.com/Azure/sonic-buildimage/pull/9353) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/434a5fcc8a5c7f0fe13e163d89ee9af61a06dbd1/doc/flow_counters/flow_counters.md) and below mentioned PR's for more details. +
**Pull Requests** : [858](https://github.com/sonic-net/SONiC/pull/858), [8940](https://github.com/sonic-net/sonic-buildimage/pull/8940), [1951](https://github.com/sonic-net/sonic-swss/pull/1951), [4456](https://github.com/sonic-net/sonic-mgmt/pull/4456), [1868](https://github.com/sonic-net/sonic-utilities/pull/1868), [954](https://github.com/sonic-net/sonic-sairedis/pull/954), [534](https://github.com/sonic-net/sonic-swss-common/pull/534), [1876](https://github.com/sonic-net/sonic-utilities/pull/1876) & [9353](https://github.com/sonic-net/sonic-buildimage/pull/9353) #### L2 functional and performance enhancements This implentation provides enhancements in SONiC layer 2 forwarding for FDB flush, MAC move, FDB aging time configuration, Static FDB configuration and VLAN Range configuration. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/layer2-forwarding-enhancements/SONiC%20Layer%202%20Forwarding%20Enhancements%20HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [379](https://github.com/Azure/SONiC/pull/379), [510](https://github.com/Azure/sonic-sairedis/pull/510), [303](https://github.com/Azure/sonic-swss-common/pull/303), [529](https://github.com/Azure/sonic-utilities/pull/529) & [1716](https://github.com/Azure/sonic-swss/pull/1716) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/layer2-forwarding-enhancements/SONiC%20Layer%202%20Forwarding%20Enhancements%20HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [379](https://github.com/sonic-net/SONiC/pull/379), [510](https://github.com/sonic-net/sonic-sairedis/pull/510), [303](https://github.com/sonic-net/sonic-swss-common/pull/303), [529](https://github.com/sonic-net/sonic-utilities/pull/529) & [1716](https://github.com/sonic-net/sonic-swss/pull/1716) #### New branch creation for Debian11 In preparation for Debian Bullseye, upgrade SONiC's base system to be based on Bullseye, which was released in August 2021.Kernel is now based on 5.10.x (currently, official Debian Bullseye is publishing the 5.10.70 kernel) Most Python 2 packages (as well as pip2.7) have been removed from Bullseye. The Python 2 interpreter is still available. The kernel has been upgraded to 5.10.46, and the base system is now based on Bullseye. Containers are still based on Buster. -Refer [PR#8191](https://github.com/Azure/sonic-buildimage/pull/8191) for more details. +Refer [PR#8191](https://github.com/sonic-net/sonic-buildimage/pull/8191) for more details. #### One line command to extract multiple DBs info of a SONiC component In SONiC, there usually exists a set of tables related/relevant to a particular module. All of these have to be looked at to confirm whether any configuration update is properly applied and propagated.The task of debugging quickly becomes tedious because currently, there is no utility which does print a unified view of the redis-state. This is the problem which is addressed by this dump utility.This utility provides the base infrastructure and guidelines to make is easy for the developers to extend and support the utility for different modules. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/Dump-Utility.md) and below mentioned PR's for more details. -
**Pull Requests** : [789](https://github.com/Azure/SONiC/pull/789), [1666](https://github.com/Azure/sonic-utilities/pull/1666), [1667](https://github.com/Azure/sonic-utilities/pull/1667), [1668](https://github.com/Azure/sonic-utilities/pull/1668), [1669](https://github.com/Azure/sonic-utilities/pull/1669), [1670](https://github.com/Azure/sonic-utilities/pull/1670), [1853](https://github.com/Azure/sonic-utilities/pull/1853), [1877](https://github.com/Azure/sonic-utilities/pull/1877), [1913](https://github.com/Azure/sonic-utilities/pull/1913) & [1892](https://github.com/Azure/sonic-utilities/pull/1892) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/Dump-Utility.md) and below mentioned PR's for more details. +
**Pull Requests** : [789](https://github.com/sonic-net/SONiC/pull/789), [1666](https://github.com/sonic-net/sonic-utilities/pull/1666), [1667](https://github.com/sonic-net/sonic-utilities/pull/1667), [1668](https://github.com/sonic-net/sonic-utilities/pull/1668), [1669](https://github.com/sonic-net/sonic-utilities/pull/1669), [1670](https://github.com/sonic-net/sonic-utilities/pull/1670), [1853](https://github.com/sonic-net/sonic-utilities/pull/1853), [1877](https://github.com/sonic-net/sonic-utilities/pull/1877), [1913](https://github.com/sonic-net/sonic-utilities/pull/1913) & [1892](https://github.com/sonic-net/sonic-utilities/pull/1892) #### Overlay ECMP This feature provides Vxlan Overlay ECMP feature implementation in SONiC with BFD support. This is an extension to the existing VNET Vxlan support as defined in the Vxlan HLD. -Refer [HLD document](https://github.com/Azure/SONiC/blob/b9f1e94235553c825de67d244c9e8836f369b965/doc/vxlan/Overlay%20ECMP%20with%20BFD.md) and below mentioned PR's for more details. -
**Pull Requests** : [861](https://github.com/Azure/SONiC/pull/861), [1960](https://github.com/Azure/sonic-swss/pull/1960), [9197](https://github.com/Azure/sonic-uildimage/pull/9197), [96](https://github.com/Azure/sonic-restapi/pull/96), [1955](https://github.com/Azure/sonic-swss/pull/1955)[903](https://github.com/Azure/sonic-sairedis/pull/903), [1883](https://github.com/Azure/sonic-swss/pull/1883) & [1942](https://github.com/Azure/sonic-utilities/pull/1942) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/b9f1e94235553c825de67d244c9e8836f369b965/doc/vxlan/Overlay%20ECMP%20with%20BFD.md) and below mentioned PR's for more details. +
**Pull Requests** : [861](https://github.com/sonic-net/SONiC/pull/861), [1960](https://github.com/sonic-net/sonic-swss/pull/1960), [9197](https://github.com/sonic-net/sonic-uildimage/pull/9197), [96](https://github.com/sonic-net/sonic-restapi/pull/96), [1955](https://github.com/sonic-net/sonic-swss/pull/1955)[903](https://github.com/sonic-net/sonic-sairedis/pull/903), [1883](https://github.com/sonic-net/sonic-swss/pull/1883) & [1942](https://github.com/sonic-net/sonic-utilities/pull/1942) #### PDK - Platform Development Environment SONiC OS is portable across different network devices with supported ASIC via Switch Abstraction Interface (SAI). These devices primarily differ in the way various device specific hardware components are accessed, and thus require custom device drivers and python plugins. Each platform vendor implements these custom device drivers and plugins. The feature requirement is to support a SONiC platform driver development framework to enable rapid development of custom device drivers and plugins. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/platform/brcm_pdk_pddf.md) and below mentioned PR's for more details. -
**Pull Requests** : [3387](https://github.com/Azure/sonic-buildimage/pull/3387), [624](https://github.com/Azure/sonic-utilities/pull/624), [62](https://github.com/Azure/sonic-platform-common/pull/62) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/platform/brcm_pdk_pddf.md) and below mentioned PR's for more details. +
**Pull Requests** : [3387](https://github.com/sonic-net/sonic-buildimage/pull/3387), [624](https://github.com/sonic-net/sonic-utilities/pull/624), [62](https://github.com/sonic-net/sonic-platform-common/pull/62) #### PINS (P4 Integrated Network Stack) This feature describes PINS (P4 Integrated Network Stack), a P4RT based SDN interface for SONiC. P4RT for SONiC is opt-in, has familiar interfaces, enables rapid innovation, provides automated validation, and serves as unambiguous documentation. A canonical family of P4 programs documents the packet forwarding pipeline of SAI. Remote SDN controllers will use these P4 programs to control the switch forwarding behavior over the P4RT API. Refer [HLD document](https://github.com/pins/SONiC/blob/pins-hld/doc/pins/pins_hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [841](https://github.com/Azure/SONiC/issues/841), [809](https://github.com/Azure/SONiC/pull/809), [826](https://github.com/Azure/SONiC/pull/826), [825](https://github.com/Azure/SONiC/pull/825), [840](https://github.com/Azure/SONiC/pull/840), [852](https://github.com/Azure/SONiC/pull/852), [846](https://github.com/Azure/SONiC/pull/846), [850](https://github.com/Azure/SONiC/pull/850) & [836](https://github.com/Azure/SONiC/pull/836) +
**Pull Requests** : [841](https://github.com/sonic-net/SONiC/issues/841), [809](https://github.com/sonic-net/SONiC/pull/809), [826](https://github.com/sonic-net/SONiC/pull/826), [825](https://github.com/sonic-net/SONiC/pull/825), [840](https://github.com/sonic-net/SONiC/pull/840), [852](https://github.com/sonic-net/SONiC/pull/852), [846](https://github.com/sonic-net/SONiC/pull/846), [850](https://github.com/sonic-net/SONiC/pull/850) & [836](https://github.com/sonic-net/SONiC/pull/836) #### Reclaim reserved buffer for unused ports Originally, the reserved buffer is reclaimed by removing buffer objects of the unused ports. However, this introduces inconsistency. To resolve this zero buffer profiles are introduced to indicate 0 reserved size of a buffer object. Removing a buffer object indicates setting the buffer object to SDK default value. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/qos/reclaim-reserved-buffer-images/reclaim-reserved-buffer-sequence-flow.md) and below mentioned PR's for more details. -
**Pull Requests** : [831](https://github.com/Azure/SONiC/pull/831) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/qos/reclaim-reserved-buffer-images/reclaim-reserved-buffer-sequence-flow.md) and below mentioned PR's for more details. +
**Pull Requests** : [831](https://github.com/sonic-net/SONiC/pull/831) #### Routed sub-interface naming convention A sub port interface is a logical interface that can be created on a physical port or a port channel. A sub port interface serves as an interface to either a .1D bridge or a VRF, but not both. This feature design focuses on the use case of creating a sub port interface on a physical port or a port channel and using it as a router interface to a VRF. -Refer [HLD document](https://github.com/Azure/SONiC/blob/d1b715a9cc762eff084d953581633e2a94115bac/doc/subport/sonic-sub-port-intf-hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [833](https://github.com/Azure/SONiC/pull/833), [2017](https://github.com/Azure/sonic-swss/pull/2017), [1907](https://github.com/Azure/sonic-swss/pull/1907), [8761](https://github.com/Azure/sonic-buildimage/pull/8761) & [1821](https://github.com/Azure/sonic-utilities/pull/1821) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/d1b715a9cc762eff084d953581633e2a94115bac/doc/subport/sonic-sub-port-intf-hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [833](https://github.com/sonic-net/SONiC/pull/833), [2017](https://github.com/sonic-net/sonic-swss/pull/2017), [1907](https://github.com/sonic-net/sonic-swss/pull/1907), [8761](https://github.com/sonic-net/sonic-buildimage/pull/8761) & [1821](https://github.com/sonic-net/sonic-utilities/pull/1821) #### SONiC for MPLS Dataplane This implementation is about the initial support for MPLS in SONiC infrastructure. The focus of this initial MPLS support is to expand existing SONiC infrastructure for IPv4/IPv6 routing to include equivalent MPLS functionality. The expected use case for this initial MPLS support is static LSP routing. -Refer [HLD document](https://github.com/Azure/SONiC/blob/dc4a7ae5be75e8e376f9e95692e678aee0fb5dac/doc/mpls/MPLS_hld.md) and below mentioned PR's for more details. -
**Pull Requests** : [706](https://github.com/Azure/SONiC/pull/706), [1181](https://github.com/opencomputeproject/SAI/pull/1181), [815](https://github.com/Azure/sonic-sairedis/pull/815), [824](https://github.com/Azure/sonic-sairedis/pull/824), [469](https://github.com/Azure/sonic-swss-common/pull/469), [7195](https://github.com/Azure/sonic-buildimage/pull/7195), [1686](https://github.com/Azure/sonic-swss/pull/1686), [1537](https://github.com/Azure/sonic-utilities/pull/1537), [1871](https://github.com/Azure/sonic-swss/pull/1871), [7881](https://github.com/Azure/sonic-buildimage/pull/7881) & [3483](https://github.com/Azure/sonic-mgmt/pull/3483) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/dc4a7ae5be75e8e376f9e95692e678aee0fb5dac/doc/mpls/MPLS_hld.md) and below mentioned PR's for more details. +
**Pull Requests** : [706](https://github.com/sonic-net/SONiC/pull/706), [1181](https://github.com/opencomputeproject/SAI/pull/1181), [815](https://github.com/sonic-net/sonic-sairedis/pull/815), [824](https://github.com/sonic-net/sonic-sairedis/pull/824), [469](https://github.com/sonic-net/sonic-swss-common/pull/469), [7195](https://github.com/sonic-net/sonic-buildimage/pull/7195), [1686](https://github.com/sonic-net/sonic-swss/pull/1686), [1537](https://github.com/sonic-net/sonic-utilities/pull/1537), [1871](https://github.com/sonic-net/sonic-swss/pull/1871), [7881](https://github.com/sonic-net/sonic-buildimage/pull/7881) & [3483](https://github.com/sonic-net/sonic-mgmt/pull/3483) #### SONiC Generic Update and Rollback The SONiC Generic Update and Rollback feature is to standardize the way to do partial updates, to take checkpoints and finally to rollback the configurations for SONiC. Refer [HLD document](https://github.com/ghooo/SONiC/blob/c1f3f3b5427d0cafb3defd93df8b906a26fcee8a/doc/config-generic-update-rollback/SONiC_Generic_Config_Update_and_Rollback_Design.md) and below mentioned PR's for more details. -
**Pull Requests** : [736](https://github.com/Azure/SONiC/pull/736), [1536](https://github.com/Azure/sonic-utilities/pull/1536), [1599](https://github.com/Azure/sonic-utilities/pull/1599), [1762](https://github.com/Azure/sonic-utilities/pull/1762), [1794](https://github.com/Azure/sonic-utilities/pull/1794), [1831](https://github.com/Azure/sonic-utilities/pull/1831), [1856](https://github.com/Azure/sonic-utilities/pull/1856), [1864](https://github.com/Azure/sonic-utilities/pull/1864), [1885](https://github.com/Azure/sonic-utilities/pull/1885), [1901](https://github.com/Azure/sonic-utilities/pull/1901), [1919](https://github.com/Azure/sonic-utilities/pull/1919), [1923](https://github.com/Azure/sonic-utilities/pull/1923), [1929](https://github.com/Azure/sonic-utilities/pull/1929), [1934](https://github.com/Azure/sonic-utilities/pull/1934), [1969](https://github.com/Azure/sonic-utilities/pull/1969), [1973](https://github.com/Azure/sonic-utilities/pull/1973), [1977](https://github.com/Azure/sonic-utilities/pull/1977), [1981](https://github.com/Azure/sonic-utilities/pll/1981), [1983](https://github.com/Azure/sonic-utilities/pull/1983), [1987](https://github.com/Azure/sonic-utilities/pull/1987), [1988](https://github.com/Azure/sonic-utilities/pull/1988), [2003](https://github.com/Azure/sonic-utilities/pull/2003), [2006](https://github.com/Azure/sonic-utilities/pull/2006), [2008](https://github.com/Azure/sonic-utilities/pull/2008), [2015](https://github.com/Azure/sonic-utilities/pull/2015), [2020](https://github.com/Azure/sonic-utilities/pull/2020) & [2028](https://github.com/Azure/sonic-utilities/pull/2028) +
**Pull Requests** : [736](https://github.com/sonic-net/SONiC/pull/736), [1536](https://github.com/sonic-net/sonic-utilities/pull/1536), [1599](https://github.com/sonic-net/sonic-utilities/pull/1599), [1762](https://github.com/sonic-net/sonic-utilities/pull/1762), [1794](https://github.com/sonic-net/sonic-utilities/pull/1794), [1831](https://github.com/sonic-net/sonic-utilities/pull/1831), [1856](https://github.com/sonic-net/sonic-utilities/pull/1856), [1864](https://github.com/sonic-net/sonic-utilities/pull/1864), [1885](https://github.com/sonic-net/sonic-utilities/pull/1885), [1901](https://github.com/sonic-net/sonic-utilities/pull/1901), [1919](https://github.com/sonic-net/sonic-utilities/pull/1919), [1923](https://github.com/sonic-net/sonic-utilities/pull/1923), [1929](https://github.com/sonic-net/sonic-utilities/pull/1929), [1934](https://github.com/sonic-net/sonic-utilities/pull/1934), [1969](https://github.com/sonic-net/sonic-utilities/pull/1969), [1973](https://github.com/sonic-net/sonic-utilities/pull/1973), [1977](https://github.com/sonic-net/sonic-utilities/pull/1977), [1981](https://github.com/sonic-net/sonic-utilities/pll/1981), [1983](https://github.com/sonic-net/sonic-utilities/pull/1983), [1987](https://github.com/sonic-net/sonic-utilities/pull/1987), [1988](https://github.com/sonic-net/sonic-utilities/pull/1988), [2003](https://github.com/sonic-net/sonic-utilities/pull/2003), [2006](https://github.com/sonic-net/sonic-utilities/pull/2006), [2008](https://github.com/sonic-net/sonic-utilities/pull/2008), [2015](https://github.com/sonic-net/sonic-utilities/pull/2015), [2020](https://github.com/sonic-net/sonic-utilities/pull/2020) & [2028](https://github.com/sonic-net/sonic-utilities/pull/2028) #### SRv6 support (Cntd) SRv6 has been widely adopted as an IPv6 based SDN solution, which provides programming ability, TE capabilities, and deployment simplicity to network administrators. With current support from a rich ecosystem, including major ASIC manufactures, networking vendors and open source communities, the deployment of SRv6 is accelerating. This implentation adds SRv6 into SONIC to benefit users in DC as well as beyond DC. -Refer [HLD document](https://github.com/Azure/SONiC/blob/faa432df6185f7c04d896285db61ac86300161c9/doc/srv6/srv6-hld-v19.md) and below mentioned PR's for more details. -
**Pull Requests** : [795](https://github.com/Azure/SONiC/pull/795), [9238](https://github.com/Azure/sonic-buildimage/pull/9238), [538](https://github.com/Azure/sonic-swss-common/pull/538), [1964](https://github.com/Azure/sonic-swss/pull/1964) & [1883](https://github.com/Azure/sonic-utilities/pull/1883) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/faa432df6185f7c04d896285db61ac86300161c9/doc/srv6/srv6-hld-v19.md) and below mentioned PR's for more details. +
**Pull Requests** : [795](https://github.com/sonic-net/SONiC/pull/795), [9238](https://github.com/sonic-net/sonic-buildimage/pull/9238), [538](https://github.com/sonic-net/sonic-swss-common/pull/538), [1964](https://github.com/sonic-net/sonic-swss/pull/1964) & [1883](https://github.com/sonic-net/sonic-utilities/pull/1883) #### Upgrade SONiC init flow This implentation is to introduce a new API for query statistics capabilities of counters in a faster and more efficient way. Currently on SONiC, in order to get the counters capabilities, SONiC is iterating all port stats one by one, to understand the supported capabilities. This operation is time consuming and the new API can reduce the time for this operation in one call. -Refer [HLD document](https://github.com/Azure/SONiC/blob/master/doc/Query_Stats_Capability/Query_Stats_Capability_HLD.md) and below mentioned PR's for more details. -
**Pull Requests** : [871](https://github.com/Azure/SONiC/pull/871) & [952](https://github.com/Azure/sonic-sairedis/pull/952) +Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/Query_Stats_Capability/Query_Stats_Capability_HLD.md) and below mentioned PR's for more details. +
**Pull Requests** : [871](https://github.com/sonic-net/SONiC/pull/871) & [952](https://github.com/sonic-net/sonic-sairedis/pull/952) # SAI APIs diff --git a/doc/Sonic BSL Test plan.md b/doc/Sonic BSL Test plan.md index 8c10a3854f..b8910c8f9a 100644 --- a/doc/Sonic BSL Test plan.md +++ b/doc/Sonic BSL Test plan.md @@ -2,7 +2,7 @@ ## Overview -This document outlines the Sonic BSL test plan. In BSL mode, Sonic device is brought up as an L2 switch. This test plan validates the functionality by running the tests as described in below sections. More details on BSL can be found in this [document](https://github.com/Azure/SONiC/wiki/L2-Switch-mode#3-generate-a-configuration-for-l2-switch-mode). This must be followed to configure a Sonic device in L2 switch and verify the associated commands before running the below test cases. +This document outlines the Sonic BSL test plan. In BSL mode, Sonic device is brought up as an L2 switch. This test plan validates the functionality by running the tests as described in below sections. More details on BSL can be found in this [document](https://github.com/sonic-net/SONiC/wiki/L2-Switch-mode#3-generate-a-configuration-for-l2-switch-mode). This must be followed to configure a Sonic device in L2 switch and verify the associated commands before running the below test cases. ### Scope --------- @@ -18,7 +18,7 @@ L2 configuration on a T0 topology ### Configuration scripts ------------------------- -Configuration is created from https://github.com/Azure/SONiC/wiki/L2-Switch-mode#3-generate-a-configuration-for-l2-switch-mode. After applying configuration, this also has basic verifications of interfaces and oper status. +Configuration is created from https://github.com/sonic-net/SONiC/wiki/L2-Switch-mode#3-generate-a-configuration-for-l2-switch-mode. After applying configuration, this also has basic verifications of interfaces and oper status. The following is an example script to create config file for Mellanox platform ``` @@ -38,7 +38,7 @@ Verify basic sanity. This checks if the orchagent and syncd processes are runnin Triggered before and after each test case #### Test description -Run sanity check - https://github.com/Azure/sonic-mgmt/blob/master/tests/common/sanity_check.py +Run sanity check - https://github.com/sonic-net/sonic-mgmt/blob/master/tests/common/sanity_check.py ### Test case \#2 @@ -46,7 +46,7 @@ Run sanity check - https://github.com/Azure/sonic-mgmt/blob/master/tests/common/ Verify FDB learning happens on all ports. #### Test description -Run fdb test - https://github.com/Azure/sonic-mgmt/blob/master/tests/fdb/test_fdb.py +Run fdb test - https://github.com/sonic-net/sonic-mgmt/blob/master/tests/fdb/test_fdb.py ### Test case \#3 @@ -56,14 +56,14 @@ Verify Vlan configurations, ARP and PING. The current vlan test (vlantb) has two This test covers Vlan, ARP and PING tests. #### Test description -Run fdb test - https://github.com/Azure/sonic-mgmt/blob/master/tests/vlan/test_vlan.py +Run fdb test - https://github.com/sonic-net/sonic-mgmt/blob/master/tests/vlan/test_vlan.py ### Test case \#4 #### Test objective -Verify SNMP. This [document](https://github.com/Azure/SONiC/wiki/How-to-Check-SNMP-Configuration) can be referred for basic SNMP verification and configuring public community string +Verify SNMP. This [document](https://github.com/sonic-net/SONiC/wiki/How-to-Check-SNMP-Configuration) can be referred for basic SNMP verification and configuring public community string The BSL test can cover to get 1. MAC table @@ -73,9 +73,9 @@ Verify SNMP. This [document](https://github.com/Azure/SONiC/wiki/How-to-Check-SN #### Test description Run SNMP tests: - - https://github.com/Azure/sonic-mgmt/tree/master/tests/snmp/test_snmp_interfaces.py - - https://github.com/Azure/sonic-mgmt/tree/master/tests/snmp/test_snmp_cpu.py - - https://github.com/Azure/sonic-mgmt/tree/master/tests/snmp/test_snmp_psu.py + - https://github.com/sonic-net/sonic-mgmt/tree/master/tests/snmp/test_snmp_interfaces.py + - https://github.com/sonic-net/sonic-mgmt/tree/master/tests/snmp/test_snmp_cpu.py + - https://github.com/sonic-net/sonic-mgmt/tree/master/tests/snmp/test_snmp_psu.py | **\#** | **Test Description** | **Expected Result** | |--------|----------------------|---------------------| diff --git a/doc/aaa/TACACS+ Design.md b/doc/aaa/TACACS+ Design.md index 6d4cbabf52..6ab382b048 100644 --- a/doc/aaa/TACACS+ Design.md +++ b/doc/aaa/TACACS+ Design.md @@ -307,7 +307,7 @@ The following figure show how Auditd config an TACACS+ config update by ConfigDB ## 4.3 ConfigDB Schema - - Existing tables, for more detail please check [TACACS+ Authentication](https://github.com/Azure/SONiC/blob/master/doc/aaa/TACACS%2B%20Authentication.md#aaa-table-schema) + - Existing tables, for more detail please check [TACACS+ Authentication](https://github.com/sonic-net/SONiC/blob/master/doc/aaa/TACACS%2B%20Authentication.md#aaa-table-schema) - TACPLUS Table - TACPLUS_SERVER Table. - AAA Table (updated). @@ -319,7 +319,7 @@ login = LIST(1*32VCHAR) ; AAA protocol, now only support (local fallback = "True" / "False" ; fallback mechanism for pam modules failthrough = "True" / "False" ; failthrough mechanism for pam modules ``` -* According to [TACACS+ Authentication](https://github.com/Azure/SONiC/blob/master/doc/aaa/TACACS%2B%20Authentication.md#aaa-table-schema), the 'login' attribute should be 'protocol' attribute , But in current SONiC [yang model](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-system-aaa.yang), this attribute name is 'login'. Because change the attribute name may break backward compatibility, so keep will use 'login' as attribute name. +* According to [TACACS+ Authentication](https://github.com/sonic-net/SONiC/blob/master/doc/aaa/TACACS%2B%20Authentication.md#aaa-table-schema), the 'login' attribute should be 'protocol' attribute , But in current SONiC [yang model](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-system-aaa.yang), this attribute name is 'login'. Because change the attribute name may break backward compatibility, so keep will use 'login' as attribute name. ## 4.4 CLI - The existing TACACS+ server config command will not change. @@ -547,7 +547,7 @@ Schema in [TACACS+ Authentication](#TACPLUS-Authentication)). ## RFC8907 https://datatracker.ietf.org/doc/html/rfc8907 ## TACACS+ Authentication -https://github.com/Azure/SONiC/blob/master/doc/aaa/TACACS%2B%20Authentication.md +https://github.com/sonic-net/SONiC/blob/master/doc/aaa/TACACS%2B%20Authentication.md ## Bash https://www.gnu.org/software/bash/html ## pam_tacplus diff --git a/doc/aaa/TACACS+ Test Plan.md b/doc/aaa/TACACS+ Test Plan.md index 25c311fac3..6f79ff33f0 100644 --- a/doc/aaa/TACACS+ Test Plan.md +++ b/doc/aaa/TACACS+ Test Plan.md @@ -4,7 +4,7 @@ Related documents | **Document Name** | **Link** | |-------------------|----------| -| AAA_with_SONiC_v2 | [https://github.com/Azure/SONiC/blob/gh-pages/doc/AAA_with_SONiC_v2.docx](https://github.com/Azure/SONiC/blob/gh-pages/doc/AAA_with_SONiC_v2.docx) | +| AAA_with_SONiC_v2 | [https://github.com/sonic-net/SONiC/blob/gh-pages/doc/aaa/AAA_with_SONiC_v2.docx](https://github.com/sonic-net/SONiC/blob/gh-pages/doc/aaa/AAA_with_SONiC_v2.docx) | | pam_tacplus | [https://github.com/jeroennijhof/pam_tacplus/blob/master/README.md](https://github.com/jeroennijhof/pam_tacplus/blob/master/README.md) | | tacacs+ daemon | [http://manpages.ubuntu.com/manpages/xenial/man8/tac_plus.8.html](http://manpages.ubuntu.com/manpages/xenial/man8/tac_plus.8.html) | diff --git a/doc/aaa/radius_authentication.md b/doc/aaa/radius_authentication.md index 20ed646603..02970a0d0b 100644 --- a/doc/aaa/radius_authentication.md +++ b/doc/aaa/radius_authentication.md @@ -857,7 +857,7 @@ http://man7.org/linux/man-pages/man5/nsswitch.conf.5.html ## TACPLUS Authentication -https://github.com/Azure/SONiC/blob/master/doc/aaa/TACACS%2B%20Authentication.md +https://github.com/sonic-net/SONiC/blob/master/doc/aaa/TACACS%2B%20Authentication.md ## pam_radius diff --git a/doc/acl/ACL-High-Level-Design.md b/doc/acl/ACL-High-Level-Design.md index 74ff25c25e..8c1afa22f5 100644 --- a/doc/acl/ACL-High-Level-Design.md +++ b/doc/acl/ACL-High-Level-Design.md @@ -548,18 +548,18 @@ for egress ACL rule. Add possibility to receive updates about mirror sessions state change and perform mirroring rules state change accordingly. # 4 Flows ## 4.1 Creating of ACL Objects -![](https://github.com/Azure/SONiC/blob/master/images/acl_hld/acl_create.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/acl_hld/acl_create.png) ## 4.2 Deleting of ACL Objects -![](https://github.com/Azure/SONiC/blob/master/images/acl_hld/acl_delete.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/acl_hld/acl_delete.png) ## 4.3 Updating of ACL Objects Depending on the number of changed properties in the updated ACL object, update may include one or more extra delete/create calls to the SAI Redis. -![](https://github.com/Azure/SONiC/blob/master/images/acl_hld/acl_update.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/acl_hld/acl_update.png) ## 4.4 Creating of ACL Mirror rules -![](https://github.com/Azure/SONiC/blob/master/images/acl_hld/acl_mirror_rule_flow.svg) +![](https://github.com/sonic-net/SONiC/blob/master/images/acl_hld/acl_mirror_rule_flow.svg) ## 4.5 Deleting of ACL Mirror rules -![](https://github.com/Azure/SONiC/blob/master/images/acl_hld/mirror_delete.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/acl_hld/mirror_delete.png) ## 4.6 Mirror state change handling -![](https://github.com/Azure/SONiC/blob/master/images/acl_hld/mirror_state_change.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/acl_hld/mirror_state_change.png) # 5 swssconfig input file format and restrictions - Valid json file. The file should be in the format swssconfig can process. This assumes lists surrounded by square brackets, dictionaries with curly brackets (braces), tuples inside dictionary separated with semicolon and enumerated elements separated with the comma. - Logical consistency. The configuration provided should be complete. Rules should not refer non-existing tables, etc. diff --git a/doc/acl/ACL-Ingress-Egress-test-plan.md b/doc/acl/ACL-Ingress-Egress-test-plan.md index de0009c4db..903679ad28 100644 --- a/doc/acl/ACL-Ingress-Egress-test-plan.md +++ b/doc/acl/ACL-Ingress-Egress-test-plan.md @@ -14,7 +14,7 @@ ## The existing test plan and scripts -The existing test plan: https://github.com/Azure/SONiC/wiki/ACL-test-plan +The existing test plan: https://github.com/sonic-net/SONiC/wiki/ACL-test-plan The existing acl test scripts covered ingress ACL on SONiC switch. Supported topo: t1, t1-lag, t1-64-lag diff --git a/doc/acl/Everflow-test-plan.md b/doc/acl/Everflow-test-plan.md index b465acea69..76d0a064a3 100644 --- a/doc/acl/Everflow-test-plan.md +++ b/doc/acl/Everflow-test-plan.md @@ -52,7 +52,7 @@ ## Overview -This document is an updated version of the existing everflow test plan: https://github.com/Azure/SONiC/wiki/Everflow-test-plan +This document is an updated version of the existing everflow test plan: https://github.com/sonic-net/SONiC/wiki/Everflow-test-plan The purpose is to test functionality of Everflow on the SONIC switch DUT with and without LAGs configured, closely resembling production environment. The test assumes all necessary configuration, including Everflow session and ACL rules, LAG configuration and BGP routes, are already pre-configured on the SONIC switch before test runs. @@ -277,10 +277,10 @@ Existing test cases: #### What new enhancements need to be covered? ##### Egress ACL table -In Jan 2019, egress ACL table support is added (https://github.com/Azure/SONiC/pull/322, https://github.com/Azure/sonic-swss/pull/741) to SONiC. Then ACL table can have an extra field `stage` indicting on which stage will the ACL rules be checked against packets. If the `stage` is ignored or is set to 'ingress', the behavior is same as before, ingress packets will be checked against ACL rules. If the `stage` field is set to 'egress', then on ports bound to ACL table, egress packets will be checked against the ACL rules and will be handled according to the action configured for the ACL rules. The action could be `PACKET_ACTION` or `MIRROR_ACTION`. +In Jan 2019, egress ACL table support is added (https://github.com/sonic-net/SONiC/pull/322, https://github.com/sonic-net/sonic-swss/pull/741) to SONiC. Then ACL table can have an extra field `stage` indicting on which stage will the ACL rules be checked against packets. If the `stage` is ignored or is set to 'ingress', the behavior is same as before, ingress packets will be checked against ACL rules. If the `stage` field is set to 'egress', then on ports bound to ACL table, egress packets will be checked against the ACL rules and will be handled according to the action configured for the ACL rules. The action could be `PACKET_ACTION` or `MIRROR_ACTION`. ##### Egress mirroring -Besides the egress ACL table support, a recent enhancement (Design: https://github.com/Azure/SONiC/pull/411 Implementations: https://github.com/Azure/sonic-swss/pull/963 https://github.com/Azure/sonic-utilities/pull/575) added egress mirroring support. This enhancement added two ACL rule action types based on the existing mirroring action `MIRROR_ACTION`: +Besides the egress ACL table support, a recent enhancement (Design: https://github.com/sonic-net/SONiC/pull/411 Implementations: https://github.com/sonic-net/sonic-swss/pull/963 https://github.com/sonic-net/sonic-utilities/pull/575) added egress mirroring support. This enhancement added two ACL rule action types based on the existing mirroring action `MIRROR_ACTION`: * MIRROR_INGRESS_ACTION * MIRROR_EGRESS_ACTION diff --git a/doc/acl/egress-acl-bug-fix-description.md b/doc/acl/egress-acl-bug-fix-description.md index 667111de12..2d9e415d38 100644 --- a/doc/acl/egress-acl-bug-fix-description.md +++ b/doc/acl/egress-acl-bug-fix-description.md @@ -68,7 +68,7 @@ To have both mirror action supported, we need to extend AclRuleMirror and the cr - flow chart after add the new flow - ![](https://github.com/Azure/SONiC/blob/master/images/acl_hld/acl_mirror_rule_flow.svg) + ![](https://github.com/sonic-net/SONiC/blob/master/images/acl_hld/acl_mirror_rule_flow.svg) ### 3. New SWSS virtual test Added to cover the egress ACL support diff --git a/doc/arp/Proxy Arp.md b/doc/arp/Proxy Arp.md index 5ea3f6c40b..6b9e9dc0f0 100644 --- a/doc/arp/Proxy Arp.md +++ b/doc/arp/Proxy Arp.md @@ -57,14 +57,14 @@ The following flow diagram captures two example, one for user configuration and ## Kernel config -![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/proxy_arp_kernel.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/proxy_arp_kernel.png) ## SAI config For requirement #2, the proposal is to disable flooding for the specific Vlan so that ARP packets shall not get flooded in hardware. By default in Sonic, it is a copy action for ARP packets which means, packets gets flooded in hardware. In the event of enabling proxy-arp, flooding must be disabled. This enables the switch to respond to ARP requests within this subnet to be responded with its SVI mac. ```Intforch``` must invoke "Vlan flood" disable during the RIF creation based on "prxoy_arp" attribute. -![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/proxy_arp_flood.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/proxy_arp_flood.png) # Additional Notes 1. The flooding is disabled only for those interfaces that has proxy_arp setting. The implementation shall not modify the existing behavior and shall be backward compatible. diff --git a/doc/asic_thermal_monitoring_hld.md b/doc/asic_thermal_monitoring_hld.md index cd7be570a9..57a4af17f1 100644 --- a/doc/asic_thermal_monitoring_hld.md +++ b/doc/asic_thermal_monitoring_hld.md @@ -43,7 +43,7 @@ A configurable ASIC sensors poller is introduced that periodically retrieves the * There should be a way to enable/disable the poller * The polling interval should be configurable (from 5 to 300 secs) 2. The retrieved values should be written to the STATE DB (of each ASIC's DB instance in a multi ASIC platform). -3. The ASIC internal sensor values retrieved should be useable by the Thermal Control infrastructure (https://github.com/Azure/SONiC/blob/master/thermal-control-design.md). +3. The ASIC internal sensor values retrieved should be useable by the Thermal Control infrastructure (https://github.com/sonic-net/SONiC/blob/master/thermal-control-design.md). ### 5.2 CLI requirements @@ -103,7 +103,7 @@ In the timer callback, the following actions are performed: ### 6.3 Platform changes to support ASIC Thermals -Platform owners typically provide the implementation for Thermals (https://github.com/Azure/sonic-platform-common/blob/master/sonic_platform_base/thermal_base.py). While there is no change in existing Platform API definitions, apart from external/CPU sensors, platform vendors should also include ASIC internal sensors in the _thermal_list[] of the Chassis / Module implementations. +Platform owners typically provide the implementation for Thermals (https://github.com/sonic-net/sonic-platform-common/blob/master/sonic_platform_base/thermal_base.py). While there is no change in existing Platform API definitions, apart from external/CPU sensors, platform vendors should also include ASIC internal sensors in the _thermal_list[] of the Chassis / Module implementations. Assuming a Multi ASIC Chassis with 3 ASICs, the thermal names could be: ASIC0 Internal 0, ... ASIC0 Internal N0, ASIC1 Internal 0, ... ASIC1 Internal N1, ASIC2 Internal 0, ... ASIC2 Internal N2 diff --git a/doc/auto_techsupport_and_coredump_mgmt.md b/doc/auto_techsupport_and_coredump_mgmt.md index 2341abbd95..97704af41b 100644 --- a/doc/auto_techsupport_and_coredump_mgmt.md +++ b/doc/auto_techsupport_and_coredump_mgmt.md @@ -482,7 +482,7 @@ The configuration in the init_cfg.json is loaded to the running config i.e. CONF ### 10 App Extension Considerations -Detailed Info related to Appliation Extension can be found here: https://github.com/Azure/SONiC/blob/master/doc/sonic-application-extension/sonic-application-extention-hld.md +Detailed Info related to Appliation Extension can be found here: https://github.com/sonic-net/SONiC/blob/master/doc/sonic-application-extension/sonic-application-extention-hld.md A new AUTO_TECHSUPPORT_FEATURE register/deregister option will be introduced. The existing FeatureRegistry class will be enahcned to also add/delete configuration related to AUTO_TECHSUPPORT_FEATURE table. diff --git a/doc/barefoot_dtel/Dtel-SONiC.md b/doc/barefoot_dtel/Dtel-SONiC.md index eab7b900b8..faa16ecb95 100644 --- a/doc/barefoot_dtel/Dtel-SONiC.md +++ b/doc/barefoot_dtel/Dtel-SONiC.md @@ -372,7 +372,7 @@ Following is the minimum configuration for each DTel feature to detect intended 1. Reporting enabled on at least one queue with some threshold (latency or depth) set or tail drop enabled. ## Application to configure DTel via SONiC -Since currently there is no SONiC CLI, users can configure DTel by interacting with ConfigDB. This can be done either directly, through the Redis CLI, or through the use of configuration tools, such as the [Python SwSS SDK](https://github.com/Azure/sonic-py-swsssdk). +Since currently there is no SONiC CLI, users can configure DTel by interacting with ConfigDB. This can be done either directly, through the Redis CLI, or through the use of configuration tools, such as the [Python SwSS SDK](https://github.com/sonic-net/sonic-py-swsssdk). ## euclid diff --git a/doc/barefoot_dtel/Dtel-test-plan.md b/doc/barefoot_dtel/Dtel-test-plan.md index 88ced99d7e..ffb89c30d0 100644 --- a/doc/barefoot_dtel/Dtel-test-plan.md +++ b/doc/barefoot_dtel/Dtel-test-plan.md @@ -53,7 +53,7 @@ As an example, setting/getting DSCP attribute for a DTel event object is done us ## Testbed DTel tests will run on __ptf32__ topology described in: -[SONiC test topologies](https://github.com/Azure/sonic-mgmt/blob/master/ansible/doc/README.testbed.Topology.md) +[SONiC test topologies](https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/doc/README.testbed.Topology.md) diff --git a/doc/bfd/BFD HW Offload HLD.md b/doc/bfd/BFD HW Offload HLD.md index 4c109cf9c0..29fb4a1484 100644 --- a/doc/bfd/BFD HW Offload HLD.md +++ b/doc/bfd/BFD HW Offload HLD.md @@ -104,7 +104,7 @@ BFD_SESSION:{{vrf}}:{{ifname}}:{{ipaddr}} An example state transition diagram is as below -![](https://github.com/Azure/SONiC/blob/master/images/bfd/BFD_States.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/bfd/BFD_States.png) ## 2.4 Orchestration Agent @@ -113,7 +113,7 @@ Following orchagents shall be introduced/modified. ### BfdOrch Sonic shall offload the BFD session handling to hardware that has BFD capabilities. A new module, BfdOrch shall be introduced to handle BFD session to monitoring endpoints and check the health of remote endpoints. BfdOrch shall offload the session initiation/sustenance to hardware via SAI APIs and gets the notifications of session state from SAI. The session state shall be updated in STATE_DB and to any other observer orchestration agents. -![](https://github.com/Azure/SONiC/blob/master/images/bfd/BFD_FlowDiagram.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/bfd/BFD_FlowDiagram.png) #### SAI Attributes @@ -135,7 +135,7 @@ In the multihop session, for bfd packet forwarding, this design expects that the The flow of BfdOrch is presented in the following figure. BfdOrch subscribes to the BFD_SESSION_TABLE of APPL_DB and send the corresponding request to program the BFD sessions to syncd accordingly. The BfdOrch also creates the STATE_DB entry of the BFD session which includes the BFD parameters and an initial state. Upon receiving bfd session state change notifications from syncd, BfdOrch update the STATE_DB field to update the BFD session state. -![](https://github.com/Azure/SONiC/blob/master/images/bfd/BFD_Notification.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/bfd/BFD_Notification.png) ## 2.5 Control plane BFD diff --git a/doc/buffer-watermark/watermarks_HLD.md b/doc/buffer-watermark/watermarks_HLD.md index 0ce3993f46..c7600e27e8 100644 --- a/doc/buffer-watermark/watermarks_HLD.md +++ b/doc/buffer-watermark/watermarks_HLD.md @@ -67,7 +67,7 @@ This document describes the high level design of the watermark feature. ## 1.1 System Chart Following diagram describes a top level overview of the architecture: -![](https://github.com/Azure/SONiC/blob/master/images/watermark_HLD/SystemOverview.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/watermark_HLD/SystemOverview.png) ## 1.2 Modules description ### 1.2.1 gRPC @@ -102,7 +102,7 @@ Regular user is able to query the persistent watermark. Regular user is able to When one regular user and the streaming telemetry coexist, they do not interfere with each other. Their behaviors stay the same as described above. So the software should be able to handle the following situations and return the correct watermark values to each user: -![](https://github.com/Azure/SONiC/blob/master/images/watermark_HLD/timeline.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/watermark_HLD/timeline.png) t0 - clear user watermark event @@ -337,7 +337,7 @@ Examples of virtual paths: #### 4.1 Watermark general flow -![](https://github.com/Azure/SONiC/blob/master/images/watermark_HLD/WM_general.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/watermark_HLD/WM_general.png) The core components are the flex counter, watermark orch, DB, CLI. @@ -353,13 +353,13 @@ The Cli reads the watermarks from the tables, formats and outputs it. #### 4.2 Resetting the telemetry period flow -![](https://github.com/Azure/SONiC/blob/master/images/watermark_HLD/WM_period.PNG) +![](https://github.com/sonic-net/SONiC/blob/master/images/watermark_HLD/WM_period.PNG) The watermark orch handles notifications on changes in WATERMARK_TABLE in config DB. The new interval will be assigned to the timer during the timer handling, so the orch will reset the interval only when the current timer expires. #### 4.3 Cli flow -![](https://github.com/Azure/SONiC/blob/master/images/watermark_HLD/WM_cli.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/watermark_HLD/WM_cli.png) ### 5 Open questions diff --git a/doc/cbf/cbf_hld.md b/doc/cbf/cbf_hld.md index eed24e0a35..17e6c730ea 100644 --- a/doc/cbf/cbf_hld.md +++ b/doc/cbf/cbf_hld.md @@ -87,7 +87,7 @@ This design directly changes CONFIG_DB, APPL_DB, orchagent and sairedis. ## 3.2 DB Changes ### 3.2.1 APPL DB -Based on the next hop group split (https://github.com/Azure/SONiC/pull/712) on which this HLD is based on, a new CLASS_BASED_NEXT_HOP_GROUP table will be added to the APPL_DB with the following format: +Based on the next hop group split (https://github.com/sonic-net/SONiC/pull/712) on which this HLD is based on, a new CLASS_BASED_NEXT_HOP_GROUP table will be added to the APPL_DB with the following format: A new table is added to store the NHG maps. ``` @@ -203,7 +203,7 @@ For a new entry in CLASS_BASED_NEXT_HOP_GROUP_TABLE, the orchestration agent wil If the dataplane doesn't have any more room for a new next hop group object, the task will remain in the process queue for the event of space being freed. -There is a special scenario for creating the class based next hop groups, and that is when it references temporary next hop groups (as described in https://github.com/Azure/SONiC/pull/712), as these may be updated at some point which in turn will change their SAI ID. For this scenario, the class based next hop groups will keep a list of their temporary members and periodically check if it's SAI ID has been updated. If so, the SAI_NEXT_HOP_GROUP_MEMBER_ATTR_NEXT_HOP_ID attribute of the class based next hop group member will be updated to the match the new value and if the next hop group was updated to a proper (;-temporary) next hop group object, it will be erased from the specified list. When all the temporary next hop groups have been updated to proper next hop groups, the class based one will stop checking periodically for the updates. +There is a special scenario for creating the class based next hop groups, and that is when it references temporary next hop groups (as described in https://github.com/sonic-net/SONiC/pull/712), as these may be updated at some point which in turn will change their SAI ID. For this scenario, the class based next hop groups will keep a list of their temporary members and periodically check if it's SAI ID has been updated. If so, the SAI_NEXT_HOP_GROUP_MEMBER_ATTR_NEXT_HOP_ID attribute of the class based next hop group member will be updated to the match the new value and if the next hop group was updated to a proper (;-temporary) next hop group object, it will be erased from the specified list. When all the temporary next hop groups have been updated to proper next hop groups, the class based one will stop checking periodically for the updates. For an updated entry in CLASS_BASED_NEXT_HOP_GROUP_TABLE, the orchestration agent will remove the group's previous members and add the updated ones. We do this due to the limitation of the SAI_NEXT_HOP_GROUP_MEMBER_ATTR_INDEX attribute which is CREATE_ONLY and so can't be updated. Instead of accounting for all the possibilities for the index of a member to be updated (by moving it to a different position in the list, removing a member that comes before it or adding a new one before it) which would be exhaustive to handle, we prefer this simpler and more robust solution. The selection map will also be updated in ASIC_DB if necessary. diff --git a/doc/cli_auto_generation/cli_auto_generation.md b/doc/cli_auto_generation/cli_auto_generation.md index c30f98211a..0d2c6689ba 100644 --- a/doc/cli_auto_generation/cli_auto_generation.md +++ b/doc/cli_auto_generation/cli_auto_generation.md @@ -52,7 +52,7 @@ The SONiC CLI Auto-generation tool - is a utility for generating the command-lin To make SONiC NOS more flexible for developers [SONiC Application Extension infrastructure](https://github.com/stepanblyschak/SONiC/blob/sonic-app-ext-3/doc/sonic-application-extention/sonic-application-extention-hld.md) was introduced. -If someone wants to extend the SONiC NOS functionality - the SAE infrastructure should be used. Some of the third-party features that will be integrated into the SONiC - may require the command-line interface. To avoid spending time on the investigation of how to develop and add a new CLI to [sonic-utilities](https://github.com/Azure/sonic-utilities/tree/master) - the CLI Auto-generation utility was introduced. The command line interface that would be generated will be intuitive for people familiar with the SONiC NOS and CONFIG DB schema. +If someone wants to extend the SONiC NOS functionality - the SAE infrastructure should be used. Some of the third-party features that will be integrated into the SONiC - may require the command-line interface. To avoid spending time on the investigation of how to develop and add a new CLI to [sonic-utilities](https://github.com/sonic-net/sonic-utilities/tree/master) - the CLI Auto-generation utility was introduced. The command line interface that would be generated will be intuitive for people familiar with the SONiC NOS and CONFIG DB schema. ## Requirements @@ -70,7 +70,7 @@ A current SONiC NOS architecture does not require changes, because the SONiC CLI There are three main entities: -`YANG model` - YANG model file which contains a description of CONFIG DB schema. Should be written strictly according to [SONiC Yang Model Guidelines](https://github.com/Azure/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md) +`YANG model` - YANG model file which contains a description of CONFIG DB schema. Should be written strictly according to [SONiC Yang Model Guidelines](https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md) `SONiC CLI Auto-generation tool` - a utility that reads the YANG model and produces the Auto-generated CLI plugin. @@ -227,7 +227,7 @@ admin@sonic:~$ config feature-a sub-command-1 add ... __2. For every `container`, that goes after `top-level container`, (top-level container goes after `module`) will be generated dedicated sub-command for `show` and `config` command groups AND in case if `container` is without `list`, for every `leaf` will be generated dedicated sub-command:__ -For instance let's take a PART of existing [sonic-device_metadata.yang](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-device_metadata.yang) +For instance let's take a PART of existing [sonic-device_metadata.yang](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-device_metadata.yang) ###### sonic-device_metadata YANG model ```yang @@ -296,7 +296,7 @@ ACS-MSN2100 UP r-sonic-switch x86_64-mlnx_msn2100-r0 ``` __3. For every `list` element will be generated `add/del/update` commands:__ -For instance let's take a PART of existing [sonic-vlan.yang](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-vlan.yang) +For instance let's take a PART of existing [sonic-vlan.yang](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-vlan.yang) ###### sonic-vlan YANG model ```yang @@ -383,7 +383,7 @@ Vlan11 11 128 up __In case if the YANG models have more than 1 `list` entity inside `container`:__ -For instance let's take a PART of existing [sonic-vlan.yang](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-vlan.yang) +For instance let's take a PART of existing [sonic-vlan.yang](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-vlan.yang) ###### YANG model with 2 lists ```yang @@ -422,7 +422,7 @@ admin@sonic:~$ config vlan-interface add ... __4. For every `leaf-list` element will be generated dedicated `add/del/update` commands, also the user can use a comma-separated list when creating a new list element to fill `leaf-list`. Also will be added dedicated command `clear` to delete all the elements from `leaf-list`:__ -For instance let's take a PART of existing [sonic-vlan.yang](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-vlan.yang) +For instance let's take a PART of existing [sonic-vlan.yang](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-vlan.yang) ###### sonic-vlan YANG model ```yang @@ -625,7 +625,7 @@ No impact for warmboot/fastboot flows. ## Restrictions Limitations -1. The YANG models for Application extension MUST have unique names for constructs - __module__, __container__, that are located on the same nested level in comparison to [existing YANG models](https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-yang-models/yang-models). This needed to avoid an intersection with the existing CLI on the switch. The below [sonic-vlan.yang](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-vlan.yang) has a __module__ name - "sonic-vlan", so the developer can NOT use this "sonic-vlan" name for another module in another YANG mode. +1. The YANG models for Application extension MUST have unique names for constructs - __module__, __container__, that are located on the same nested level in comparison to [existing YANG models](https://github.com/sonic-net/sonic-buildimage/tree/master/src/sonic-yang-models/yang-models). This needed to avoid an intersection with the existing CLI on the switch. The below [sonic-vlan.yang](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-vlan.yang) has a __module__ name - "sonic-vlan", so the developer can NOT use this "sonic-vlan" name for another module in another YANG mode. ```yang module sonic-vlan { diff --git a/doc/config-generic-update-rollback/Json_Change_Application_Design.md b/doc/config-generic-update-rollback/Json_Change_Application_Design.md index 9a247c0e82..f5a914a2ff 100644 --- a/doc/config-generic-update-rollback/Json_Change_Application_Design.md +++ b/doc/config-generic-update-rollback/Json_Change_Application_Design.md @@ -319,7 +319,7 @@ The 3 dots (`...`) in `ValidateService(services, validationCommand, ...)` indica ### 3.1.5 ConfigDB SONiC is managing configuration in a single source of truth - a redisDB instance that we refer as ConfigDB. Applications subscribe to ConfigDB and generate their running configuration correspondingly. -For further details on the ConfigDB, check [SONiC Configuration Database Manual](https://github.com/Azure/SONiC/wiki/Configuration). +For further details on the ConfigDB, check [SONiC Configuration Database Manual](https://github.com/sonic-net/SONiC/wiki/Configuration). ## 3.2 User Interface N/A diff --git a/doc/config-generic-update-rollback/Json_Patch_Ordering_using_YANG_Models_Design.md b/doc/config-generic-update-rollback/Json_Patch_Ordering_using_YANG_Models_Design.md index 969863c107..926d06725d 100644 --- a/doc/config-generic-update-rollback/Json_Patch_Ordering_using_YANG_Models_Design.md +++ b/doc/config-generic-update-rollback/Json_Patch_Ordering_using_YANG_Models_Design.md @@ -76,7 +76,7 @@ This document describes the algorithm of patch ordering described in [SONiC Gene # 1 Feature Overview Please make sure you have reviewed SONiC Generic Configuration Update and Rollback design document especially [Patch Orderer](SONiC_Generic_Config_Update_and_Rollback_Design.md#3114-patch-orderer). -In this design document, we are going to explore using YANG models to order a given JsonPatch of updates. The idea is to make sure the transitions applied to the configurations all result in valid configs according to [SONiC YANG models](https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-yang-models). +In this design document, we are going to explore using YANG models to order a given JsonPatch of updates. The idea is to make sure the transitions applied to the configurations all result in valid configs according to [SONiC YANG models](https://github.com/sonic-net/sonic-buildimage/tree/master/src/sonic-yang-models). YANG models has multiple constrains that can affect ordering (check [YANG 1.1 (RFC7950)](https://tools.ietf.org/html/rfc7950)): * leafref built-in type @@ -333,7 +333,7 @@ Next we recursively go up the tree, this includes at the level of `/ACL_RULE` ta - There can be other moves as the quality of the moves will determine if there is a path to get to the Target Config from the Current Config. ### 2.2.4 Validating config and move -- Validates result config after applying the move against [SONiC YANG models](https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-yang-models). +- Validates result config after applying the move against [SONiC YANG models](https://github.com/sonic-net/sonic-buildimage/tree/master/src/sonic-yang-models). - Validates the operation itself - If we don't validate the operation, then we can always just replace the whole current_config with the whole target_config in one operation. This will always produce a valid result config. - Validating the operation makes sure it does not contain 2 changes that have dependency as JsonChange appliers do not take of ordering. @@ -383,13 +383,13 @@ SONiC YANG models are going to be used for the following: - Host flags/configs for move validation ### 3.1.1 Using YANG Models to Validate Config State -This is a straightforward task and can be done using [SONiC Libynag wrapper](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-mgmt/sonic_yang.py), specifically `validate_data_tree`. +This is a straightforward task and can be done using [SONiC Libynag wrapper](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-mgmt/sonic_yang.py), specifically `validate_data_tree`. ### 3.1.2 Using YANG models to Generate Other Moves Check [2.2.3 Generating all possible moves](#223-generating-all-possible-moves) to learn more about what are the possible moves. YANG models can help with: -- Lines getting removed which have references, can be substituted by deleting their references first as it is required anyway (check [2.2.3.3 Generating Other Moves](#2233-generating-other-moves) for details). Getting the dependency of some data can be done using [SONiC Libynag wrapper](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-mgmt/sonic_yang.py), specifically `find_data_dependencies`. +- Lines getting removed which have references, can be substituted by deleting their references first as it is required anyway (check [2.2.3.3 Generating Other Moves](#2233-generating-other-moves) for details). Getting the dependency of some data can be done using [SONiC Libynag wrapper](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-mgmt/sonic_yang.py), specifically `find_data_dependencies`. - Any other moves should be generated using YANG models, if YANG models data are not enough an extension to YANG models can be added to help with generating new moves. ### 3.1.3 Using YANG models to Host Flags for Move Validation @@ -405,7 +405,7 @@ Some fields are not allowed to be modified and can only be created, such as `/PO SAI_PORT_ATTR_HW_LANE_LIST, ``` -The new extension `create-only` will be added to [YANG models SONiC extensions](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-extension.yang): +The new extension `create-only` will be added to [YANG models SONiC extensions](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-extension.yang): ``` extension create-only { description "During apply-patch operation the field can only be created (i.e. added) or re-created (i.e. removed then added) but cannot be modified (i.e. replaced)."; @@ -431,7 +431,7 @@ Let's take the example [A.2 Dynamic Port Breakout 1 to 4](#a2-dynamic-port-break ``` But the field `lanes` is `create-only` and cannot be modified i.e. replaced. The only way to update the `lanes` field is through deleting then adding its parent the `/PORT/Ethernet0`. -In [port YANG model](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-port.yang), let's mark `lanes` with `create-only`: +In [port YANG model](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-port.yang), let's mark `lanes` with `create-only`: ```diff leaf lanes { mandatory true; @@ -522,9 +522,9 @@ N/A | 11 | Remove 2 items that depends on each other in the same table e.g. /INTERFACE/INTERFACE_LIST and /INTERFACE/INTERFACE_PREFIX_LIST. | | 12 | Add 2 items that depends on each other in the same table e.g. /INTERFACE/INTERFACE_LIST and /INTERFACE/INTERFACE_PREFIX_LIST. | | 13 | Replace a mandatory item e.g. type under ACL_TABLE. | -| 14 | Dynamic port breakout as described [here](https://github.com/Azure/SONiC/blob/master/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md).| +| 14 | Dynamic port breakout as described [here](https://github.com/sonic-net/SONiC/blob/master/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md).| | 15 | Remove an item that has a default value. | -| 16 | Modifying items that rely depends on each other based on a `must` condition rather than direct connection such as `leafref` e.g. /CRM/acl_counter_high_threshold (check [here](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-crm.yang)). | +| 16 | Modifying items that rely depends on each other based on a `must` condition rather than direct connection such as `leafref` e.g. /CRM/acl_counter_high_threshold (check [here](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-crm.yang)). |
@@ -695,4 +695,4 @@ N/A [{"op": "add", "path": "/VLAN_MEMBER/Vlan100|Ethernet3", "value": {"tagging_mode": "untagged"}}], [{"op": "add", "path": "/VLAN_MEMBER/Vlan100|Ethernet0", "value": {"tagging_mode": "untagged"}}], ] -``` \ No newline at end of file +``` diff --git a/doc/config-generic-update-rollback/SONiC_Generic_Config_Update_and_Rollback_Design.md b/doc/config-generic-update-rollback/SONiC_Generic_Config_Update_and_Rollback_Design.md index 246b204d6b..2f803fbc4d 100644 --- a/doc/config-generic-update-rollback/SONiC_Generic_Config_Update_and_Rollback_Design.md +++ b/doc/config-generic-update-rollback/SONiC_Generic_Config_Update_and_Rollback_Design.md @@ -137,7 +137,7 @@ Updating SONiC partial configurations **systematically** has been a challenge fo - Executing `sudo sonic-cfggen -j /tmp/dhcp.json --write-to-db` - Restart `dhcp_relay` service -We have explored [SONiC CLI commands](https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md) to make configuration changes. These CLI commands result in updates to the ConfigDB which are corresponding to the CLI command executed. For example, the config `vlan add 10` will create a new row in the VLAN table of the ConfigDB. But relying on the CLI commands to do partial update is also not feasible as there is no standard way of showing the config after the update. Setting up a different update mechanism for each part of the config is very time consuming and inefficient. +We have explored [SONiC CLI commands](https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md) to make configuration changes. These CLI commands result in updates to the ConfigDB which are corresponding to the CLI command executed. For example, the config `vlan add 10` will create a new row in the VLAN table of the ConfigDB. But relying on the CLI commands to do partial update is also not feasible as there is no standard way of showing the config after the update. Setting up a different update mechanism for each part of the config is very time consuming and inefficient. The other challenge to updating a switch is recoverability via rollback. Rollback needs to be with minimum-disruption e.g. if reverting ACL updates DHCP should not be affected. Currently SONiC has a couple of operations that can be candidates for rollback `config load` and `config reload`. @@ -309,7 +309,7 @@ The `apply-patch` method should help with automating partial config updates, as The `checkpoint` and `rollback` commands should help improve recoverability, can also be used by external systems to help revert failures during `apply-patch` operation. -Human operators can also leverage the `checkpoint` and `rollback` functionalities while doing updates through the CLI using [SONiC CLI commands](https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md). +Human operators can also leverage the `checkpoint` and `rollback` functionalities while doing updates through the CLI using [SONiC CLI commands](https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md). ## 2.2 Functional Description @@ -317,7 +317,7 @@ Human operators can also leverage the `checkpoint` and `rollback` functionalitie The SONiC `apply-patch` command can broadly classified into the following steps #### Stage-1 JSON Patch Verification -Using [YANG SONiC models](https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-yang-models), but the format of the JSON patch is not what YANG SONiC models is built to verify. We will verify using the following steps: +Using [YANG SONiC models](https://github.com/sonic-net/sonic-buildimage/tree/master/src/sonic-yang-models), but the format of the JSON patch is not what YANG SONiC models is built to verify. We will verify using the following steps: 1. Get current running config from ConfigDB as JSON 2. Simulate the patch application on the current config JSON object 3. Verify the the simulated output using YANG SONiC models @@ -540,14 +540,14 @@ All the configuration update operations executed and the output displayed by the The user of the system, can simply be a human operator or a service that can talk to SONiC CLI. The user can only apply-patch if they have an admin permission. Users without admin permissions can only execute dry-run of the operations where they will be able to see the exact changes going to affect the device, without executing these changes. #### 3.1.1.2 SONiC CLI -These are the CLI of SONiC switch to which makes it easy for the users to interact with the system. The CLI commands we are interested in are `config ...` and `show ...`, check [SONiC Command Line Interface Guide](https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md) to learn more about SONiC CLI. +These are the CLI of SONiC switch to which makes it easy for the users to interact with the system. The CLI commands we are interested in are `config ...` and `show ...`, check [SONiC Command Line Interface Guide](https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md) to learn more about SONiC CLI. For further details on the CLI setup, Check [3.2.2 CLI](#322-cli) #### 3.1.1.3 YANG models YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. For further details check [The YANG 1.1 Data Modeling Language](https://tools.ietf.org/html/rfc7950) -SONiC is currently getting on-boarded to YANG data models to help verify and generate the configurations. We will leverage these YANG models to help verify the result of simulating the JsonPatch on ConfigDb, to make sure final outcome adheres to all the constrains defined in the YANG models. For further details check [YANG SONiC models](https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-yang-models). +SONiC is currently getting on-boarded to YANG data models to help verify and generate the configurations. We will leverage these YANG models to help verify the result of simulating the JsonPatch on ConfigDb, to make sure final outcome adheres to all the constrains defined in the YANG models. For further details check [YANG SONiC models](https://github.com/sonic-net/sonic-buildimage/tree/master/src/sonic-yang-models). #### 3.1.1.4 Patch Orderer This component is going to solve the problems discussed in [Stage-2 JSON Patch Ordering](#stage-2-json-patch-ordering). This component is going to help provide an order of execution to the JsonPatch, in such a way when the config is updated in this order, there will be no errors generated on the device. The exact implementation details of this component will not be included in this design document, but we are going to explain in details the contract for any implementation. @@ -675,7 +675,7 @@ Since the order of executing the operation does not matter, the implementor of t #### 3.1.1.6 ConfigDB SONiC is managing configuration in a single source of truth - a redisDB instance that we refer as ConfigDB. Applications subscribe to ConfigDB and generate their running configuration correspondingly. -For further details on the ConfigDB, check [SONiC Configuration Database Manual](https://github.com/Azure/SONiC/wiki/Configuration). +For further details on the ConfigDB, check [SONiC Configuration Database Manual](https://github.com/sonic-net/SONiC/wiki/Configuration). ### 3.1.2 Checkpoint checkpoint-design @@ -905,22 +905,22 @@ N/A | 11 | Remove 2 items that depends on each other in the same table e.g. /INTERFACE/INTERFACE_LIST and /INTERFACE/INTERFACE_PREFIX_LIST. | | 12 | Add 2 items that depends on each other in the same table e.g. /INTERFACE/INTERFACE_LIST and /INTERFACE/INTERFACE_PREFIX_LIST. | | 13 | Replace a mandatory item e.g. type under ACL_TABLE. | -| 14 | Dynamic port breakout as described [here](https://github.com/Azure/SONiC/blob/master/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md).| +| 14 | Dynamic port breakout as described [here](https://github.com/sonic-net/SONiC/blob/master/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md).| | 15 | Remove an item that has a default value. | -| 16 | Modifying items that rely depends on each other based on a `must` condition rather than direct connection such as `leafref` e.g. /CRM/acl_counter_high_threshold (check [here](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-crm.yang)). | -| 17 | [Updating Syslog configs.](https://github.com/Azure/sonic-mgmt/blob/master/tests/generic_config_updater/test_syslog.py) | -| 18 | [Updating AAA configs.](https://github.com/Azure/sonic-mgmt/blob/master/tests/generic_config_updater/test_aaa.py) | -| 19 | [Updating DHCP configs.](https://github.com/Azure/sonic-mgmt/blob/master/tests/generic_config_updater/test_dhcp_relay.py) | +| 16 | Modifying items that rely depends on each other based on a `must` condition rather than direct connection such as `leafref` e.g. /CRM/acl_counter_high_threshold (check [here](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-crm.yang)). | +| 17 | [Updating Syslog configs.](https://github.com/sonic-net/sonic-mgmt/blob/master/tests/generic_config_updater/test_syslog.py) | +| 18 | [Updating AAA configs.](https://github.com/sonic-net/sonic-mgmt/blob/master/tests/generic_config_updater/test_aaa.py) | +| 19 | [Updating DHCP configs.](https://github.com/sonic-net/sonic-mgmt/blob/master/tests/generic_config_updater/test_dhcp_relay.py) | | 20 | Updating IPv6 configs. | | 21 | Updating monitor configs (EverflowAlaysOn). | | 22 | Updating BGP speaker configs. | -| 23 | [Updating BGP listener configs.](https://github.com/Azure/sonic-mgmt/blob/master/tests/generic_config_updater/test_bgpl.py) | +| 23 | [Updating BGP listener configs.](https://github.com/sonic-net/sonic-mgmt/blob/master/tests/generic_config_updater/test_bgpl.py) | | 24 | ~~Updating Bounce Back Routing configs.~~ | -| 25 | [Updating control-plane ACLs (NTP, SNMP, SSH) configs.](https://github.com/Azure/sonic-mgmt/blob/master/tests/generic_config_updater/test_cacl.py) | +| 25 | [Updating control-plane ACLs (NTP, SNMP, SSH) configs.](https://github.com/sonic-net/sonic-mgmt/blob/master/tests/generic_config_updater/test_cacl.py) | | 26 | Updating Ethernet interfaces configs. | -| 27 | [Updating VLAN interfaces configs.](https://github.com/Azure/sonic-mgmt/blob/master/tests/generic_config_updater/test_vlan_interface.py) | -| 28 | [Updating port-channel interfaces configs.](https://github.com/Azure/sonic-mgmt/blob/master/tests/generic_config_updater/test_portchannel_interface.py) | -| 29 | [Updating loopback interfaces configs.](https://github.com/Azure/sonic-mgmt/blob/master/tests/generic_config_updater/test_lo_interface.py) | +| 27 | [Updating VLAN interfaces configs.](https://github.com/sonic-net/sonic-mgmt/blob/master/tests/generic_config_updater/test_vlan_interface.py) | +| 28 | [Updating port-channel interfaces configs.](https://github.com/sonic-net/sonic-mgmt/blob/master/tests/generic_config_updater/test_portchannel_interface.py) | +| 29 | [Updating loopback interfaces configs.](https://github.com/sonic-net/sonic-mgmt/blob/master/tests/generic_config_updater/test_lo_interface.py) | | 30 | Updating BGP prefix hijack configs. | | 31 | Updating QoS headroom pool and buffer pool size. | | 32 | Add/Remove Rack. | diff --git a/doc/console/SONiC-Console-Switch-High-Level-Design.md b/doc/console/SONiC-Console-Switch-High-Level-Design.md index 0aef1c9a0e..179b02471c 100644 --- a/doc/console/SONiC-Console-Switch-High-Level-Design.md +++ b/doc/console/SONiC-Console-Switch-High-Level-Design.md @@ -291,7 +291,7 @@ Below is an example, we can look into the inner topology of a console device: The console device have 4 com ports at front panel with product port numbers from 1 to 4. After we connected the console device to SONiC switch, the SONiC OS will detect 4 tty device and put them under `/dev` directory. -From SONiC aspect, it is hard for us to know how the tty device mapped to physical console port because its depends on the external hardware design and OS kernel behavior. Then we need to create alias for all tty devices by using some rule. Here[[1]](https://github.com/Azure/SONiC/blob/master/doc/udev-terminalserver/udev%20rules%20for%20Terminal%20Server.md) is an design for resolving USB terminal server's port mapping problem by leveraging udev rule, it use the usb hardware metadata which are immutable to determine the relationship between underlying tty devices and front panel ports. +From SONiC aspect, it is hard for us to know how the tty device mapped to physical console port because its depends on the external hardware design and OS kernel behavior. Then we need to create alias for all tty devices by using some rule. Here[[1]](https://github.com/sonic-net/SONiC/blob/master/doc/udev-terminalserver/udev%20rules%20for%20Terminal%20Server.md) is an design for resolving USB terminal server's port mapping problem by leveraging udev rule, it use the usb hardware metadata which are immutable to determine the relationship between underlying tty devices and front panel ports. Regardless of the console device type, the rule is required. We define below function `device_name_mapping()` for determining the alias name for a console port: @@ -769,4 +769,4 @@ If use USB, then the maximum number of add-on console device is specific to the # 9 Reference -1. udev rules design for terminal server. Sandy Li. https://github.com/Azure/SONiC/blob/master/doc/udev-terminalserver/udev%20rules%20for%20Terminal%20Server.md \ No newline at end of file +1. udev rules design for terminal server. Sandy Li. https://github.com/sonic-net/SONiC/blob/master/doc/udev-terminalserver/udev%20rules%20for%20Terminal%20Server.md diff --git a/doc/copp/CoPP Config and Management.md b/doc/copp/CoPP Config and Management.md index 897bbca5c7..82f9e5d13c 100644 --- a/doc/copp/CoPP Config and Management.md +++ b/doc/copp/CoPP Config and Management.md @@ -15,7 +15,7 @@ The following are the high level requirements for CoPP/TRAP managment ## Current behaviour -During SWSS start, the prebuilt [copp.json](https://github.com/Azure/sonic-swss/blob/201911/swssconfig/sample/00-copp.config.json) file is loaded as part of start script [swssconfig.sh](https://github.com/Azure/sonic-buildimage/blob/201911/dockers/docker-orchagent/swssconfig.sh) and written to APP DB. [CoppOrch](https://github.com/Azure/sonic-swss/blob/201911/orchagent/copporch.cpp) then translates it to Host trap/policer tables and programmed to SAI. +During SWSS start, the prebuilt [copp.json](https://github.com/sonic-net/sonic-swss/blob/201911/swssconfig/sample/00-copp.config.json) file is loaded as part of start script [swssconfig.sh](https://github.com/sonic-net/sonic-buildimage/blob/201911/dockers/docker-orchagent/swssconfig.sh) and written to APP DB. [CoppOrch](https://github.com/sonic-net/sonic-swss/blob/201911/orchagent/copporch.cpp) then translates it to Host trap/policer tables and programmed to SAI. ## Proposed behaviour @@ -63,7 +63,7 @@ state = "ok" ``` ### coppmgr -Introduce a *new* CoPP manager, that subscribes for the Config DB CoPP Tables and Feature Tables. Based on the feature enablement, ```coppmgr``` handles the logic to resolve whether a CoPP table shall be written to APP DB for orchagent consumption. Inorder to reduce changes to copporch and for backward compatibility during warmboot, ```coppmgr``` shall use the existing APP_DB schema and implement internal logic to convert the proposed ConfigDB entries to APP DB entries. Similar to existing swss managers, an entry with state "ok" shall be added to STATE_DB. `coppmgrd` must be started by [supervisord.conf](https://github.com/Azure/sonic-buildimage/blob/master/dockers/docker-orchagent/supervisord.conf) first, before any other process is started in swss. During init, ```coppmgr``` shall read the ```copp_cfg.json``` file and apply the default configuration. The default shall not be part of Config_DB entries. ```coppmgr``` shall also read from the config_db during init and apply the logic to merge if there are same entries within the ```copp_cfg.json``` file. +Introduce a *new* CoPP manager, that subscribes for the Config DB CoPP Tables and Feature Tables. Based on the feature enablement, ```coppmgr``` handles the logic to resolve whether a CoPP table shall be written to APP DB for orchagent consumption. Inorder to reduce changes to copporch and for backward compatibility during warmboot, ```coppmgr``` shall use the existing APP_DB schema and implement internal logic to convert the proposed ConfigDB entries to APP DB entries. Similar to existing swss managers, an entry with state "ok" shall be added to STATE_DB. `coppmgrd` must be started by [supervisord.conf](https://github.com/sonic-net/sonic-buildimage/blob/master/dockers/docker-orchagent/supervisord.conf) first, before any other process is started in swss. During init, ```coppmgr``` shall read the ```copp_cfg.json``` file and apply the default configuration. The default shall not be part of Config_DB entries. ```coppmgr``` shall also read from the config_db during init and apply the logic to merge if there are same entries within the ```copp_cfg.json``` file. Trap name added to copp_cfg.json file has to match a feature name exist in FEATURE table in Config DB. In order to handle traps which has no associated feature (such as arp, ip2me), a new field called "always_enabled" will be added to COPP_TRAP table in Config DB. @@ -118,7 +118,7 @@ For this design, considering the limitations, proposal is to go ahead with secon It is desirable to have warmboot functionality from previous release versions of Sonic. Since the existing schema has COPP Group name/key with protocol names (e.g `"COPP_TABLE:trap.group.bgp.lacp"`, there is a limitation in adding any new protocol or trap to an existing CoPP group and seamlessly migrate. However, with this proposal, the following options are considered: 1. The implementation is to do a migration of APP DB entries to new schema. -2. Let ```db_migrator``` remove all previously saved APP_DB entries and let syncd reconcile and remove the TRAP entries during warmboot. Later, ```coppmgr``` can reapply the traps afresh. Also remove COPP_TABLES from being saved in [backup_database](https://github.com/Azure/sonic-utilities/blob/master/scripts/fast-reboot#L234). This may require additional tests to confirm system behaviour during warmboot. +2. Let ```db_migrator``` remove all previously saved APP_DB entries and let syncd reconcile and remove the TRAP entries during warmboot. Later, ```coppmgr``` can reapply the traps afresh. Also remove COPP_TABLES from being saved in [backup_database](https://github.com/sonic-net/sonic-utilities/blob/master/scripts/fast-reboot#L234). This may require additional tests to confirm system behaviour during warmboot. 3. Remove '00-copp.config.json' from being included for checksum calculation in ```files/build_scripts/generate_asic_config_checksum.py``` In addition, the implementation must ensure that backward compatibility is maintained. If the system is boot-up with an *old* config file, the default CoPP tables are to be loaded from ```copp_cfg.json``` and expected to work seamlessly. @@ -146,13 +146,13 @@ The following flow diagram captures the control flow. The following flow captures scenarios for ```boot-up``` sequence and ```config reload```. Default CoPP Tables shall be present in ```copp_cfg.json``` and if the same entry is present in ```config_db.json```, it is expected to be overwritten by ```config_db``` entry. This model ensures user-configuration gets priority over default configuration. -![](https://github.com/Azure/SONiC/blob/master/images/copp/CoppInit_1.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/copp/CoppInit_1.png) ## Copp Manager flow The following flow captures CoPP manager functionality. -![](https://github.com/Azure/SONiC/blob/master/images/copp/CoppManager_1.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/copp/CoppManager_1.png) # Examples diff --git a/doc/crm/Critical-Resource-Monitoring-High-Level-Design.md b/doc/crm/Critical-Resource-Monitoring-High-Level-Design.md index 8aca334897..41c4d077f5 100644 --- a/doc/crm/Critical-Resource-Monitoring-High-Level-Design.md +++ b/doc/crm/Critical-Resource-Monitoring-High-Level-Design.md @@ -64,7 +64,7 @@ This document describes the high level design of the Critical Resource Monitorin | SAI | Swich Abstraction Interface | # 1 Subsystem Requirements Overview ## 1.1 Functional requirements -Detailed description of the Critical Resource Monitoring feature requirements is here: [CRM Requirements](https://github.com/Azure/SONiC/blob/gh-pages/doc/crm/CRM_requirements.md). +Detailed description of the Critical Resource Monitoring feature requirements is here: [CRM Requirements](https://github.com/sonic-net/SONiC/blob/gh-pages/doc/crm/CRM_requirements.md). This section describes the SONiC requirements for Critical Resource Monitoring (CRM) feature. CRM should monitor utilization of ASIC resources by polling SAI attributes. @@ -304,9 +304,9 @@ Commands: ``` # 3 Flows ## 3.1 CRM monitoring -![](https://github.com/Azure/SONiC/blob/gh-pages/images/crm_hld/crm_monitoring_flow.png) +![](https://github.com/sonic-net/SONiC/blob/gh-pages/images/crm_hld/crm_monitoring_flow.png) ## 3.2 CRM CLI config -![](https://github.com/Azure/SONiC/blob/gh-pages/images/crm_hld/crm_cli_config_flow.png) +![](https://github.com/sonic-net/SONiC/blob/gh-pages/images/crm_hld/crm_cli_config_flow.png) ## 3.3 CRM CLI show -![](https://github.com/Azure/SONiC/blob/gh-pages/images/crm_hld/crm_cli_show_flow.png) +![](https://github.com/sonic-net/SONiC/blob/gh-pages/images/crm_hld/crm_cli_show_flow.png) # 4 Open Questions diff --git a/doc/dualtor/active_active_hld.md b/doc/dualtor/active_active_hld.md index 92144a61a0..7928254bb1 100644 --- a/doc/dualtor/active_active_hld.md +++ b/doc/dualtor/active_active_hld.md @@ -314,7 +314,7 @@ Linkmgrd will provide the determination of a ToR / link's readiness for use. ![grpc_failure](./image/gRPC_failure.png) #### 3.3.5 Default route to T1 - If default route to T1 is missing, dual ToR system can suffer from northbound packet loss, hence linkmgrd also monitors defaul route state. If default route is missing, linkmgrd will stop sending ICMP probing request and fake an unhealthy status. This functionality can be disabled as well, the details is included in [default_route](https://github.com/Azure/sonic-linkmgrd/blob/master/doc/default_route.md). + If default route to T1 is missing, dual ToR system can suffer from northbound packet loss, hence linkmgrd also monitors defaul route state. If default route is missing, linkmgrd will stop sending ICMP probing request and fake an unhealthy status. This functionality can be disabled as well, the details is included in [default_route](https://github.com/sonic-net/sonic-linkmgrd/blob/master/doc/default_route.md). To summarize the state transition decision we talk about, and the corresponding gRPC action to take, we have this decision table below: diff --git a/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md b/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md index 137f9d6f8c..304c21c133 100644 --- a/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md +++ b/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md @@ -1061,7 +1061,7 @@ There are some special cases where queue, scheduler group and priority group obj If they are not at default state, that means user has configured them, sai-redis will fail the delete port action. This means, user should remove the configured objects before deleting the port. I,E, User should bring queues/ingress priority groups/scheduler groups that belong to the port to default state (will remove all assigned objects like buffer profile etc). PR in Sairedis and Syncd is available already: -https://github.com/Azure/sonic-sairedis/pull/500 +https://github.com/sonic-net/sonic-sairedis/pull/500 ### Syncd changes @@ -1075,12 +1075,12 @@ However, due to the consumer tables for different objects with batch size, this We will ignore some dependencies check to avoid the crash in syncd, and also add retry logic in syncd to avoid above timing issue. PRs: -https://github.com/Azure/sonic-sairedis/pull/464 -https://github.com/Azure/sonic-sairedis/pull/483 +https://github.com/sonic-net/sonic-sairedis/pull/464 +https://github.com/sonic-net/sonic-sairedis/pull/483 Another issue with syncd today is to support dynamic port breakout feature with warm-reboot. We need dynamically update the port map in syncd for comparison logic to support warm-reboot. PR is available as below: -https://github.com/Azure/sonic-sairedis/pull/515 +https://github.com/sonic-net/sonic-sairedis/pull/515 ## libSAI requirements We need the HW to initialize with the profile that is breakout capable. diff --git a/doc/ecmp/fine_grained_next_hop_hld.md b/doc/ecmp/fine_grained_next_hop_hld.md index 6e111bf4e8..ce66699589 100644 --- a/doc/ecmp/fine_grained_next_hop_hld.md +++ b/doc/ecmp/fine_grained_next_hop_hld.md @@ -156,7 +156,7 @@ BANK = DIGITS LINK = link_name ; Link associated with next-hop-ip, if configured, enables next-hop withdrawal/addition per link's operational state changes ``` -Please refer to the [schema](https://github.com/Azure/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. +Please refer to the [schema](https://github.com/sonic-net/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. ## 2.2 State DB diff --git a/doc/error-handling/error_handling_design_spec.md b/doc/error-handling/error_handling_design_spec.md index 65308e2f4d..fdc28b5d32 100755 --- a/doc/error-handling/error_handling_design_spec.md +++ b/doc/error-handling/error_handling_design_spec.md @@ -262,7 +262,7 @@ family = "IPv4" / "IPv6" ; address family rc = SWSS code ; status code for each neighbour ``` -Please refer to the [schema](https://github.com/Azure/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. +Please refer to the [schema](https://github.com/sonic-net/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. ## 3.5 CLI diff --git a/doc/fast-reboot/Fast-reboot_Flow_Improvements_HLD.md b/doc/fast-reboot/Fast-reboot_Flow_Improvements_HLD.md index f7b044b82e..280a9b6336 100644 --- a/doc/fast-reboot/Fast-reboot_Flow_Improvements_HLD.md +++ b/doc/fast-reboot/Fast-reboot_Flow_Improvements_HLD.md @@ -42,9 +42,9 @@ This new flag can be used later on for any functionality, we want to start only This is to prevent interference in the fast-reboot reconciliation process and impair the performance, for example enablement of flex counters. References: -https://github.com/Azure/SONiC/blob/master/doc/fast-reboot/fastreboot.pdf -https://github.com/Azure/sonic-swss/blob/master/neighsyncd/restore_neighbors.py -https://github.com/Azure/sonic-buildimage/blob/master/dockers/docker-orchagent/enable_counters.py +https://github.com/sonic-net/SONiC/blob/master/doc/fast-reboot/fastreboot.pdf +https://github.com/sonic-net/sonic-swss/blob/master/neighsyncd/restore_neighbors.py +https://github.com/sonic-net/sonic-buildimage/blob/master/dockers/docker-orchagent/enable_counters.py # 2 Functional Requirements @@ -226,4 +226,4 @@ reboot-finalizer.sh (warm-finalizer.sh) script must also be templatized and upda This chapter it taken from SONiC Application Extension Infrastructure HLD: -https://github.com/Azure/SONiC/blob/master/doc/sonic-application-extension/sonic-application-extention-hld.md#warmboot-and-fastboot-design-impact +https://github.com/sonic-net/SONiC/blob/master/doc/sonic-application-extension/sonic-application-extention-hld.md#warmboot-and-fastboot-design-impact diff --git a/doc/flow_counters/routes_flow_counters.md b/doc/flow_counters/routes_flow_counters.md index e52fd1e821..d9d8da6c5b 100644 --- a/doc/flow_counters/routes_flow_counters.md +++ b/doc/flow_counters/routes_flow_counters.md @@ -46,7 +46,7 @@ This document focus on route counter. Flow counter shall utilize the following existing infrastructure: - Generic Counters API - defined in https://github.com/opencomputeproject/SAI/blob/master/doc/SAI-Proposal-Generic-Counters.md and already supported by the SAI layer. This feature shall support binding/unbinding of these Generic counters to/from relevant SONIC objects -- Flex Counters framework - used for background polling and pushing the statistic information to COUNTER DB for later use (e.g. by CLI). A introduction to flex counter can be found at: https://github.com/Azure/SONiC/pull/858. +- Flex Counters framework - used for background polling and pushing the statistic information to COUNTER DB for later use (e.g. by CLI). A introduction to flex counter can be found at: https://github.com/sonic-net/SONiC/pull/858. ![architecture](/doc/flow_counters/route_flow_counter_architecture.png). @@ -409,7 +409,7 @@ As this is a debugging feature, basically, user should not enable this counter d However, if user did it by mistake: -- For fastboot, there is already a mechanism that delays flex counter, nothing needs to be done here. See PR https://github.com/Azure/sonic-swss/pull/1877. +- For fastboot, there is already a mechanism that delays flex counter, nothing needs to be done here. See PR https://github.com/sonic-net/sonic-swss/pull/1877. - For warmboot, routeorch does not handle any DB change except the "resync" during warmboot, it means that route flow counter will not be enabled until warmboot finish. So, no change is required in this feature. Based on the above, this feature shall not introduce any delay in fastboot or warmboot, and this shall be verified by test. diff --git a/doc/kubernetes/Kubernetes-support.md b/doc/kubernetes/Kubernetes-support.md index fdd09272ee..b1665c46b5 100644 --- a/doc/kubernetes/Kubernetes-support.md +++ b/doc/kubernetes/Kubernetes-support.md @@ -444,7 +444,7 @@ Note: SystemState == Up does not really mean the feature is running, as in case # Reboot support ## Warm-reboot support - This [warm-reboot](https://github.com/Azure/SONiC/blob/master/doc/warm-reboot/SONiC_Warmboot.md) support is for updating/restarting with no data-plane disruption. The `/usr/bin/warm_reboot` script is a complex script that does many pre-requisites, kill the containers and eventually call a specific command for reboot. The individual service level support for warm-start lies within its code/implementation-logic. When configured for warm start, upon start-up, the service should be able to acquire its i/p data from all its channels as ever, but instead of pushing it in entirety to the consumer/DB, read the pre-boot data (which is made available in APP-DB), find the diffs as stale/new/update and only push the diffs. With every app doing it and, with some additional complex steps for critical processes like orchagent & syncd, the data plane traffic goes unaffected, except for the changes pushed into ASIC, which is a normal runtime experience of consuming changes as it happens. + This [warm-reboot](https://github.com/sonic-net/SONiC/blob/master/doc/warm-reboot/SONiC_Warmboot.md) support is for updating/restarting with no data-plane disruption. The `/usr/bin/warm_reboot` script is a complex script that does many pre-requisites, kill the containers and eventually call a specific command for reboot. The individual service level support for warm-start lies within its code/implementation-logic. When configured for warm start, upon start-up, the service should be able to acquire its i/p data from all its channels as ever, but instead of pushing it in entirety to the consumer/DB, read the pre-boot data (which is made available in APP-DB), find the diffs as stale/new/update and only push the diffs. With every app doing it and, with some additional complex steps for critical processes like orchagent & syncd, the data plane traffic goes unaffected, except for the changes pushed into ASIC, which is a normal runtime experience of consuming changes as it happens. In short if a service supports warmboot, it would continue to support in both local & kube modes transparently.
The warm_reboot script needs few updates as below.
@@ -467,7 +467,7 @@ Note: SystemState == Up does not really mean the feature is running, as in case For new features that are not known to warm-reboot script, some hooks could be allowed for registration of feature-custom scripts. This could help with some preparation steps before reboot, like caching some data, setting some DB values, ... ## Fast-reboot - This [fast-reboot](https://github.com/Azure/SONiC/wiki/Fast-Reboot) support aims to help image-udpate and restart, with minimal data-plane traffic disruption. The implementation is similar to warm-reboot, that logic is embedded in the fast-boot script, additional utilities and some tweaks inside the code/logic of individual services that supports. Here again any service level support lies within the internal code/logic. + This [fast-reboot](https://github.com/sonic-net/SONiC/wiki/Fast-Reboot) support aims to help image-udpate and restart, with minimal data-plane traffic disruption. The implementation is similar to warm-reboot, that logic is embedded in the fast-boot script, additional utilities and some tweaks inside the code/logic of individual services that supports. Here again any service level support lies within the internal code/logic. In short, the summary and the required changes, including hooks for new features, are the same as in warm-reboot support, just that here use fast-reboot script. diff --git a/doc/lag/LACP Fallback Feature for SONiC_v0.5.md b/doc/lag/LACP Fallback Feature for SONiC_v0.5.md index 1eab42c948..995f69bd22 100644 --- a/doc/lag/LACP Fallback Feature for SONiC_v0.5.md +++ b/doc/lag/LACP Fallback Feature for SONiC_v0.5.md @@ -17,7 +17,7 @@ problem because packets sourced from the MAC address of NIC-1 can be returned to the port on which NIC-2 is attached, which will cause NIC-2 to drop the packets (due to MAC mismatch). -![lag.png](https://github.com/Azure/SONiC/blob/gh-pages/images/lacp_fallback_hld/lag.png) +![lag.png](https://github.com/sonic-net/SONiC/blob/gh-pages/images/lacp_fallback_hld/lag.png) With the LACP fallback feature, the switch allows the server to bring up the LAG (before receiving any LACP PDUs from the server) and keeps a single port @@ -70,7 +70,7 @@ Rxm\_expired states with two timeout: Short timeout (3s) and Long timeout (180s) depending on the value of the Actor's Operational Status LACP\_Timeout, as transmitted in LACPDUs. -![Current_LACP_State_Machine.png](https://github.com/Azure/SONiC/blob/gh-pages/images/lacp_fallback_hld/Current_LACP_State_Machine.png) +![Current_LACP_State_Machine.png](https://github.com/sonic-net/SONiC/blob/gh-pages/images/lacp_fallback_hld/Current_LACP_State_Machine.png) ## Receive Machine Events The following events can occur: @@ -86,7 +86,7 @@ have become non-operational. The received LACPDU event only occurs if both physical transmission and reception are operational, so far as the actor is aware. -![rxm.png](https://github.com/Azure/SONiC/blob/gh-pages/images/lacp_fallback_hld/rxm.png) +![rxm.png](https://github.com/sonic-net/SONiC/blob/gh-pages/images/lacp_fallback_hld/rxm.png) # LACP Fallback Design @@ -99,7 +99,7 @@ In order to support LACP fallback feature, we need to make the port selectable in defaulted state if fallback is enabled. Hence we'd like to introduce the fallback mode in defaulted state. -![LACP_Defaulted.png](https://github.com/Azure/SONiC/blob/gh-pages/images/lacp_fallback_hld/LACP_Defaulted.png) +![LACP_Defaulted.png](https://github.com/sonic-net/SONiC/blob/gh-pages/images/lacp_fallback_hld/LACP_Defaulted.png) - Fallback Mode: diff --git a/doc/lag/LACP Fallback Test Plan.md b/doc/lag/LACP Fallback Test Plan.md index a9f7e309ec..81052a0e82 100644 --- a/doc/lag/LACP Fallback Test Plan.md +++ b/doc/lag/LACP Fallback Test Plan.md @@ -15,7 +15,7 @@ **Related documents** -[LACP Fallback Design Document](https://github.com/Azure/SONiC/blob/gh-pages/doc/LACP%20Fallback%20Feature%20for%20SONiC_v0.3.docx) +[LACP Fallback Design Document](https://github.com/sonic-net/SONiC/blob/gh-pages/doc/lag/LACP%20Fallback%20Feature%20for%20SONiC_v0.5.md) # Overview This feature test suite is targeting on testing LACP fallback feature on SONiC. In our testbed, 't0' and 't1-lag' have LAG configurations. Each test covers a basic functionality of LACP fallback feature and ensures the switch works as expected under production scenarios. @@ -41,8 +41,8 @@ sai_remove_lag_member DUT configuration is done via minigraph. See more information below # Setup configuration -![LACP_fallback_testbed.png](https://github.com/Azure/SONiC/blob/gh-pages/images/LACP_fallback_testbed.png) -https://github.com/Azure/SONiC/blob/gh-pages/images/LACP_fallback_testbed.png +![LACP_fallback_testbed.png](https://github.com/sonic-net/SONiC/blob/gh-pages/images/LACP_fallback_testbed.png) +https://github.com/sonic-net/SONiC/blob/gh-pages/images/LACP_fallback_testbed.png * 8 LAGs per switch from the DUT to 8 vEOS devices. * Each of the LAG contains 2 members. @@ -57,7 +57,7 @@ https://github.com/Azure/SONiC/blob/gh-pages/images/LACP_fallback_testbed.png sonic-mgmt uses minigraph files to described VM set (Arista vEOS devices) and the DUT switch. We will need to create a new minigraph file, describing VMs and the switch, with LAGs. -The switch file will be named switch-lacp-fallback.yml, and located at [https://github.com/Azure/sonic-mgmt/blob/master/ansible/minigraph](https://github.com/Azure/sonic-mgmt/blob/master/ansible/minigraph). +The switch file will be named switch-lacp-fallback.yml, and located at [https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/minigraph](https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/minigraph). ### LAG related minigraph data @@ -82,7 +82,7 @@ Sample: ``` -This information will be consumed by teamd.j2 template introduced in [LAG testbed Pull Reqeust](https://github.com/Azure/sonic-mgmt/pull/69) (see port_channel variable) to produce LAG json configuration for teamd. +This information will be consumed by teamd.j2 template introduced in [LAG testbed Pull Reqeust](https://github.com/sonic-net/sonic-mgmt/pull/69) (see port_channel variable) to produce LAG json configuration for teamd. see [Setup of DUT switch](#setup-of-dut-switch) for details on teamd json. ### LAG route information file diff --git a/doc/macsec/MACsec_hld.md b/doc/macsec/MACsec_hld.md index 11d00af5d9..8b06bfa9a1 100644 --- a/doc/macsec/MACsec_hld.md +++ b/doc/macsec/MACsec_hld.md @@ -102,8 +102,8 @@ At a high level the following should be supported: #### Phase I -- MACsec can be enabled at a specified [port](https://github.com/Azure/SONiC/wiki/Configuration#port) -- MACsec can co-work with the [port channel](https://github.com/Azure/SONiC/wiki/Configuration#port-channel) +- MACsec can be enabled at a specified [port](https://github.com/sonic-net/SONiC/wiki/Configuration#port) +- MACsec can co-work with the [port channel](https://github.com/sonic-net/SONiC/wiki/Configuration#port-channel) - Support Cipher: GCM-AES-128 and GCM-AES-256 - Secure Association Key(SAK) can be replaced without service outage diff --git a/doc/mclag/MCLAG_Enhancements_HLD.md b/doc/mclag/MCLAG_Enhancements_HLD.md index 7530fadeae..ded353c352 100644 --- a/doc/mclag/MCLAG_Enhancements_HLD.md +++ b/doc/mclag/MCLAG_Enhancements_HLD.md @@ -105,7 +105,7 @@ Rev 0.1 | 0.2 | 10/22/2019 | Tapash Das | L3 Protocol support enhancement | # About this Manual -This document provides general information about SONiC MCLAG feature enhancements. The original MCLAG feature is described at https://github.com/Azure/SONiC/blob/f478fe7cbc03c144f3b147e9638f460f764ce4b7/doc/Sonic-mclag-hld.md +This document provides general information about SONiC MCLAG feature enhancements. The original MCLAG feature is described at https://github.com/sonic-net/SONiC/blob/f478fe7cbc03c144f3b147e9638f460f764ce4b7/doc/Sonic-mclag-hld.md # Definition/Abbreviation diff --git a/doc/mclag/Sonic-mclag-hld.md b/doc/mclag/Sonic-mclag-hld.md index 37047bdf3a..dcfaebb473 100644 --- a/doc/mclag/Sonic-mclag-hld.md +++ b/doc/mclag/Sonic-mclag-hld.md @@ -430,7 +430,7 @@ Flow 8: After configure/update APP_DB, OrchAgent monitors and procesess the rela Jason definition is exactly the same as acl_table and acl_rule_table in config-db. MCLAG uses acl to isolate peer-link from mclag-enabled port-channel. so We add acl_table and acl_rule_table in app-db. Other apps which need to configure acl dynamically can reuse this mechanism. -The acl hld has defined app_acl_table and app_acl_rule_table but did not implement it. Please refer [acl_hld](https://github.com/Azure/SONiC/blob/master/doc/acl/ACL-High-Level-Design.md#31211-acl-tables-table) for detail. +The acl hld has defined app_acl_table and app_acl_rule_table but did not implement it. Please refer [acl_hld](https://github.com/sonic-net/SONiC/blob/master/doc/acl/ACL-High-Level-Design.md#31211-acl-tables-table) for detail. ```jason "ACL_TABLE": { @@ -582,7 +582,7 @@ Config loglevel success! ## 9.4. aclorch changes -Adding the following logic:([PR#810](https://github.com/Azure/sonic-swss/pull/810)) +Adding the following logic:([PR#810](https://github.com/sonic-net/sonic-swss/pull/810)) - ACL table can be matched with OUT_PORTS. - Aclorch as the consumer to monitor the events of APP_ACL_TABLE_NAME and APP_ACL_RULE_TABLE_NAME tables in APP_DB . The definition of APP_ACL_TABLE_NAME and APP_ACL_RULE_TABLE_NAME are in sonic-swss-common/common/schema.h. @@ -598,8 +598,8 @@ Adding the following logics: Adding the following logics: -- Listening new APP_DB events, enable or disable to learn interface MACs. If ‘learn_mode’ attribute of one port is set to ‘disabled’, the MAC learning of this port is disbled.([PR#809](https://github.com/Azure/sonic-swss/pull/809)) -- Add LAG name map to counter table, so that ‘show mac’ can display the MACs learned from LAG ports. ([PR#808](https://github.com/Azure/sonic-swss/pull/808)) +- Listening new APP_DB events, enable or disable to learn interface MACs. If ‘learn_mode’ attribute of one port is set to ‘disabled’, the MAC learning of this port is disbled.([PR#809](https://github.com/sonic-net/sonic-swss/pull/809)) +- Add LAG name map to counter table, so that ‘show mac’ can display the MACs learned from LAG ports. ([PR#808](https://github.com/sonic-net/sonic-swss/pull/808)) ## 9.7. intfmgr changes @@ -611,14 +611,14 @@ Adding the following logics: Adding the following logics: -- Listening MAC modification of L3 interfaces, updating it to ASIC.([PR#814](https://github.com/Azure/sonic-swss/pull/814)) -- Removing the function of adding/delete direct connected network FIB update triggered by creation of L3 interface in orchAgent. (Such direct connected network FIB does not respond to the state change, which is wrong, it only responds to the ip address addition or deletion）[PR#878](https://github.com/Azure/sonic-swss/pull/878)) +- Listening MAC modification of L3 interfaces, updating it to ASIC.([PR#814](https://github.com/sonic-net/sonic-swss/pull/814)) +- Removing the function of adding/delete direct connected network FIB update triggered by creation of L3 interface in orchAgent. (Such direct connected network FIB does not respond to the state change, which is wrong, it only responds to the ip address addition or deletion）[PR#878](https://github.com/sonic-net/sonic-swss/pull/878)) ## 9.9. routeorch changes Adding the following logics: -- For the creation of the directly connected network, the code is moved from intfsorch to routeorch. Like other types of route, the direct connect network is informed by Zebra. This is to fix a common issue, not only for MC-LAG support.([PR#878](https://github.com/Azure/sonic-swss/pull/878)) +- For the creation of the directly connected network, the code is moved from intfsorch to routeorch. Like other types of route, the direct connect network is informed by Zebra. This is to fix a common issue, not only for MC-LAG support.([PR#878](https://github.com/sonic-net/sonic-swss/pull/878)) ## 9.10. fdborch changes @@ -626,7 +626,7 @@ Adding the following logics: - If the FDB entry is already exist when the event is ADD, remove the entry first, then add the entry. - FDB MAC can be learnt from or set to VXLAN tunnel in ASIC. -([PR#877](https://github.com/Azure/sonic-swss/pull/877)) +([PR#877](https://github.com/sonic-net/sonic-swss/pull/877)) ## 9.11. vxlanmgr changes diff --git a/doc/mgmt/Management Framework.md b/doc/mgmt/Management Framework.md index 4fe6f88830..b7728bbcd2 100644 --- a/doc/mgmt/Management Framework.md +++ b/doc/mgmt/Management Framework.md @@ -172,7 +172,7 @@ Management framework is a SONiC application which is responsible for providing v * Must provide support for: 1. Standard [YANG](https://tools.ietf.org/html/rfc7950) models (e.g. OpenConfig, IETF, IEEE) - 2. Custom YANG models ([SONiC YANG](https://github.com/Azure/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md)) + 2. Custom YANG models ([SONiC YANG](https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md)) 3. Industry-standard CLI / Cisco like CLI * Must provide support for [OpenAPI spec](http://spec.openapis.org/oas/v3.0.3) to generate REST server side code @@ -1843,19 +1843,19 @@ module openconfig-acl-annot { ##### 3.2.2.8 Config Validation Library (CVL) -Config Validation Library (CVL) is an independent library to validate ABNF schema based SONiC (Redis) configuration. This library can be used by component like [Cfg-gen](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/sonic-cfggen), Translib, [ZTP](https://github.com/Azure/SONiC/blob/master/doc/ztp/ztp.md) etc. to validate SONiC configuration data before it is written to Redis DB. Ideally, any component importing config_db.json file into Redis DB can invoke CVL API to validate the configuration. +Config Validation Library (CVL) is an independent library to validate ABNF schema based SONiC (Redis) configuration. This library can be used by component like [Cfg-gen](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-config-engine/sonic-cfggen), Translib, [ZTP](https://github.com/sonic-net/SONiC/blob/master/doc/ztp/ztp.md) etc. to validate SONiC configuration data before it is written to Redis DB. Ideally, any component importing config_db.json file into Redis DB can invoke CVL API to validate the configuration. CVL uses SONiC YANG models written based on ABNF schema along with various constraints. These native YANG models are simple and have a very close mapping to the associated ABNF schema. Custom YANG extensions (annotations) are used for custom validation purpose. Specific YANG extensions (rather metadata) are used to translate ABNF data to YANG data. In the context of CVL these YANG models are called CVL YANG models and generated from SONiC YANG during build time. Opensource [libyang](https://github.com/CESNET/libyang) library is used to perform YANG data validation. SONiC YANG can be used as Northbound YANG for management interface by adding other data definitions such as state data (read only data), RPC or Notification as needed.Such YANG models are called SONiC NBI YANG models. Since CVL validates configuration data only, these data definition statements are ignored by CVL. During build time CVL YANG is actually generated from SONiC NBI YANG models with the help of CVL specific pyang plugin. -CVL supports multiple user-defined Redis database instances based on the [Multi DB instance HLD](https://github.com/Azure/SONiC/blob/master/doc/database/multi_database_instances.md) specification. During CVL initialization time, the DB configuration file is read from the predefined location and details are stored in internal data structure. CVL implements internal API for connecting to a Redis DB instance using the details stored in its internal data structure. +CVL supports multiple user-defined Redis database instances based on the [Multi DB instance HLD](https://github.com/sonic-net/SONiC/blob/master/doc/database/multi_database_instances.md) specification. During CVL initialization time, the DB configuration file is read from the predefined location and details are stored in internal data structure. CVL implements internal API for connecting to a Redis DB instance using the details stored in its internal data structure. ###### 3.2.2.8.1 Architecture ![CVL architecture](images/CVL_Arch.jpg) -1. During build time, developer writes SONiC YANG schema based on ABNF schema following [SONiC YANG Guidelines](https://github.com/Azure/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md) and adds metadata and constraints as needed. Custom YANG extensions are defined for this purpose. +1. During build time, developer writes SONiC YANG schema based on ABNF schema following [SONiC YANG Guidelines](https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md) and adds metadata and constraints as needed. Custom YANG extensions are defined for this purpose. 2. The YANG models are compiled using Pyang compiler. CVL specific YIN schema files are derived from SONiC YANG with the help of CVL specific pyang plugin. Finally, generated YIN files are packaged in the build. 3. During boot up/initialization sequence, YIN schemas generated from SONiC YANG models are parsed and schema tree is build using libyang API. 4. Application calls CVL APIs to validate the configuration. In case of Translib library DB Access layer calls appropriate CVL APIs to validate the configuration. @@ -2219,7 +2219,7 @@ Redis schema needs to be expressed in SONiC proprietary YANG model with all data Custom validation code needs to be written if some of the constraints cannot be expressed in YANG syntax. -Please refer to [SONiC YANG Guidelines](https://github.com/Azure/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md) for detiailed guidelines on writing SONiC YANG. +Please refer to [SONiC YANG Guidelines](https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md) for detiailed guidelines on writing SONiC YANG. #### 5.1.2 Generation of REST server stubs and Client SDKs for YANG based APIs @@ -2284,7 +2284,7 @@ Redis schema needs to be expressed in SONiC YANG model with all data types and c Custom validation code needs to be written if some of the constraints cannot be expressed in YANG syntax. -Please refer to [SONiC YANG Guidelines](https://github.com/Azure/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md) for detiailed guidelines on writing SONiC YANG. +Please refer to [SONiC YANG Guidelines](https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md) for detiailed guidelines on writing SONiC YANG. #### 5.2.4 Generation of REST server stubs and Client SDKs for YANG based APIs @@ -2552,7 +2552,7 @@ Following are the list of Open source tools used in Management framework ## 12 Appendix B Following are the list of Open source libraries used in telemetry container. -Always refer to the [Makefile](https://github.com/Azure/sonic-telemetry/blob/master/Makefile) for the sonic-telemetry container for current package list. +Always refer to the [Makefile](https://github.com/sonic-net/sonic-gnmi/blob/master/Makefile) for the sonic-gnmi container for current package list. 1. [GRPC](https://google.golang.org/grpc) diff --git a/doc/mgmt/SONiC Management Framework Show Techsupport HLD.md b/doc/mgmt/SONiC Management Framework Show Techsupport HLD.md index f2b3061ddf..2a375a1122 100644 --- a/doc/mgmt/SONiC Management Framework Show Techsupport HLD.md +++ b/doc/mgmt/SONiC Management Framework Show Techsupport HLD.md @@ -79,7 +79,7 @@ Provide Management Framework functionality to process the "show techsupport" com NOTE: The underlying feature for which this Management Framework feature provides "front end" client interfaces is unchanged by the addition of these interfaces. (The "since " option available through these interfaces, however, is restricted to the IETF/YANG date/time format.) Please refer to the following document for a description of the "show techsupport" base feature: -https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md#troubleshooting-commands +https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md#troubleshooting-commands DEPENDENCY ON SONIC-HOSTSERVICES: diff --git a/doc/mgmt/SONiC_YANG_Model_Guidelines.md b/doc/mgmt/SONiC_YANG_Model_Guidelines.md index 8f7057ec0f..a2d7127dad 100644 --- a/doc/mgmt/SONiC_YANG_Model_Guidelines.md +++ b/doc/mgmt/SONiC_YANG_Model_Guidelines.md @@ -13,7 +13,7 @@ | References | Date/Version | Link | |:-------------------------:|:-------------------:|:-----------------------------------:| | RFC 7950 | August 2016 | https://tools.ietf.org/html/rfc7950 | -| Management Framework | 0.9 | https://github.com/Azure/SONiC/pull/436 | +| Management Framework | 0.9 | https://github.com/sonic-net/SONiC/pull/436 | ## Terminology and Acronyms | Acronyms | Description/Expansion | @@ -24,9 +24,9 @@ ## Overview - This document lists the guidelines, which will be used to write YANG Modules for SONiC. These YANG Modules (called SONiC YANG models) will be primarily based on or represent the ABNF.json of SONiC, and the syntax of YANG models must follow RFC 7950 ([https://tools.ietf.org/html/rfc7950](https://tools.ietf.org/html/rfc7950)). Details of config in format of ABNF.json can be found at https://github.com/Azure/SONiC/wiki/Configuration. + This document lists the guidelines, which will be used to write YANG Modules for SONiC. These YANG Modules (called SONiC YANG models) will be primarily based on or represent the ABNF.json of SONiC, and the syntax of YANG models must follow RFC 7950 ([https://tools.ietf.org/html/rfc7950](https://tools.ietf.org/html/rfc7950)). Details of config in format of ABNF.json can be found at https://github.com/sonic-net/SONiC/wiki/Configuration. -These YANG models will be used to verify the configuration for SONiC switches, so a library which supports validation of configuration on SONiC Switch must use these YANG Models. List of such Libraries are: 1.) Configuration Validation Library. (CVL). YANG models, which are written using these guidelines can also be used as User End YANG Models, i.e North Bound configuration tools or CLI can provide config data in sync with these YANG models. For example [SONiC Management Framework](https://github.com/Azure/SONiC/pull/436) uses SONiC YANG models as Northbound Management YANG and for configuration validation purpose also. +These YANG models will be used to verify the configuration for SONiC switches, so a library which supports validation of configuration on SONiC Switch must use these YANG Models. List of such Libraries are: 1.) Configuration Validation Library. (CVL). YANG models, which are written using these guidelines can also be used as User End YANG Models, i.e North Bound configuration tools or CLI can provide config data in sync with these YANG models. For example [SONiC Management Framework](https://github.com/sonic-net/SONiC/pull/436) uses SONiC YANG models as Northbound Management YANG and for configuration validation purpose also. ## Guidelines diff --git a/doc/mgmt/sonic_stretch_management_vrf_design.md b/doc/mgmt/sonic_stretch_management_vrf_design.md index 811f6bca6a..31c0834fad 100644 --- a/doc/mgmt/sonic_stretch_management_vrf_design.md +++ b/doc/mgmt/sonic_stretch_management_vrf_design.md @@ -172,7 +172,7 @@ iface eth0 inet static If a default route was already present in management VRF, it is added to the "default" routing table which is part of default VRF. This is done when the eth0 interface comes up. When networking service is restarted, it will first bring down all existing interfaces. As part of "lo" down, previously created interface "lo-m" that was used as part of management VRF will be deleted. -These management VRF changes are implemented in the pull request [PR2585](https://github.com/Azure/sonic-buildimage/pull/2585) +These management VRF changes are implemented in the pull request [PR2585](https://github.com/sonic-net/sonic-buildimage/pull/2585) #### Config Commands @@ -236,7 +236,7 @@ Management NetWork Default Gateway = 10.16.210.254 root@sonic:/etc/init.d# ``` -These CLI commands are implemented as part of the pull request [PR463](https://github.com/Azure/sonic-utilities/pull/463) +These CLI commands are implemented as part of the pull request [PR463](https://github.com/sonic-net/sonic-utilities/pull/463) ### IP Application Design This section explains the behavior of each application on the default VRF and management VRF. Application functionality differs based on whether the application is used to connect to the application daemons running in the device or the application is triggered from the device. @@ -291,7 +291,7 @@ cgexec -g l3mdev:mgmt ssh 10.1.2.3 ##### TACACS TACACS is a library function that is used by applications like SSHD to authenticate the users. When users connect to the device using SSH and if the "aaa" authentication is configured to use the tacacs+, it is expected that device shall connect to the tacacs+ server via management port and authenticate the user. TACACS implementation contains two sub-modules, viz, NSS and PAM. These module codes is enhanced to support an additional parameter "--use-mgmt-vrf" while configuring the tacacs+ server IP address. When user specifies the --use-mgmt-vrf as part of "config tacacs add --use-mgmt-vrf " command, this is passed as an additional parameter to the config_db's TACPLUS_SERVER tag. This additional parameter is read using the files/image_config/hostcfgd/common-auth-sonic.j2 & files/image_config/hostcfgd/tacplus_nss.conf.j2 and the information is added to the tacplus configuration files /etc/tacplus_nss.conf and /etc/pam.d/common-auth-sonic. When SSHD uses the tacacs+ authentication using the API "pam_authenticate", enhanced tacacs+ code shall read the additional configuration related to vrfname "mgmt" associated with the tacac+ server and then it uses SO_BINDTODEVICE to attach the socket to the "mgmt" interface. Once if the socket is attached to "mgmt" interface, all tacacs+ traffic shall be routed via the management interface. -Code changes required in PAM & NSS are completed. [PR2217](https://github.com/Azure/sonic-buildimage/pull/2217) & [PR346](https://github.com/Azure/sonic-utilities/pull/346) address the same. +Code changes required in PAM & NSS are completed. [PR2217](https://github.com/sonic-net/sonic-buildimage/pull/2217) & [PR346](https://github.com/sonic-net/sonic-utilities/pull/346) address the same. As explained in the PR, tacacs PAM & NSS module had been enhanced to parse and process the "vrfname" and to setsockopt using SO_BINDTODEVICE for "mgmt" interface. Added an optional parameter "-m" (or --use-mgmt-vrf) for the "tacacs" command. The optional parameter "-m" used while configuring tacacs server results in configuring the DB with vrfname as "mgmt". Files "files/image_config/hostcfgd/common-auth-sonic.j2" and "files/image_config/hostcfgd/tacplus_nss_conf.j2" are modified to read this optional parameter and update the PAM & NSS configuration files "/etc/pam.d/common-auth" and "/etc/tacplus_nss.conf" respectively with the vrfname. After enhancing the code for NSS in the file nss_tacplus.c for parsing the vrfname and passing it to the connect library function "tac_connect_single", git patch "0003-management-vrf-support.patch" was generated and checked in. @@ -324,7 +324,7 @@ TACPLUS_SERVER address 10.11.55.41 2. cURL from device: Works for default VRF as usual. For cURL via management interface, use "cgexec -g l3mdev:mgmt" as prefix. #### SNMP -1. snmp to the device: SNMP being an UDP application, Linux netsmp 5.7.3 patch for VRF support is patched with SONiC sources. [PR2608](https://github.com/Azure/sonic-buildimage/pull/2608) and [PR472](https://github.com/Azure/sonic-utilities/pull/472) contains the changes done for SNMP. +1. snmp to the device: SNMP being an UDP application, Linux netsmp 5.7.3 patch for VRF support is patched with SONiC sources. [PR2608](https://github.com/sonic-net/sonic-buildimage/pull/2608) and [PR472](https://github.com/sonic-net/sonic-utilities/pull/472) contains the changes done for SNMP. 2. snmp traps from device: netsnmp 5.7.3 Linux patch has VRF support for traps. Conifuguration file needs to specify VRF name. Above mentioned PRs handle the required changes. #### NTP @@ -342,9 +342,9 @@ Since this file "/etc/init.d/ntp" is part of the default NTP package from debian In addtion to this change, NTP has got linux commands like "ntpq" which communicates with "ntpd" using the loopback IP address 127.0.0.1. Hence, a dummy interface "lo-m" is created and enslaved into "mgmt" and configured with the IP address 127.0.0.1 -These NTP changes are done as part of the pull request [PR3204](https://github.com/Azure/sonic-buildimage/pull/3204) +These NTP changes are done as part of the pull request [PR3204](https://github.com/sonic-net/sonic-buildimage/pull/3204) -Similarly, the "show ntp" command is also enhanced to use "cgexec -g l3mdev:mgmt" as explained in the [PR627](https://github.com/Azure/sonic-utilities/pull/627) +Similarly, the "show ntp" command is also enhanced to use "cgexec -g l3mdev:mgmt" as explained in the [PR627](https://github.com/sonic-net/sonic-utilities/pull/627) #### DHCP Client DHCP client gets the IP address for the management ports from the DHCP server, since it is enabled on a per interface the IP address is received automatically. @@ -352,7 +352,7 @@ DHCP Client had already been enhanced to execute a "vrf" script as part of exit- This script does "no-op" when management VRF is not enabled (i.e. when eth0 is not in management vrf). With the script, eth0 is placed in a vrf and on startup it will get an IP address via dhcp. IP address changes or gateway changes are correctly reflected. -[PR2348](https://github.com/Azure/sonic-buildimage/pull/2348) handles these changes. +[PR2348](https://github.com/sonic-net/sonic-buildimage/pull/2348) handles these changes. #### DHCP Relay DHCP relay is expected to work via the default VRF. diff --git a/doc/multi_asic/SONiC_multi_asic_hld.md b/doc/multi_asic/SONiC_multi_asic_hld.md index 56b4ca6770..7587c57620 100644 --- a/doc/multi_asic/SONiC_multi_asic_hld.md +++ b/doc/multi_asic/SONiC_multi_asic_hld.md @@ -228,7 +228,7 @@ For multi asic platform, the bgp, lldp, teamd, swss, syncd and database dockers Systemd allows starting of multiple instances of a systemd service using service template. If foo@.service is a template service, we can start N number of foo service by starting foo@0.service, foo@1.service etc. The instance number is passed to service template itself as a parameter %i which is used to identify the instance number that is being passed. -Example: `https://github.com/Azure/sonic-buildimage/blob/master/files/build_templates/per_namespace/teamd.service.j2 ` +Example: `https://github.com/sonic-net/sonic-buildimage/blob/master/files/build_templates/per_namespace/teamd.service.j2 ` Each service file uses a start up script to start/stop corresponding docker. This script is updated to use the instance number. The changes are done so that the number of asics do not need to be defined during build-time and is identified during run-time. Systemd-generator binary runs during boot-up, before systemd runs and identifies the number of asics by reading /usr/share/sonic/device//asic.conf file. @@ -453,7 +453,7 @@ A new template file database_global.json.j2 is introduced which is used to gener #### 2.4.4.1. Infrastructure changes The dbconnector classes present in the sonic-py-swsssdk submodule viz. SoncV2Connector, ConfigDBConnector is enhanced to accept the namespace parameter to connect to the DB in a particular namesapce. The dbconnector in the sonic-swsscommon submodule viz DBConnector too will be enhanced to accept the namespace parameter. -Please refer [multi namespace db instance implementation document](https://github.com/Azure/SONiC/blob/master/doc/database/multi_namespace_db_instances.md) for more details. +Please refer [multi namespace db instance implementation document](https://github.com/sonic-net/SONiC/blob/master/doc/database/multi_namespace_db_instances.md) for more details. ### 2.4.5. Configuration CLIs diff --git a/doc/nat/nat_design_spec.md b/doc/nat/nat_design_spec.md index b012659ab3..fa53b76bdd 100644 --- a/doc/nat/nat_design_spec.md +++ b/doc/nat/nat_design_spec.md @@ -450,7 +450,7 @@ key = LOOPBACK_INTERFACE:loopback-name NAT_ZONE = 1*1DIGIT ; a number in the range 0-3 ``` -Please refer to the [schema](https://github.com/Azure/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. +Please refer to the [schema](https://github.com/sonic-net/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. ### 3.2.3 APP DB New tables are introduced to specify NAT translation entries. diff --git a/doc/nvgre_tunnel/nvgre_tunnel.md b/doc/nvgre_tunnel/nvgre_tunnel.md index 3bcabdc947..390845b88a 100755 --- a/doc/nvgre_tunnel/nvgre_tunnel.md +++ b/doc/nvgre_tunnel/nvgre_tunnel.md @@ -56,7 +56,7 @@ At a high level the following should be supported: - User should be able to create VLAN to VSID mapper entries for the NVGRE tunnel - Both VLAN and Bridge to VSID mappers should be supported by the NVGRE tunnel - Only the decapsulation mappers supported -- YANG model should be created in order to auto-generate CLI by using the [SONiC CLI Auto-generation tool](https://github.com/Azure/SONiC/blob/master/doc/cli_auto_generation/cli_auto_generation.md). +- YANG model should be created in order to auto-generate CLI by using the [SONiC CLI Auto-generation tool](https://github.com/sonic-net/SONiC/blob/master/doc/cli_auto_generation/cli_auto_generation.md). - CLI for NVGRE tunnel Counters for NVGRE Tunnel are out of scope of this design document. @@ -132,9 +132,9 @@ The following orchestration agents will be added or modified. The flow diagrams ### High-Level Design The following sub-modules will be modified: -* [sonic-swss](https://github.com/Azure/sonic-swss) - will be extended with the new orchestration agent for NVGRE. -* [sonic-swss-common](https://github.com/Azure/sonic-swss-common) - will be extended with the new tables for ConfigDB. -* [sonic-utilities](https://github.com/Azure/sonic-utilities) - will be extened with the new CLI. +* [sonic-swss](https://github.com/sonic-net/sonic-swss) - will be extended with the new orchestration agent for NVGRE. +* [sonic-swss-common](https://github.com/sonic-net/sonic-swss-common) - will be extended with the new tables for ConfigDB. +* [sonic-utilities](https://github.com/sonic-net/sonic-utilities) - will be extened with the new CLI. #### Sequence diagrams @@ -417,7 +417,7 @@ The number of the tunnels are not limited by SONiC, but if ASIC vendor reach the ### Testing Requirements/Design -The tests will be implemented under the VS environment and will be placed - [sonic-swss/tests](https://github.com/Azure/sonic-swss/tree/master/tests) sub-module. +The tests will be implemented under the VS environment and will be placed - [sonic-swss/tests](https://github.com/sonic-net/sonic-swss/tree/master/tests) sub-module. #### Unit Test cases diff --git a/doc/pbh/pbh-design.md b/doc/pbh/pbh-design.md index 548de5c744..47ec2df3cd 100644 --- a/doc/pbh/pbh-design.md +++ b/doc/pbh/pbh-design.md @@ -1217,4 +1217,4 @@ PBH extended configuration test: ## 3.2 Data plane tests via PTF PBH will reuse and extend the existing test plan: -[Inner packet hashing test plan #759](https://github.com/Azure/SONiC/pull/759) +[Inner packet hashing test plan #759](https://github.com/sonic-net/SONiC/pull/759) diff --git a/doc/pcie-mon/pcie-monitoring-services-hld.md b/doc/pcie-mon/pcie-monitoring-services-hld.md index bb3dd62fb9..7ad736c435 100644 --- a/doc/pcie-mon/pcie-monitoring-services-hld.md +++ b/doc/pcie-mon/pcie-monitoring-services-hld.md @@ -40,7 +40,7 @@ For the convenience of implementation and reduce the time consuming, pcie-check. 2. `PcieUtil` will provide APIs `load_config_file`, `get_pcie_device` and `get_pcie_check` to get the expected PCIe device list and informations, to get the current PCIe device information, and check if any PCIe device is missing or if there is any PCIe bus error. -![pcieinfo_design](https://github.com/Azure/SONiC/blob/master/doc/pcieinfo_design.md) +![pcieinfo_design](https://github.com/sonic-net/SONiC/blob/master/doc/pcieinfo_design.md) ### 1.2 PCIe device configuration file ### @@ -96,7 +96,7 @@ PcieUtil calls this API to check the PCIe device status, following example code pcie-check.service will be started by systemd during boot up and it will spawn a thread to check PCIe device status and perform the rescan pci devices if there is any missing devices after rc.local.service is completed and it will update the state db with pcie device satus after the `pcieutil pcie-chek` call so that the dependent services/container or kernel driver can be started or stopped based on the status. Detailed flow as showed in below chart: -![](https://github.com/Azure/SONiC/blob/70a152f1b98e145c9f0771e7cda7a951d98a978e/images/pcie-check.svg) +![](https://github.com/sonic-net/SONiC/blob/70a152f1b98e145c9f0771e7cda7a951d98a978e/images/pcie-check.svg) ### 1.5 PCIe daemon `pcied` flow ### @@ -104,7 +104,7 @@ Detailed flow as showed in below chart: pcied will be started by PMON container will continue monitoring the PCIe device status during run time and it will check the PCIe device status periodically every 1 minute and update the state db when the status is checked. Detailed flow as showed in below chart: -![](https://github.com/Azure/SONiC/blob/70a152f1b98e145c9f0771e7cda7a951d98a978e/images/pcied.svg) +![](https://github.com/sonic-net/SONiC/blob/70a152f1b98e145c9f0771e7cda7a951d98a978e/images/pcied.svg) ### 1.6 STATE_DB keys and value ### diff --git a/doc/pfc_asym/PFC_Asymmetric_Test_HLD.md b/doc/pfc_asym/PFC_Asymmetric_Test_HLD.md index 01922c48dc..7cd2a02456 100644 --- a/doc/pfc_asym/PFC_Asymmetric_Test_HLD.md +++ b/doc/pfc_asym/PFC_Asymmetric_Test_HLD.md @@ -22,7 +22,7 @@ The purpose is to test functionality of Asymmetric PFC on the SONIC based DUT, closely resembling production environment. ### Scope -The test is targeting a running SONIC system with fully functioning configuration. The purpose of the test is to perform functional testing of Asymmetric PFC on SONIC system. There will be reused existed PTF test suite for PFC Asymmetric which is located at https://github.com/Azure/sonic-mgmt/blob/master/ansible/roles/test/files/saitests/pfc_asym.py. +The test is targeting a running SONIC system with fully functioning configuration. The purpose of the test is to perform functional testing of Asymmetric PFC on SONIC system. There will be reused existed PTF test suite for PFC Asymmetric which is located at https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/roles/test/files/saitests/pfc_asym.py. ### Testbed The test will run on the following testbeds: @@ -39,20 +39,20 @@ There is already existed PFC asymmetric test cases which use PTF to send traffic Test suite location -https://github.com/Azure/sonic-mgmt/blob/master/ansible/roles/test/files/saitests/pfc_asym.py +https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/roles/test/files/saitests/pfc_asym.py It requires several updates: 1. Packets sending speed can be increased by using multiprocessing instead of multithreading library. -https://github.com/Azure/sonic-mgmt/blob/master/ansible/roles/test/files/saitests/pfc_asym.py#L83 +https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/roles/test/files/saitests/pfc_asym.py#L83 Replace ```threading.Thread``` to use ```multiprocessing.Process``` instead. 2. Looks like there is a redundancy in generating configuration file for ARP responder. -https://github.com/Azure/sonic-mgmt/blob/master/ansible/roles/test/files/saitests/pfc_asym.py#L56 +https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/roles/test/files/saitests/pfc_asym.py#L56 Fix the loop to store file only once diff --git a/doc/pins/Packet_io.md b/doc/pins/Packet_io.md index cfd22220de..52707bd10d 100644 --- a/doc/pins/Packet_io.md +++ b/doc/pins/Packet_io.md @@ -156,7 +156,7 @@ The netdev port attributes are specified as below in the [copp_cfg.j2](https://g ``` -[Copporch.cpp](https://github.com/Azure/sonic-swss/blob/fb06c32b2e25e6057514e9455e997ff7edcb7340/orchagent/copporch.cpp) will parse the above fields and add the netdev port attributes for the CPU port and invoke the SAI hostif create API to create the netdev port for the new submit_to_ingress interface. +[Copporch.cpp](https://github.com/sonic-net/sonic-swss/blob/fb06c32b2e25e6057514e9455e997ff7edcb7340/orchagent/copporch.cpp) will parse the above fields and add the netdev port attributes for the CPU port and invoke the SAI hostif create API to create the netdev port for the new submit_to_ingress interface. P4Runtime will create a socket for the “submit_to_ingress” netdev port and write into this socket for packets marked to send to “submit_to_ingress”. Packets egressing out of the socket end up as incoming packets on the CPU port of the switch. The packets now follow the regular switch pipeline to get forwarded out. diff --git a/doc/pins/pins_hld.md b/doc/pins/pins_hld.md index a7588f8f7e..dad98fb5e0 100644 --- a/doc/pins/pins_hld.md +++ b/doc/pins/pins_hld.md @@ -284,10 +284,10 @@ Here is the full list of supplementary HLD docs: [packet-hld]: in_progress.md -[buildimage-repo]: https://github.com/Azure/sonic-buildimage +[buildimage-repo]: https://github.com/sonic-net/sonic-buildimage [p4c-repo]: https://github.com/p4lang/p4c -[swss-repo]: https://github.com/Azure/sonic-swss -[swss-common-repo]: https://github.com/Azure/sonic-swss-common +[swss-repo]: https://github.com/sonic-net/sonic-swss +[swss-common-repo]: https://github.com/sonic-net/sonic-swss-common [p4rt-spec-ref]: https://p4lang.github.io/p4runtime/spec/main/P4Runtime-Spec.html diff --git a/doc/platform/pde.md b/doc/platform/pde.md index a6a5735bbc..dd01bab7df 100644 --- a/doc/platform/pde.md +++ b/doc/platform/pde.md @@ -58,7 +58,7 @@ The requirements for the SONiC PDE are: 8. All platform drivers and device files will reside in their original SONiC locations as part of the PDE build process. 9. The PDE uses the base SONiC build generated Linux kernel, Debian bootstrap image, SAI, root filesystem, and other pre-compiled binaries necessary for booting the PDE ONIE image. 10. All PDE makefiles and associated supporting files reside in the base SONiC repository as part of the "sonic-buildimage" repository and will not interfere or execute as part of the normal SONiC build process. -11. The PDE supports the existing SONiC porting guide for adding new platform support. Please refer to [link](https://github.com/Azure/SONiC/wiki/Porting-Guide) for more information. +11. The PDE supports the existing SONiC porting guide for adding new platform support. Please refer to [link](https://github.com/sonic-net/SONiC/wiki/Porting-Guide) for more information. As the PDE New platform changes added in the PDE are seamlessly integrated into the SONiC base repository. diff --git a/doc/platform_api/new_platform_api.md b/doc/platform_api/new_platform_api.md index 42000a8000..08e3c8a59b 100644 --- a/doc/platform_api/new_platform_api.md +++ b/doc/platform_api/new_platform_api.md @@ -196,4 +196,4 @@ print("PSU 1 presence: {}".format(presence)) ### New Platform API Framework location -https://github.com/Azure/sonic-platform-common/tree/master/sonic_platform_base +https://github.com/sonic-net/sonic-platform-common/tree/master/sonic_platform_base diff --git a/doc/pmon/pmon-chassis-design.md b/doc/pmon/pmon-chassis-design.md index 304b8d0737..e2f751c8cc 100644 --- a/doc/pmon/pmon-chassis-design.md +++ b/doc/pmon/pmon-chassis-design.md @@ -422,7 +422,7 @@ Thermal 5 59 68 0 N/A N/A * Update per namespace port status - The pmon processes will need to run per-asic specific functinality ina a separate thread. Two approaches were discussed as part of the design: -* Approach-1 - Existing process and threads will connect/subscribe to all databases across per-asic namespace. This is the preferred approach and has been documented in https://github.com/Azure/SONiC/blob/master/doc/pmon/pmon_multiasic_design.md. +* Approach-1 - Existing process and threads will connect/subscribe to all databases across per-asic namespace. This is the preferred approach and has been documented in https://github.com/sonic-net/SONiC/blob/master/doc/pmon/pmon_multiasic_design.md. * Approach-2 - Create separate threads per-asic and that thread will connect/subscribe to databases in per-asic namespace. Approach-2 is outlined below for the sake of completeness. However, it is not the preferred approach. The maximum number of ports seen in a multi-asic environment for fixed platform or for line-cards in a chassis would not be greater than 64. Monitoring and subscribing for events for these ports can easily be accommodated by Approach-1. Additional management of per-asic threads will also add to the complexity of the design. #### Database Connections diff --git a/doc/pmon/pmon-enhancement-design.md b/doc/pmon/pmon-enhancement-design.md index 9845b97d89..bab0e5c212 100644 --- a/doc/pmon/pmon-enhancement-design.md +++ b/doc/pmon/pmon-enhancement-design.md @@ -138,7 +138,7 @@ All the peripheral devices data will be stored in state DB. #### 1.5.6 Transceiver Table -We have a transceiver related information DB schema defined in the [Xcvrd daemon design doc](https://github.com/Azure/SONiC/blob/master/doc/xrcvd/transceiver-monitor-hld.md#11-state-db-schema). +We have a transceiver related information DB schema defined in the [Xcvrd daemon design doc](https://github.com/sonic-net/SONiC/blob/master/doc/xrcvd/transceiver-monitor-hld.md#11-state-db-schema). To align with the output of the current show interface transceiver we need to extend Transceiver info Table with more information, as below: @@ -267,7 +267,7 @@ Currently Transceiver related CLI is fetching information by directly access the ### 2.6 PSU SNMP Agent re-factoring -After PSU status data post to state DB, SNMP agent will get PSU data from state DB instead of directly call platform psu plugin, related code in class [PowerStatusHandler](https://github.com/Azure/sonic-snmpagent/blob/master/src/sonic_ax_impl/mibs/vendor/cisco/ciscoEntityFruControlMIB.py#L13) will be changed accordingly. [PhysicalTableMIBUpdater](https://github.com/Azure/sonic-snmpagent/blob/master/src/sonic_ax_impl/mibs/ietf/rfc2737.py#L113) is a good example for updating MIB from state DB. +After PSU status data post to state DB, SNMP agent will get PSU data from state DB instead of directly call platform psu plugin, related code in class [PowerStatusHandler](https://github.com/sonic-net/sonic-snmpagent/blob/master/src/sonic_ax_impl/mibs/vendor/cisco/ciscoEntityFruControlMIB.py#L13) will be changed accordingly. [PhysicalTableMIBUpdater](https://github.com/sonic-net/sonic-snmpagent/blob/master/src/sonic_ax_impl/mibs/ietf/rfc2737.py#L113) is a good example for updating MIB from state DB. ### 2.7 Utilities for real-time data @@ -285,7 +285,7 @@ New base APIs were added for platform, chassis, watchdog, FAN and PSU. SFP and e Previously we have an issue with the old implementation, when adding a new platform API to the base class, have to implement it in all the platform plugins, or at least add a dummy stub to them, or it will fail on the platform that doesn't have it. This will be addressed in the new platform API design, not part of the work here. -Design doc for new platform API [design doc](https://github.com/Azure/SONiC/pull/285) and [code implementation PR](https://github.com/Azure/sonic-platform-common/pull/13) are available now. +Design doc for new platform API [design doc](https://github.com/sonic-net/SONiC/pull/285) and [code implementation PR](https://github.com/sonic-net/sonic-platform-common/pull/13) are available now. ## 4. Pmon daemons dynamically loading We have multi pmon daemons for different peripheral devices, like xcvrd for transceivers, ledd for front panel LEDs, etc. Later on we may add more for PSU, fan. diff --git a/doc/pmon/pmon_multiasic_design.md b/doc/pmon/pmon_multiasic_design.md index dc3106d9e0..118ec4a499 100644 --- a/doc/pmon/pmon_multiasic_design.md +++ b/doc/pmon/pmon_multiasic_design.md @@ -184,7 +184,7 @@ Here are the pros and cons of both the approaches, The swss-common::DBconnector class needs to be enhanced to use the **"namespace"** context information to connect to the DB instance in that namespace. The DB connector classes will have capability to parse the new "database\_global.json" file and retrieve the namespaces present in the platform and the database instances in each namespace. -Please refer [multi_namespace_db_instances design document](https://github.com/Azure/SONiC/blob/master/doc/database/multi_namespace_db_instances.md) for more details. +Please refer [multi_namespace_db_instances design document](https://github.com/sonic-net/SONiC/blob/master/doc/database/multi_namespace_db_instances.md) for more details. ## @@ -213,4 +213,4 @@ The snmp agent needs to connect to the STATE\_DB in different namespaces dependi 1. Which daemon in Sonic takes care of the **system/unit** LED's? -- It is being planned [https://github.com/Azure/sonic-buildimage/pull/4835](https://github.com/Azure/sonic-buildimage/pull/4835) +- It is being planned [https://github.com/sonic-net/sonic-buildimage/pull/4835](https://github.com/sonic-net/sonic-buildimage/pull/4835) diff --git a/doc/pmon/sonic_platform_test_plan.md b/doc/pmon/sonic_platform_test_plan.md index fbcc29560a..cf12a919ec 100644 --- a/doc/pmon/sonic_platform_test_plan.md +++ b/doc/pmon/sonic_platform_test_plan.md @@ -766,7 +766,7 @@ New automation required # Automation Design -This section outlines the design of scripts automating the SONiC platform test cases. The new pytest-ansible framework will be used. Sample code can be found [here](https://github.com/Azure/sonic-mgmt/tree/master/tests). +This section outlines the design of scripts automating the SONiC platform test cases. The new pytest-ansible framework will be used. Sample code can be found [here](https://github.com/sonic-net/sonic-mgmt/tree/master/tests). ## Folder Structure and Script Files The pytest framwork supports flexible test discovery. The plan is to put all platform related scripts under `tests/platform`. Command like `pytest tests/platform` would be able to discover all `test_*.py` and `*_test.py` under `tests/platform`. No entry script is required. diff --git a/doc/pmon/sonic_thermal_control_test_plan.md b/doc/pmon/sonic_thermal_control_test_plan.md index 66c0d5be50..feb974fff0 100644 --- a/doc/pmon/sonic_thermal_control_test_plan.md +++ b/doc/pmon/sonic_thermal_control_test_plan.md @@ -38,7 +38,7 @@ Since this feature is not related to traffic and network topology, all current t ### Ansible and Pytest -This test plan is based on platform test infrastructure as additional cases. The test will reuse current [platform test](https://github.com/Azure/SONiC-mgmt/tree/master/tests/platform) in SONiC-mgmt. New pytest test cases will be added to [test_platform_info.py](https://github.com/Azure/SONiC-mgmt/blob/master/tests/platform/test_platform_info.py). In addition, valid_policy.json, invalid_format_policy.json and invalid_value_policy.json will be added as thermal policy configuration file for test purpose. +This test plan is based on platform test infrastructure as additional cases. The test will reuse current [platform test](https://github.com/sonic-net/SONiC-mgmt/tree/master/tests/platform) in SONiC-mgmt. New pytest test cases will be added to [test_platform_info.py](https://github.com/sonic-net/SONiC-mgmt/blob/master/tests/platform/test_platform_info.py). In addition, valid_policy.json, invalid_format_policy.json and invalid_value_policy.json will be added as thermal policy configuration file for test purpose. #### Valid policy file diff --git a/doc/port-add-del-dynamically/dynamic_port_add_del_hld.md b/doc/port-add-del-dynamically/dynamic_port_add_del_hld.md index 076df35da4..90f729ec49 100644 --- a/doc/port-add-del-dynamically/dynamic_port_add_del_hld.md +++ b/doc/port-add-del-dynamically/dynamic_port_add_del_hld.md @@ -29,11 +29,11 @@ This document provides general information about ports creation or removal in SO This document describes the high level design of orchagent and the impact of creating/removing ports dynamically on other services. The design describes the current implementaion and suggestion to changes that needs to be implemented in order to fully support the dynamic create/remove of ports. ## Relevant PRs -[PR #7999 Allow cfggen to work on system without ports](https://github.com/Azure/sonic-buildimage/pull/7999)
-[PR #1860 Remove buffer drop counter when port is deleted](https://github.com/Azure/sonic-swss/pull/1860)
-[PR #1808 [swss]: Allow portsyncd to run on system without ports](https://github.com/Azure/sonic-swss/pull/1808)
-[PR #2019 [orchagent] add & remove port counters dynamically each time port was added or removed](https://github.com/Azure/sonic-swss/pull/2019)
-[PR #2022 Dynamic port configuration - add port buffer cfg to the port ref counter](https://github.com/Azure/sonic-swss/pull/2022)
+[PR #7999 Allow cfggen to work on system without ports](https://github.com/sonic-net/sonic-buildimage/pull/7999)
+[PR #1860 Remove buffer drop counter when port is deleted](https://github.com/sonic-net/sonic-swss/pull/1860)
+[PR #1808 [swss]: Allow portsyncd to run on system without ports](https://github.com/sonic-net/sonic-swss/pull/1808)
+[PR #2019 [orchagent] add & remove port counters dynamically each time port was added or removed](https://github.com/sonic-net/sonic-swss/pull/2019)
+[PR #2022 Dynamic port configuration - add port buffer cfg to the port ref counter](https://github.com/sonic-net/sonic-swss/pull/2022)
## Design @@ -68,9 +68,9 @@ The Dynamic port add/remove configuration will be supported for all types of ini **Note:** This is a new type of init that was never tested and will be supported.
The zero-port system is a special case of this feature.
Few PRs were already added in order to support zero ports init:
-[PR #7999 Allow cfggen to work on system without ports](https://github.com/Azure/sonic-buildimage/pull/7999)
-[PR #1860 Remove buffer drop counter when port is deleted](https://github.com/Azure/sonic-swss/pull/1860)
-[PR #1808 [swss]: Allow portsyncd to run on system without ports](https://github.com/Azure/sonic-swss/pull/1808)
+[PR #7999 Allow cfggen to work on system without ports](https://github.com/sonic-net/sonic-buildimage/pull/7999)
+[PR #1860 Remove buffer drop counter when port is deleted](https://github.com/sonic-net/sonic-swss/pull/1860)
+[PR #1808 [swss]: Allow portsyncd to run on system without ports](https://github.com/sonic-net/sonic-swss/pull/1808)
after init stage we can add/remove ports dynamically through redis call to add/remove entry to/from port table on config db ("PORT") @@ -156,7 +156,7 @@ In the current implementation these counters were created for all ports only aft ** Counters PR: **
-[https://github.com/Azure/sonic-swss/pull/2019](https://github.com/Azure/sonic-swss/pull/2019) +[https://github.com/sonic-net/sonic-swss/pull/2019](https://github.com/sonic-net/sonic-swss/pull/2019) @@ -201,8 +201,8 @@ each time the snmpagent needs information from ports (oper_state, mtu, speed..) Listen to events on cfg port table and update transeiver information
implemented on those PRs: -https://github.com/Azure/sonic-buildimage/pull/8422
-https://github.com/Azure/sonic-platform-daemons/pull/212 +https://github.com/sonic-net/sonic-buildimage/pull/8422
+https://github.com/sonic-net/sonic-platform-daemons/pull/212 ## Buffermgrd: @@ -253,7 +253,7 @@ Need to add to orchagent the ability to add the buffer configuration of a port a If we will not use this mechanism we will get a lot of SAI error and with this ref counter method we will receive only one warning. Also we wanted the buffer configuration to be the same as ACL/VLAN/INTERFACE configuration, which uses the ref counter for the dependencies, and before removing a port we check this ref counter. ** Buffer changes PR: **
-[https://github.com/Azure/sonic-swss/pull/2022](https://github.com/Azure/sonic-swss/pull/2022) +[https://github.com/sonic-net/sonic-swss/pull/2022](https://github.com/sonic-net/sonic-swss/pull/2022) diff --git a/doc/port-config-refactor/port-config-refactor-design.md b/doc/port-config-refactor/port-config-refactor-design.md index 75a2193926..6dba5baece 100644 --- a/doc/port-config-refactor/port-config-refactor-design.md +++ b/doc/port-config-refactor/port-config-refactor-design.md @@ -10,27 +10,27 @@ ## 1. Overview -The file "port_config.ini" defines port name, index and other information. In current SONiC code, there is a module [portconfig.py](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/portconfig.py) to parse and collect all information in this file. However, there are also other places have code to parse "port_config.ini". To keep code clean, it would be better to make all those parse logic reuse [portconfig.py](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/portconfig.py). +The file "port_config.ini" defines port name, index and other information. In current SONiC code, there is a module [portconfig.py](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-config-engine/portconfig.py) to parse and collect all information in this file. However, there are also other places have code to parse "port_config.ini". To keep code clean, it would be better to make all those parse logic reuse [portconfig.py](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-config-engine/portconfig.py). -There are also open PRs to begin transitioning from the "port_config.ini" file to a new "platform.json" file. So if we keep all parse logic in [portconfig.py](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/portconfig.py), it will be easy to keep backward compatible. +There are also open PRs to begin transitioning from the "port_config.ini" file to a new "platform.json" file. So if we keep all parse logic in [portconfig.py](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-config-engine/portconfig.py), it will be easy to keep backward compatible. ## 2. Changes in portconfig module -1. [portconfig.parse_port_config_file](https://github.com/Azure/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L28) return value should always contain the index of all ports even if "index" is not defined in "port_config.ini" because port index is used in other module. If there is no "index" defined, a 1-based auto-increment default value should be there. For now, there are still a few SKUs provided port_config.ini file with 0-based port index, all those port_config.ini files should be changed to 1-based. +1. [portconfig.parse_port_config_file](https://github.com/sonic-net/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L28) return value should always contain the index of all ports even if "index" is not defined in "port_config.ini" because port index is used in other module. If there is no "index" defined, a 1-based auto-increment default value should be there. For now, there are still a few SKUs provided port_config.ini file with 0-based port index, all those port_config.ini files should be changed to 1-based. ## 3. Files that contain "port_config.ini" related logic -1. [daemon_base.py](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-daemon-base/sonic_daemon_base/daemon_base.py) in [sonic-daemon-base](https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-daemon-base) contains logic to get file path of "port_config.ini", it should be replaced by [portconfig.get_port_config_file_name](https://github.com/Azure/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L6). -2. [sfputilbase.py](https://github.com/Azure/sonic-platform-common/blob/master/sonic_platform_base/sonic_sfp/sfputilbase.py) in [sonic-platform-common](https://github.com/Azure/sonic-platform-common) contains logic to parse "port_config.ini", it should be replaced by [portconfig.get_port_config](https://github.com/Azure/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L20). Currently sfptutilbase.py keeps 3 dictionaries and 1 list to store information gets from port_config.ini file. We will keep the current data structure of sfputilbase.py to avoid introduce too much changes which means that we need transform the output of portconfig.py to the existing data structure. -3. [sfputilhelper.py](https://github.com/Azure/sonic-platform-common/blob/master/sonic_platform_base/sonic_sfp/sfputilhelper.py) in [sonic-platform-common](https://github.com/Azure/sonic-platform-common) contains logic to parse "port_config.ini", it should be replaced by [portconfig.get_port_config](https://github.com/Azure/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L20). Since the current logic in sfputilhelper.py and sfputilbase.py are very similar, it is suggested to put the logic in a common place and reuse it. -4. [main.py](https://github.com/Azure/sonic-utilities/blob/master/sfputil/main.py) in [sonic-utilities](https://github.com/Azure/sonic-utilities) contains logic to get file path of "port_config.ini", it should be replaced by [portconfig.get_port_config_file_name](https://github.com/Azure/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L6). -5. [util_base.py](https://github.com/Azure/sonic-utilities/blob/master/utilities_common/util_base.py) in [sonic-utilities](https://github.com/Azure/sonic-utilities) contains logic to get file path of "port_config.ini", it should be replaced by [portconfig.get_port_config_file_name](https://github.com/Azure/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L6). +1. [daemon_base.py](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-daemon-base/sonic_daemon_base/daemon_base.py) in [sonic-daemon-base](https://github.com/sonic-net/sonic-buildimage/tree/master/src/sonic-daemon-base) contains logic to get file path of "port_config.ini", it should be replaced by [portconfig.get_port_config_file_name](https://github.com/sonic-net/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L6). +2. [sfputilbase.py](https://github.com/sonic-net/sonic-platform-common/blob/master/sonic_platform_base/sonic_sfp/sfputilbase.py) in [sonic-platform-common](https://github.com/sonic-net/sonic-platform-common) contains logic to parse "port_config.ini", it should be replaced by [portconfig.get_port_config](https://github.com/sonic-net/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L20). Currently sfptutilbase.py keeps 3 dictionaries and 1 list to store information gets from port_config.ini file. We will keep the current data structure of sfputilbase.py to avoid introduce too much changes which means that we need transform the output of portconfig.py to the existing data structure. +3. [sfputilhelper.py](https://github.com/sonic-net/sonic-platform-common/blob/master/sonic_platform_base/sonic_sfp/sfputilhelper.py) in [sonic-platform-common](https://github.com/sonic-net/sonic-platform-common) contains logic to parse "port_config.ini", it should be replaced by [portconfig.get_port_config](https://github.com/sonic-net/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L20). Since the current logic in sfputilhelper.py and sfputilbase.py are very similar, it is suggested to put the logic in a common place and reuse it. +4. [main.py](https://github.com/sonic-net/sonic-utilities/blob/master/sfputil/main.py) in [sonic-utilities](https://github.com/sonic-net/sonic-utilities) contains logic to get file path of "port_config.ini", it should be replaced by [portconfig.get_port_config_file_name](https://github.com/sonic-net/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L6). +5. [util_base.py](https://github.com/sonic-net/sonic-utilities/blob/master/utilities_common/util_base.py) in [sonic-utilities](https://github.com/sonic-net/sonic-utilities) contains logic to get file path of "port_config.ini", it should be replaced by [portconfig.get_port_config_file_name](https://github.com/sonic-net/sonic-buildimage/blob/142d45ce98008aac6437070a3a941083494b52a8/src/sonic-config-engine/portconfig.py#L6). There are also some vendor specified code contains "port_config.ini" related logic, those code should be refactored by each vendor. ## 4. Dependency -[portconfig.py](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/portconfig.py) is defined in [sonic-config-engine](https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-config-engine). In order to reuse this module: +[portconfig.py](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-config-engine/portconfig.py) is defined in [sonic-config-engine](https://github.com/sonic-net/sonic-buildimage/tree/master/src/sonic-config-engine). In order to reuse this module: 1. For those modules who have build-time unit test, they may declare sonic-config-engine as a build-time dependency in make rules. 2. For those modules who are installed in a docker, we must make sure sonic-config-engine is also installed in that docker, for example, pmon docker need reuse portconfig.py and it has sonic-config-engine installed. diff --git a/doc/port_auto_neg/port-auto-negotiation-design.md b/doc/port_auto_neg/port-auto-negotiation-design.md index 65f9e00064..d762e38fa1 100644 --- a/doc/port_auto_neg/port-auto-negotiation-design.md +++ b/doc/port_auto_neg/port-auto-negotiation-design.md @@ -678,10 +678,10 @@ Dynamic port breakout feature also introduces a hwsku.json file to describe the #### PMON xcvrd Consideration -While it is possible to use CLI/CONFIG_DB for setting the port auto negotiation attributes, this feature is also available via [media_settings.json](https://github.com/Azure/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) +While it is possible to use CLI/CONFIG_DB for setting the port auto negotiation attributes, this feature is also available via [media_settings.json](https://github.com/sonic-net/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) - **Interface Type** - Unfortunately, it's not straightforward for users to identify which interface type is most appropriate to the attached transceivers, and the link will not get up unless the connected devices are both advertising the same interface type. This requires domain knowledge, correct EERPOM information and the individual hardware datasheet review process. Hence it's recommended to use [media_settings.json](https://github.com/Azure/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) to automate the while process. A interface type update request from [media_settings.json](https://github.com/Azure/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) is triggered by the transceiver detection of pmon#xcvrd, which leverages **APPL_DB** instead of **CONFIG_DB**, hence the requests will not be blocked by **portsyncd**. If the interface type update request arrives when autoneg is enabled, it should alter the advertisement and restart the autoneg. That said, if the user has interface type configured in both CONFIG_DB and media_settings.json, it wouldn't be possible to predict which would take precedence as there is no logic giving one priority over other. Hence please be sure to use either CLI/CONFIG_DB or media_settings.json at a time, never have both of them activated. + Unfortunately, it's not straightforward for users to identify which interface type is most appropriate to the attached transceivers, and the link will not get up unless the connected devices are both advertising the same interface type. This requires domain knowledge, correct EERPOM information and the individual hardware datasheet review process. Hence it's recommended to use [media_settings.json](https://github.com/sonic-net/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) to automate the while process. A interface type update request from [media_settings.json](https://github.com/sonic-net/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) is triggered by the transceiver detection of pmon#xcvrd, which leverages **APPL_DB** instead of **CONFIG_DB**, hence the requests will not be blocked by **portsyncd**. If the interface type update request arrives when autoneg is enabled, it should alter the advertisement and restart the autoneg. That said, if the user has interface type configured in both CONFIG_DB and media_settings.json, it wouldn't be possible to predict which would take precedence as there is no logic giving one priority over other. Hence please be sure to use either CLI/CONFIG_DB or media_settings.json at a time, never have both of them activated. - **Pre-Emphasis** Typically, prior to some process, such as transmission over cable, or recording to phonograph record or tape, the input frequency range most susceptible to noise is boosted. This is referred to as "pre-emphasis" - before the process the signal will undergo. While this is rarely necessay to the native RJ45 ports, it's important to SFP/QSFP/QSFPDD ports. For optical arrangements (e.g. SR/LR/DR transceivers), the loss is miniscule. The loss budget allocated for the host PCB board is small, which implies the pre-emphasis calibrated is supposed to work regardless of the fiber cable attached. On the other hand, on passive media, there is a significant amount of frequency dependent loss and the channel loss can range up to the CR/KR loss spec. It is therefore important and useful to activate Link-Training to "train" the TX FIR in both directions to help equalize that loss. IEEE 802.3 Clause 72, Clause 73 and Clause 93 define the auto-negotiation and link-training support for CR/KR transceivers, while the support of opticals (e.g. SR/LR/DR) are never in the scope. On the other hand, when autoneg is enabled, the link-training will also be activated, and the link-training handshake will only get started after negotiation if autoneg is enabled. Furtherly, link-training is to dynamically tune hardware signals at runtime, as a result, the static pre-emphasis parameters in media_setting.json is not necessary and will not be taken into autoneg process. @@ -705,7 +705,7 @@ For sonic-utilities, we will leverage the existing unit test framework to test. 3. Test command `config interface type `. Verify the command return error if given invalid interface name or interface type. 4. Test command `config interface advertised-types `. Verify the command return error if given invalid interface name or interface type list. -For sonic-swss, there is an existing test case [test_port_an](https://github.com/Azure/sonic-swss/blob/master/tests/test_port_an.py). The existing test case covers autoneg and speed attributes on both direct and warm-reboot scenario. So new unit test cases need cover the newly supported attributes: +For sonic-swss, there is an existing test case [test_port_an](https://github.com/sonic-net/sonic-swss/blob/master/tests/test_port_an.py). The existing test case covers autoneg and speed attributes on both direct and warm-reboot scenario. So new unit test cases need cover the newly supported attributes: 1. Test attribute adv_speeds on both direct and warm-reboot scenario. Verify SAI_PORT_ATTR_ADVERTISED_SPEED is in ASIC_DB and has correct value. 2. Test attribute interface_type on both direct and warm-reboot scenario. Verify SAI_PORT_ATTR_INTERFACE_TYPE is in ASIC_DB and has correct value. diff --git a/doc/port_buffer_drop_counters/sonic_port_buffer_drop_counters.md b/doc/port_buffer_drop_counters/sonic_port_buffer_drop_counters.md index 4db44ab288..32c177564e 100644 --- a/doc/port_buffer_drop_counters/sonic_port_buffer_drop_counters.md +++ b/doc/port_buffer_drop_counters/sonic_port_buffer_drop_counters.md @@ -40,7 +40,7 @@ This document describes the motivation for port buffer drop counters and the cha # 1 Overview The main goal of this feature is to poll port level buffer drop counters in a safe way. -According to https://github.com/Azure/sonic-swss/pull/1308, +According to https://github.com/sonic-net/sonic-swss/pull/1308, > These counters are causing widespread issues in the master branch, so we're backing them out for now to be revisited in a later PR. They will likely need to be polled separately from the other counters, and on a longer interval, to avoid performance issues and conflicts. @@ -109,4 +109,4 @@ admin@sonic:~$ counterpoll port-buffer-drop disable ### 3.1.3 Setting new polling interval ``` admin@sonic:~$ counterpoll port-buffer-drop interval 30000 -``` \ No newline at end of file +``` diff --git a/doc/port_link_training/port-link-training-design.md b/doc/port_link_training/port-link-training-design.md index 18db296b67..e82369471f 100644 --- a/doc/port_link_training/port-link-training-design.md +++ b/doc/port_link_training/port-link-training-design.md @@ -52,7 +52,7 @@ The link-training hardware controls in this document is SAI specific, while the Link training is a process by which the transmitter and receiver on a high-speed serial link communicate with each other in order to tune their equalization settings. In theory, link training enables automatic tuning of the FIR filter for each channel in an ASIC to achieve the desired bit error rate (BER) -In current SONiC implementation, user can leverage the platform-specific [media_settings.json](https://github.com/Azure/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) to statically update the TX FIR per attached transceiver to improve BER. However, the ODM vendors rarely provide the pre-calibrated pre-emphasis for the CR/KR transceivers, which could result in the link reliability issues. +In current SONiC implementation, user can leverage the platform-specific [media_settings.json](https://github.com/sonic-net/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) to statically update the TX FIR per attached transceiver to improve BER. However, the ODM vendors rarely provide the pre-calibrated pre-emphasis for the CR/KR transceivers, which could result in the link reliability issues. The IEEE 802.3 standard defines a set of link training protocols for various mediums, and the feature in this document is to focus on IEEE clause 72 and 93 to dynamically improve the link quality over the SFP coppers and backplanes. @@ -316,11 +316,11 @@ N/A #### Unit Test cases -For **sonic-swss**, we will leverage the existing [test_port.py](https://github.com/Azure/sonic-swss/blob/master/tests/test_port.py) for this. A few new test cases will be added: +For **sonic-swss**, we will leverage the existing [test_port.py](https://github.com/sonic-net/sonic-swss/blob/master/tests/test_port.py) for this. A few new test cases will be added: 1. Test attribute **link_training** on both direct and warm-reboot scenario. Verify SAI_PORT_ATTR_LINK_TRAINING_ENABLE is in ASIC_DB and has correct value. -For **sonic-utilities**, we will leverage the existing [unit test framework](https://github.com/Azure/sonic-utilities/tree/master/tests) for this. A few new test cases will be added: +For **sonic-utilities**, we will leverage the existing [unit test framework](https://github.com/sonic-net/sonic-utilities/tree/master/tests) for this. A few new test cases will be added: 1. Test command `config interface link-training `. Verify the command return error if given invalid interface_name or mode. diff --git a/doc/psud/PSU_daemon_design.md b/doc/psud/PSU_daemon_design.md index f3e9006263..9ec6551c0a 100644 --- a/doc/psud/PSU_daemon_design.md +++ b/doc/psud/PSU_daemon_design.md @@ -35,7 +35,7 @@ Now psud collects PSU data via platform API, and it also support platform plugin ## 3. DB schema for PSU -PSU number is stored in chassis table. Please refer to this [document](https://github.com/Azure/SONiC/blob/master/doc/pmon/pmon-enhancement-design.md), section 1.5.2. +PSU number is stored in chassis table. Please refer to this [document](https://github.com/sonic-net/SONiC/blob/master/doc/pmon/pmon-enhancement-design.md), section 1.5.2. PSU information is stored in PSU table: @@ -138,7 +138,7 @@ We define a few abnormal PSU events here. When any PSU event happens, syslog sho ### 5.2 Platform API change -Some abstract member methods need to be added to [psu_base.py](https://github.com/Azure/sonic-platform-common/blob/master/sonic_platform_base/psu_base.py) and vendor should implement these methods. +Some abstract member methods need to be added to [psu_base.py](https://github.com/sonic-net/sonic-platform-common/blob/master/sonic_platform_base/psu_base.py) and vendor should implement these methods. ```python diff --git a/doc/qos/dynamically-headroom-calculation.md b/doc/qos/dynamically-headroom-calculation.md index 7145c0d4a7..e71f7fa0af 100644 --- a/doc/qos/dynamically-headroom-calculation.md +++ b/doc/qos/dynamically-headroom-calculation.md @@ -131,7 +131,7 @@ Backward compatibility is supported in the following ways: In this section we will introduce the ways it is achieved. -Currently, the SONiC system starts buffer manager from swss docker by the `supervisor` according to the following settings in [`/etc/supervisor/conf.d/supervisord.conf`](https://github.com/Azure/sonic-buildimage/blob/master/dockers/docker-orchagent/supervisord.conf) in `swss` docker. For the traditional mode, the argument is `-l /usr/share/sonic/hwsku/pg_profile_lookup.ini` which means to load the pg lookup file. +Currently, the SONiC system starts buffer manager from swss docker by the `supervisor` according to the following settings in [`/etc/supervisor/conf.d/supervisord.conf.j2`](https://github.com/sonic-net/sonic-buildimage/blob/master/dockers/docker-orchagent/supervisord.conf.j2) in `swss` docker. For the traditional mode, the argument is `-l /usr/share/sonic/hwsku/pg_profile_lookup.ini` which means to load the pg lookup file. ```shell [program:buffermgrd] @@ -1431,7 +1431,7 @@ In APPL_DB there should be: Status: Open. - Decision: Should be. But there is issues in SONiC ["dynamic_th" parameter for lossless buffer profile can't be change on the fly.](https://github.com/Azure/sonic-buildimage/issues/3971) + Decision: Should be. But there is issues in SONiC ["dynamic_th" parameter for lossless buffer profile can't be change on the fly.](https://github.com/sonic-net/sonic-buildimage/issues/3971) 6. There are default headrooms for lossy traffic which are determined by SDK and SONiC isn't aware. Do they affect shared buffer calculation? Status: Closed. @@ -1442,7 +1442,7 @@ In APPL_DB there should be: Status: Closed. Decision: There should be a maxinum value of the accumulate PGs for port. This can be fetched from ASIC_DB. -8. Originally buffer configuration had been stored in APPL_DB but were moved to CONFIG_DB later. Why? [doc](https://github.com/Azure/SONiC/wiki/Converting-old-or-creating-new-buffers-config) for reference. +8. Originally buffer configuration had been stored in APPL_DB but were moved to CONFIG_DB later. Why? [doc](https://github.com/sonic-net/SONiC/wiki/Converting-old-or-creating-new-buffers-config) for reference. 9. In theory, when system starts, as `BUFFER_PROFILE` and `BUFFER_PG` tables are stored in config database which survives system reboot, the `Buffer Orch` can receive items of the tables ahead of they being recalculated by `Buffer Manager` based on the current algorithm and `cable length` and `speed`. If the headroom size calculated differs before and after reboot, it can cause the items in the tables be deployed twice in which the first deployment will be overwritten quickly by the second one. 10. For chassis systems the gearbox in variant line-cards can differ, which means a mapping from port/line-card to gearbox model is required to get the correct gearbox model for a port. This requires additional field defined in `PORT` table or some newly introduced table. As this part hasn't been defined in community, we will not discuss this case for now. diff --git a/doc/qos/tunnel_dscp_remapping.md b/doc/qos/tunnel_dscp_remapping.md index d20fc108cd..1ef2c35996 100644 --- a/doc/qos/tunnel_dscp_remapping.md +++ b/doc/qos/tunnel_dscp_remapping.md @@ -61,10 +61,10 @@ This design proposes a method to remapping DSCP and TC for tunnel traffic. ### 5.1 SWSS Schema #### 5.1.1 Define new table for mapping -Update [qos_config.j2](https://github.com/Azure/sonic-buildimage/blob/master/files/build_templates/qos_config.j2) to generate 4 tables for remapping. Currently, the remapping is required in `dual-tor` scenario. So the tables are rendered into `config_db` only when `DEVICE_METADATA['localhost']['subtype'] = 'DualToR`. +Update [qos_config.j2](https://github.com/sonic-net/sonic-buildimage/blob/master/files/build_templates/qos_config.j2) to generate 4 tables for remapping. Currently, the remapping is required in `dual-tor` scenario. So the tables are rendered into `config_db` only when `DEVICE_METADATA['localhost']['subtype'] = 'DualToR`. Please be noted that below config is to remap traffic in queue 3 to queue 2, and traffic in queue 4 to queue 6. -Before remapping to queue 2 and 6, both queues are required to be cleared. Hence the current `DSCP_TO_TC_MAP|AZURE` in [qos_config.j2](https://github.com/Azure/sonic-buildimage/blob/master/files/build_templates/qos_config.j2) is required to be updated. +Before remapping to queue 2 and 6, both queues are required to be cleared. Hence the current `DSCP_TO_TC_MAP|AZURE` in [qos_config.j2](https://github.com/sonic-net/sonic-buildimage/blob/master/files/build_templates/qos_config.j2) is required to be updated. * Table for decap DSCP_TO_TC_MAP for mapping DSCP to TC @@ -232,7 +232,7 @@ In current version, PFC watchdog will read `pfc_enable` to determine PFCWD is en } ``` -To support new field `pfc_wd_sw_enable`, [sonic-port-qos-map.yang](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-port-qos-map.yang) is required to be updated. +To support new field `pfc_wd_sw_enable`, [sonic-port-qos-map.yang](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-port-qos-map.yang) is required to be updated. ### 5.2 SAI attribute @@ -321,4 +321,4 @@ All changes are to be covered by system test. ## 7 Open Questions - \ No newline at end of file + diff --git a/doc/recirculation-port/recirculation_port.md b/doc/recirculation-port/recirculation_port.md index 26ab8b4205..a050b1e6dc 100644 --- a/doc/recirculation-port/recirculation_port.md +++ b/doc/recirculation-port/recirculation_port.md @@ -64,7 +64,7 @@ The support of explicit recycle ports requires the minimal changes to SAI as lon Recirculation ports are configured in port_config.ini or platform.json just like front panel ports. In order to distinguish recirculation from front panel ports, the appropriate port role must be set for recirculation ports. The port role must indicate the intended use of a recirculation port. SONiC can discover all configured recirculation ports, based on their port roles, and use them appropriately. -As of now, there are two use cases of recirculation ports: inband port [here](https://github.com/Azure/SONiC/blob/master/doc/voq/architecture.md), or features like Everflow that needs to recycle encapsulated packets to be routed to the egress ASIC [here](https://github.com/Azure/SONiC/pull/716/files). In order to ensure the right recirculation ports are used, we introduce two port roles, Inb and Rec, for the two use cases respectively. +As of now, there are two use cases of recirculation ports: inband port [here](https://github.com/sonic-net/SONiC/blob/master/doc/voq/architecture.md), or features like Everflow that needs to recycle encapsulated packets to be routed to the egress ASIC [here](https://github.com/sonic-net/SONiC/pull/716/files). In order to ensure the right recirculation ports are used, we introduce two port roles, Inb and Rec, for the two use cases respectively. Two recirculation ports, Ethernet-Rec0 and Ethernet-IB0, are configured in the example port_config.ini below. Ethernet-Rec0 is used by Everflow, which has port role Rec. Ethernet-IB0 is used as an inband port and thus its port role is set to Inb. The recirculation port's lanes, used to discover the corresponding SAI ports, must be provided in port_config.ini as well. @@ -113,4 +113,4 @@ The process of recirculation ports in SWSS container is similar to front panel p ## 1.4 SAI -ASIC vendoers may implement recirculation ports in different ways. If recirculation ports are implemented just like front panel ports, then no SAI change is required because recirculation ports can be initialized and configured by using existing SAI port API. \ No newline at end of file +ASIC vendoers may implement recirculation ports in different ways. If recirculation ports are implemented just like front panel ports, then no SAI change is required because recirculation ports can be initialized and configured by using existing SAI port API. diff --git a/doc/sflow/Sflow_test_plan.md b/doc/sflow/Sflow_test_plan.md index 7eb48dae55..71b5eaa519 100644 --- a/doc/sflow/Sflow_test_plan.md +++ b/doc/sflow/Sflow_test_plan.md @@ -14,7 +14,7 @@ The test is targeting a running SONIC system with fully functioning configuratio The test will run on the t0 testbed: -![testbed-t0.png](https://github.com/Azure/sonic-mgmt/blob/master/ansible/doc/img/testbed-t0.png?raw=true) +![testbed-t0.png](https://github.com/sonic-net/sonic-mgmt/blob/master/docs/testbed/img/testbed-t0.png?raw=true) - 1 port from each port channel is used for traffic. Sflow is enabled on these 4 ports - 2 ports from Vlan1000 are removed and used to reach sflow collector in ptf docker . diff --git a/doc/sfp-cmis/Interface-Link-bring-up-sequence.md b/doc/sfp-cmis/Interface-Link-bring-up-sequence.md index 227c0d4176..9a993ad6cc 100644 --- a/doc/sfp-cmis/Interface-Link-bring-up-sequence.md +++ b/doc/sfp-cmis/Interface-Link-bring-up-sequence.md @@ -194,10 +194,10 @@ Following items are not in the scope of this document. They would be taken up se - Cleanup scenario - Check if the host_tx_ready field in STATE-DB need to be updated to “False” for any use-case, either in going down or coming up path - Discuss further on the possible use-cases 3. CMIS API feature is not part of this design and the APIs will be used in this design. For CMIS HLD, Please refer to: - https://github.com/Azure/SONiC/blob/9d480087243fd1158e785e3c2f4d35b73c6d1317/doc/sfp-cmis/cmis-init.md + https://github.com/sonic-net/SONiC/blob/9d480087243fd1158e785e3c2f4d35b73c6d1317/doc/sfp-cmis/cmis-init.md 4. Error handling of SAI attributes a) At present, If there is a set attribute failure, orch agent will exit. - Refer the error handling API : https://github.com/Azure/sonic-swss/blob/master/orchagent/orch.cpp#L885 + Refer the error handling API : https://github.com/sonic-net/sonic-swss/blob/master/orchagent/orch.cpp#L885 b) Error handling for SET_ADMIN_STATUS attribute will be added in future. c) A propabale way to handle the failure is to set a error handling attribute to respective container syncd/GBsyncd with attribute that is failed. The platform layer knows the error better and it will try to recover. diff --git a/doc/snmp/extension-to-physical-entity-mib.md b/doc/snmp/extension-to-physical-entity-mib.md index 92cc2665b0..4453606ece 100644 --- a/doc/snmp/extension-to-physical-entity-mib.md +++ b/doc/snmp/extension-to-physical-entity-mib.md @@ -364,7 +364,7 @@ Port Sensor Type describes below: #### 1.5.1 Unit test -SNMP unit test for sensors (https://github.com/Azure/sonic-snmpagent/blob/master/tests/test_sensor.py) will be extended to cover all the new added MIB objects and physical components. +SNMP unit test for sensors (https://github.com/sonic-net/sonic-snmpagent/blob/master/tests/test_sensor.py) will be extended to cover all the new added MIB objects and physical components. #### 1.5.2 Community regression test @@ -374,7 +374,7 @@ New test cases will be added to cover the new MIB entries: 2. Get fan MIB info and cross-check with the FAN_INFO table. 3. Get PSU related MIB info and cross-check with PSU_INFO and related tables 4. Remove/Add DB entries from related tables to see whether MIB info can be correctly updated. -5. Currently, each platform API is tested by sonic-mgmt, see [here](https://github.com/Azure/sonic-mgmt/tree/master/tests/platform_tests/api). We will add regression test case for each newly added platform API to verify them. +5. Currently, each platform API is tested by sonic-mgmt, see [here](https://github.com/sonic-net/sonic-mgmt/tree/master/tests/platform_tests/api). We will add regression test case for each newly added platform API to verify them. ## 2. Entity Sensor MIB Extension @@ -435,8 +435,8 @@ PSU Power Sensor: #### 2.3.1 Unit test -SNMP unit test for sensors (https://github.com/Azure/sonic-snmpagent/blob/master/tests/test_sensor.py) will be extended to cover all the new added sensors MIB objects. +SNMP unit test for sensors (https://github.com/sonic-net/sonic-snmpagent/blob/master/tests/test_sensor.py) will be extended to cover all the new added sensors MIB objects. #### 2.3.2 Community regression test -SNMP Entity community regression test (https://github.com/Azure/sonic-mgmt/blob/master/tests/snmp/test_snmp_phy_entity.py) will be extended to cover all the new added sensors. +SNMP Entity community regression test (https://github.com/sonic-net/sonic-mgmt/blob/master/tests/snmp/test_snmp_phy_entity.py) will be extended to cover all the new added sensors. diff --git a/doc/snmp/snmp-configdb-migration-hld.md b/doc/snmp/snmp-configdb-migration-hld.md index 942f748d21..07a09bfaaa 100644 --- a/doc/snmp/snmp-configdb-migration-hld.md +++ b/doc/snmp/snmp-configdb-migration-hld.md @@ -18,7 +18,7 @@ The goal of this update is to move away from the snmp.yml file and move towards # Config DB ## SNMP SCHEMA Some new "SNMP" tables should be added to ConfigDB in order to store SNMP related configuration. -https://github.com/Azure/SONiC/blob/master/doc/snmp/snmp-schema-addition.md +https://github.com/sonic-net/SONiC/blob/master/doc/snmp/snmp-schema-addition.md The new SNMP tables are: SNMP diff --git a/doc/sonic-application-extension/sonic-application-extension-guide.md b/doc/sonic-application-extension/sonic-application-extension-guide.md index 0f22ff5eb9..4f6f2f5f57 100644 --- a/doc/sonic-application-extension/sonic-application-extension-guide.md +++ b/doc/sonic-application-extension/sonic-application-extension-guide.md @@ -30,7 +30,7 @@ It is recommended to get acquainted with [HLD](sonic-application-extention-hld.m It is possible to port existing SONiC docker image and make it an Application Extension. -An example of porting DHCP relay - https://github.com/Azure/sonic-buildimage/commit/b3b6938fda9244607fb00bfd36a74bccab0c38a9. +An example of porting DHCP relay - https://github.com/sonic-net/sonic-buildimage/commit/b3b6938fda9244607fb00bfd36a74bccab0c38a9. 1. Add a new build time flag to SONiC build system to control whether to include new Docker Image *XXX*: @@ -63,7 +63,7 @@ $(DOCKER_XXX)_CONTAINER_VOLUMES += /usr/share/sonic/scripts:/usr/share/sonic/scr $(DOCKER_XXX)_CONTAINER_TMPFS += /tmp/ ```` -These variables are used to generate manifest for docker at build time (see generate_manifest function in https://github.com/Azure/sonic-buildimage/blob/master/rules/functions): +These variables are used to generate manifest for docker at build time (see generate_manifest function in https://github.com/sonic-net/sonic-buildimage/blob/master/rules/functions): 4. For extensions that provide CLI commands a CLI plugin is needed. @@ -124,7 +124,7 @@ Modify files/build_templates/packages.json.j2 to include new package. Example fo ### Building SONiC image with 3rd party application To build SONiC image with 3rd party application pre-installed use SONIC_PACKAGES target group. -See https://github.com/Azure/sonic-buildimage/blob/master/rules/sonic-packages.mk. +See https://github.com/sonic-net/sonic-buildimage/blob/master/rules/sonic-packages.mk. Create a file under rules/ called rules/cpu-report.mk with the following content: ```makefile diff --git a/doc/sonic-application-extension/sonic-application-extention-hld.md b/doc/sonic-application-extension/sonic-application-extention-hld.md index 50dbfb10eb..905bf518d4 100644 --- a/doc/sonic-application-extension/sonic-application-extention-hld.md +++ b/doc/sonic-application-extension/sonic-application-extention-hld.md @@ -163,7 +163,7 @@ In the above figure *Azure/sonic-dhcp-relay* and *Azure/sonic-snmp* are reposito SONiC Packages must meet few requirements in order to be a SONiC compatible Docker image. - A package must provide a manifest as part of the Docker image. -- Requirement on the container state recording by [Kubernetes HLD](https://github.com/Azure/SONiC/blob/698e8d7991c0ca3d21b4488cf336efcfe891ef9a/doc/kubernetes/Kuberenetes-support.md)). +- Requirement on the container state recording by [Kubernetes HLD](https://github.com/sonic-net/SONiC/blob/698e8d7991c0ca3d21b4488cf336efcfe891ef9a/doc/kubernetes/Kuberenetes-support.md)). ###### Figure 2. High Level Overview of SONiC Package integration @@ -945,7 +945,7 @@ be auto-generated as well. To avoid re-generating *swss.sh* script we will put d The file path is chosen to be */etc/sonic/\_dependent* for single instance services and */etc/sonic/\_dependent_multi_inst_dependent* for multi instance services. -Example of required code change for swss is given below [swss.sh](https://github.com/Azure/sonic-buildimage/blob/master/files/scripts/swss.sh): +Example of required code change for swss is given below [swss.sh](https://github.com/sonic-net/sonic-buildimage/blob/master/files/scripts/swss.sh): ```bash DEPENDENT="radv dhcp_relay" @@ -961,9 +961,9 @@ The infrastructure is not deciding whether this script is needed for a particula container lifetime hooks provided by a feature, instead this script is always generated and if no specific actions descirbed above are needed it becomes a simple wrapper around a script under /usr/bin/. -Examples are [swss.sh](https://github.com/Azure/sonic-buildimage/blob/master/files/scripts/swss.sh), -[syncd.sh](https://github.com/Azure/sonic-buildimage/blob/master/files/scripts/syncd.sh), -[bgp.sh](https://github.com/Azure/sonic-buildimage/blob/master/files/scripts/bgp.sh). These scripts +Examples are [swss.sh](https://github.com/sonic-net/sonic-buildimage/blob/master/files/scripts/swss.sh), +[syncd.sh](https://github.com/sonic-net/sonic-buildimage/blob/master/files/scripts/syncd.sh), +[bgp.sh](https://github.com/sonic-net/sonic-buildimage/blob/master/files/scripts/bgp.sh). These scripts share a good amount of code, thus making it possible to templatize into a single script that can be parametrized during generation according to feature needs - place lifecycle action hooks and dependent service management. @@ -984,7 +984,7 @@ after installation all the service scripts under */usr/local/bin/* are re-genera ##### /usr/bin/*feature*.sh The script under /usr/bin/ starts, stops or waits for container exit. This script is auto-generated during build time from -[docker_image_ctl.j2](https://github.com/Azure/sonic-buildimage/blob/4006ce711fa6545b0870186ffa05d4df24edb8b7/files/build_templates/docker_image_ctl.j2). +[docker_image_ctl.j2](https://github.com/sonic-net/sonic-buildimage/blob/4006ce711fa6545b0870186ffa05d4df24edb8b7/files/build_templates/docker_image_ctl.j2). To allow a runtime package installation, it is required to have this file as part of SONiC image and put it in */usr/share/sonic/templates/docker_image_ctl.j2*. The Jinja2 template will accept three arguments, *docker_container_name*, *docker_image_name* and *docker_run_options*, which derive from the */container/* node from manifest. Besides of options @@ -1136,7 +1136,7 @@ ave to be also auto-generated from YANG in the future. ### SONiC Processes and Docker Statistics Telemetry Support -[Processes And Docker Stats Telemetry HLD](https://github.com/Azure/SONiC/blob/master/doc/system-telemetry/process-docker-stats.md) +[Processes And Docker Stats Telemetry HLD](https://github.com/sonic-net/SONiC/blob/master/doc/system-telemetry/process-docker-stats.md) This feature should be supported by SONiC Application Extension without any changes to existing feature implementation. @@ -1146,7 +1146,7 @@ SONiC controls optional feature (aka services) via FEATURE table in CONFIG DB. O it must be treated in the same way as any optional SONiC feature. The SONiC package installation process will register new feature in CONFIG DB. -[Optional Feature HLD Reference](https://github.com/Azure/SONiC/blob/master/doc/Optional-Feature-Control.md) +[Optional Feature HLD Reference](https://github.com/sonic-net/SONiC/blob/master/doc/Optional-Feature-Control.md) Features are configured in *FEATURE* table in *CONFIG DB* and backend - *hostcfgd* daemon - enables, disables features according to the configuration. Default desired state for a SONiC Application Extension is "disabled". After installation, user can enable the feature: @@ -1308,7 +1308,7 @@ admin@sonic:~$ sudo sonic-installer install -y sonic.bin --no-package-migration ### Kubernetes & SONiC Application Extension -[Kubernetes HLD](https://github.com/Azure/SONiC/blob/be12cc665c316348352b868f515714f202861f63/doc/kubernetes/Kubernetes-support.md) +[Kubernetes HLD](https://github.com/sonic-net/SONiC/blob/be12cc665c316348352b868f515714f202861f63/doc/kubernetes/Kubernetes-support.md) This section is WIP and describes the approach in very high level and needs more deep investigation. diff --git a/doc/sonic-build-system/build-enhancements.md b/doc/sonic-build-system/build-enhancements.md index a86ae53750..2bb0b87981 100644 --- a/doc/sonic-build-system/build-enhancements.md +++ b/doc/sonic-build-system/build-enhancements.md @@ -80,7 +80,7 @@ This feature provides improvements in three essential areas. Reference: - Version caching feature is enhanced on top of DPKG caching and Versioning framework. Ref: - - https://github.com/Azure/SONiC/blob/master/doc/sonic-build-system/DPKG%20caching%20framework%20.ppt + - https://github.com/sonic-net/SONiC/blob/master/doc/sonic-build-system/DPKG%20caching%20framework%20.pptx - https://github.com/xumia/SONiC/blob/repd3/doc/sonic-build-system/SONiC-Reproduceable-Build.md # Feature Requirements @@ -557,5 +557,5 @@ files/build/versions/ ## References - Ref: - - https://github.com/Azure/SONiC/blob/master/doc/sonic-build-system/DPKG%20caching%20framework%20.ppt + - https://github.com/sonic-net/SONiC/blob/master/doc/sonic-build-system/DPKG%20caching%20framework%20.pptx - https://github.com/xumia/SONiC/blob/repd3/doc/sonic-build-system/SONiC-Reproduceable-Build.md diff --git a/doc/sonic-build-system/build_system_improvements.md b/doc/sonic-build-system/build_system_improvements.md index 99342ab3cf..122bdf1d7e 100644 --- a/doc/sonic-build-system/build_system_improvements.md +++ b/doc/sonic-build-system/build_system_improvements.md @@ -155,7 +155,7 @@ If your package can be built in parallel, please either use compat 10 or pass -- ## Seperate sairedis RPC from non-RPC build -Some work is done on that but no PR (https://github.com/Azure/sonic-sairedis/issues/333) +Some work is done on that but no PR (https://github.com/sonic-net/sonic-sairedis/issues/333) sairedis is a dependency for a lot of targets (usually I see sairedis compilation takes a lot of time blocking other targets to start) diff --git a/doc/sonic-flags/control-sonic-behaviors-with-sonic-flags.md b/doc/sonic-flags/control-sonic-behaviors-with-sonic-flags.md index 51015a5fe8..a7787a2860 100644 --- a/doc/sonic-flags/control-sonic-behaviors-with-sonic-flags.md +++ b/doc/sonic-flags/control-sonic-behaviors-with-sonic-flags.md @@ -83,7 +83,7 @@ Below is a sample of `SYSTEM_DEFAULTS` table #### 5.2.1 Set default value with `init_cfg.json` The default value of flags in `SYSTEM_DEFAULTS` table can be set in `init_cfg.json` and loaded into db at system startup. These flags are usually set at image being build, and are unlikely to change at runtime. -If the values in `config_db.json` is changed by user, it will not be rewritten back by `init_cfg.json` as `config_db.json` is loaded after `init_cfg.json` in [docker_image_ctl.j2](https://github.com/Azure/sonic-buildimage/blob/master/files/build_templates/docker_image_ctl.j2) +If the values in `config_db.json` is changed by user, it will not be rewritten back by `init_cfg.json` as `config_db.json` is loaded after `init_cfg.json` in [docker_image_ctl.j2](https://github.com/sonic-net/sonic-buildimage/blob/master/files/build_templates/docker_image_ctl.j2) ``` if [ -r /etc/sonic/config_db$DEV.json ]; then @@ -128,7 +128,7 @@ The `SYSTEM_DEFAULTS` table can be subscribed by components that are interested 2. Templates that depend on `DEVICE_METADATA|localhost` table are required to be updated. ### 6.2 Yang model update -A new Yang model is to be added to restrict the valid flags in `SYSTEM_DEFAULTS` table. The existing entries for flags in current [sonic-device_metadata.yang](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-device_metadata.yang) are to be removed. +A new Yang model is to be added to restrict the valid flags in `SYSTEM_DEFAULTS` table. The existing entries for flags in current [sonic-device_metadata.yang](https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-device_metadata.yang) are to be removed. ### 6.3 Code change 1. Update `db_migrator.py` to migrate flags from `DEVICE_METADATA|localhost` table to `SYSTEM_DEFAULTS` table. Current flags include diff --git a/doc/ssdhealth_design.md b/doc/ssdhealth_design.md index 886ba826db..4d111cc84c 100644 --- a/doc/ssdhealth_design.md +++ b/doc/ssdhealth_design.md @@ -136,7 +136,7 @@ Location: `sonic-buildimage/device/{{vendor}}/platform/plugins/ssdutil.py` ## Utilities and packages #### smartctl Part of smartmontools package (1.9M) -PR: [https://github.com/Azure/sonic-buildimage/pull/2703](https://github.com/Azure/sonic-buildimage/pull/2703) +PR: [https://github.com/sonic-net/sonic-buildimage/pull/2703](https://github.com/sonic-net/sonic-buildimage/pull/2703) #### iSmart Utility for InnoDisk Corp. SSDs (<120K) diff --git a/doc/subport/sonic-sub-port-intf-hld.md b/doc/subport/sonic-sub-port-intf-hld.md index cf5db32ec9..e126396765 100644 --- a/doc/subport/sonic-sub-port-intf-hld.md +++ b/doc/subport/sonic-sub-port-intf-hld.md @@ -750,16 +750,16 @@ Wenda would like to thank his colleagues with Microsoft SONiC team, Shuotian, Pr [2] Remove the need to create an object id for vlan in creating a sub port router interface https://github.com/opencomputeproject/SAI/pull/998 -[3] Sub port interface schema https://github.com/Azure/sonic-swss-common/pull/284 +[3] Sub port interface schema https://github.com/sonic-net/sonic-swss-common/pull/284 -[4] Sub port interface implementation https://github.com/Azure/sonic-swss/pull/969 +[4] Sub port interface implementation https://github.com/sonic-net/sonic-swss/pull/969 -[5] Use dot1p in packet 802.1q tag to map a packet to traffic class (TC) inside a switch pipeline https://github.com/Azure/sonic-swss/pull/871; https://github.com/Azure/sonic-buildimage/pull/3412; https://github.com/Azure/sonic-buildimage/pull/3422 +[5] Use dot1p in packet 802.1q tag to map a packet to traffic class (TC) inside a switch pipeline https://github.com/sonic-net/sonic-swss/pull/871; https://github.com/sonic-net/sonic-buildimage/pull/3412; https://github.com/sonic-net/sonic-buildimage/pull/3422 -[6] Generate a CONFIG_DB with sub port interface config from minigraph https://github.com/Azure/sonic-buildimage/pull/3413 +[6] Generate a CONFIG_DB with sub port interface config from minigraph https://github.com/sonic-net/sonic-buildimage/pull/3413 -[7] CLI to support sub port interface admin status change https://github.com/Azure/sonic-utilities/pull/638 +[7] CLI to support sub port interface admin status change https://github.com/sonic-net/sonic-utilities/pull/638 -[8] CLI to show subinterfaces status https://github.com/Azure/sonic-utilities/pull/642 +[8] CLI to show subinterfaces status https://github.com/sonic-net/sonic-utilities/pull/642 -[8] CLI to add/del ip address on a sub port interface https://github.com/Azure/sonic-utilities/pull/651 +[8] CLI to add/del ip address on a sub port interface https://github.com/sonic-net/sonic-utilities/pull/651 diff --git a/doc/synchronous-mode/synchronous-mode-cfg.md b/doc/synchronous-mode/synchronous-mode-cfg.md index a4926bbf03..2a7a26257e 100644 --- a/doc/synchronous-mode/synchronous-mode-cfg.md +++ b/doc/synchronous-mode/synchronous-mode-cfg.md @@ -48,4 +48,4 @@ When the synchronous mode configuration exists in configDB, the configuration in The minigraph parser would explicitly write either "disable" or "enable" into `DEVICE_METADATA|localhost|synchronous_mode` in config_DB as the ground-truth configuration. And the configuration will be applied after swss restarts. Such a design complies with requirement 4 in Section 3.1. ### 3.6 Configuration with L2 switch mode -When configuring a device to [L2 Switch mode](https://github.com/Azure/SONiC/wiki/L2-Switch-mode), the configuration of synchronous mode in config_DB will be removed. In the scenario that there is no user-specified configuration for the synchronous mode in configDB before configuring to L2 Switch mode, the device will keep using the same default mode specified by the image after configuring to L2 switch mode. If the user would like to use a specific configuration for the synchronous mode, the user needs to specify the configuration with the CLI in Section 3.3 to explicitly wite the configuration into config_DB after configuring the switch to L2 switch mode. +When configuring a device to [L2 Switch mode](https://github.com/sonic-net/SONiC/wiki/L2-Switch-mode), the configuration of synchronous mode in config_DB will be removed. In the scenario that there is no user-specified configuration for the synchronous mode in configDB before configuring to L2 Switch mode, the device will keep using the same default mode specified by the image after configuring to L2 switch mode. If the user would like to use a specific configuration for the synchronous mode, the user needs to specify the configuration with the CLI in Section 3.3 to explicitly wite the configuration into config_DB after configuring the switch to L2 switch mode. diff --git a/doc/system-telemetry/grpc_telemetry.md b/doc/system-telemetry/grpc_telemetry.md index c7ade6b325..78049fd23c 100644 --- a/doc/system-telemetry/grpc_telemetry.md +++ b/doc/system-telemetry/grpc_telemetry.md @@ -61,7 +61,7 @@ Within each DB, the data usually is organized in hierarchy of Table, key, field ``` Some data like COUNTERS table in COUNTERS_DB doesn't have key, but field and value are stored directly under COUNTERS table. -Refer to [SONiC data schema](https://github.com/Azure/sonic-swss-common/blob/master/common/schema.h) for more info about DB and table. +Refer to [SONiC data schema](https://github.com/sonic-net/sonic-swss-common/blob/master/common/schema.h) for more info about DB and table. For data not available in DBs, Target name "OTHERS" is designated for that category of data, paths like platform/cpu or proc/loadavg under "OTHERS" target may be used get/subscribe the data. diff --git a/doc/tpid/SonicTPIDSettingHLD1.md b/doc/tpid/SonicTPIDSettingHLD1.md index 7fd348bc99..54262abc97 100644 --- a/doc/tpid/SonicTPIDSettingHLD1.md +++ b/doc/tpid/SonicTPIDSettingHLD1.md @@ -381,6 +381,6 @@ The following test cases are to be run manually (eventually as part of the pytes ============== a) SONiC Configuration Management -b) +b) c) diff --git a/doc/voq/bgp_voq_chassis.md b/doc/voq/bgp_voq_chassis.md index e078f49cec..d904a76d95 100644 --- a/doc/voq/bgp_voq_chassis.md +++ b/doc/voq/bgp_voq_chassis.md @@ -89,7 +89,7 @@ nexthop of 10.0.1.2 would be recursively resolvable on ASIC2 over the 10.0.1.2/32 route created from the global neighbor table. (For more discussion on the creation of these host routes and how the recursively-resolved nexthops contribute to forwarding, see the -[VOQ HLD](https://github.com/Azure/SONiC/blob/master/doc/voq/voq_hld.md#251-inband-recycle-port-option).) +[VOQ HLD](https://github.com/sonic-net/SONiC/blob/master/doc/voq/voq_hld.md#251-inband-recycle-port-option).) The BGP sessions between ASIC Instances use IPv4. To get IPv6 routes distributed to all ASIC Instances, each iBGP peer will also be activated in diff --git a/doc/voq/everflow.md b/doc/voq/everflow.md index 74efa148a8..4ceecb4342 100644 --- a/doc/voq/everflow.md +++ b/doc/voq/everflow.md @@ -31,7 +31,7 @@ This document provides an overview of the SONiC support for everflow configurati # Scope -This document builds on top of the VOQ chassis architecture discussed [here](https://github.com/Azure/SONiC/blob/master/doc/voq/architecture.md) and the Everflow design discussed [here](https://github.com/Azure/SONiC/wiki/Everflow-High-Level-Design#3138-mirror-api). The goal of this document is to describe the configuration and design for everflow mirroring sessions for a VOQ-based chassis. +This document builds on top of the VOQ chassis architecture discussed [here](https://github.com/sonic-net/SONiC/blob/master/doc/voq/architecture.md) and the Everflow design discussed [here](https://github.com/sonic-net/SONiC/wiki/Everflow-High-Level-Design#3138-mirror-api). The goal of this document is to describe the configuration and design for everflow mirroring sessions for a VOQ-based chassis. # Definitions/Abbreviations diff --git a/doc/voq/fabric.md b/doc/voq/fabric.md index 2dc52fb286..b3360f01f3 100644 --- a/doc/voq/fabric.md +++ b/doc/voq/fabric.md @@ -39,7 +39,7 @@ This document covers: - Bring up of fabric ports in a VOQ chassis. - Monitoring the fabric ports in forwarding and fabric chips. -This document builds on top of the VOQ chassis architecture discussed [here](https://github.com/Azure/SONiC/blob/master/doc/voq/architecture.md) and the multi-ASIC architecture discussed [here](https://github.com/Azure/SONiC/blob/2f320430c8199132c686c06b5431ab93a86fb98f/doc/multi_asic/SONiC_multi_asic_hld.md). +This document builds on top of the VOQ chassis architecture discussed [here](https://github.com/sonic-net/SONiC/blob/master/doc/voq/architecture.md) and the multi-ASIC architecture discussed [here](https://github.com/sonic-net/SONiC/blob/2f320430c8199132c686c06b5431ab93a86fb98f/doc/multi_asic/SONiC_multi_asic_hld.md). # Definitions/Abbreviations diff --git a/doc/voq/voq_hld.md b/doc/voq/voq_hld.md index 6f81498d0e..3ab6be8a84 100644 --- a/doc/voq/voq_hld.md +++ b/doc/voq/voq_hld.md @@ -314,7 +314,7 @@ No changes in the schema of other CONFIG_DB tables. The name of the system ports For router interface and address configurations for the system ports, the existing INTERFACE table in CONFIG_DB is used. -Please refer to the [schema](https://github.com/Azure/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. +Please refer to the [schema](https://github.com/sonic-net/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. ## 2.4 Orchestration agent ### VOQ Switch Creation diff --git a/doc/vrf/sonic-vrf-hld.md b/doc/vrf/sonic-vrf-hld.md index e93c3c32f4..ed3c274ede 100644 --- a/doc/vrf/sonic-vrf-hld.md +++ b/doc/vrf/sonic-vrf-hld.md @@ -223,7 +223,7 @@ Here are the new flags we propose to add in the SAI interface: ## SONiC system diagram for VRF The following is high level diagram of modules with VRF support. -![](https://github.com/Azure/SONiC/blob/f2ebba476b4ef364b13b7980c2fe01e8929c71e6/images/vrf_hld/VRF_HIGH_LEVEL_DIAGRAM.png) +![](https://github.com/sonic-net/SONiC/blob/f2ebba476b4ef364b13b7980c2fe01e8929c71e6/images/vrf_hld/VRF_HIGH_LEVEL_DIAGRAM.png) ## The schema changes @@ -666,7 +666,7 @@ sai_remove_virtual_router_fn defined in saivirtualrouter.h to track (VR, VRF) cr - When app-intf-prefix-table change - add ip address event: wait until route interface is created ,then set ip address on existing router interface. - del ip address event: unset ip address on existing router interface. -- Move add/del subnet-route code to routeorch. In existing implementation when route interface is down, subnet routes associated with the interface still exist. It could result in a stale state and correct route configured from fpmsyncd will be rejected by routeorch. It makes sense that fpmsyncd/routeorch handles all route configurations except ip2me route. Nephos has submit this PR to swss community(). To support vrf these code will be refined to support vrf feature. +- Move add/del subnet-route code to routeorch. In existing implementation when route interface is down, subnet routes associated with the interface still exist. It could result in a stale state and correct route configured from fpmsyncd will be rejected by routeorch. It makes sense that fpmsyncd/routeorch handles all route configurations except ip2me route. Nephos has submit this PR to swss community(). To support vrf these code will be refined to support vrf feature. This change is necessary for vrf route-leak scenarios too. For example, interface Ethernet1 currently belongs to Vrf_blue , its ip address is 10.1.1.1/24. Another vrf domain Vrf_red imports all Vrf_blue route. Then there is a route like "Vrf_red:10.1.1.0/24 Ethernet1" in BGP route. When fpmsyncd pushes this route to routeorch, routeorch will drop it silently. diff --git a/doc/vxlan/EVPN/EVPN_VXLAN_HLD.md b/doc/vxlan/EVPN/EVPN_VXLAN_HLD.md index 3074b03a28..2775017e46 100644 --- a/doc/vxlan/EVPN/EVPN_VXLAN_HLD.md +++ b/doc/vxlan/EVPN/EVPN_VXLAN_HLD.md @@ -1501,6 +1501,6 @@ To support warm boot, all the sai_objects must be uniquely identifiable based on ## 9 References -- [SONiC VXLAN HLD](https://github.com/Azure/SONiC/blob/master/doc/vxlan/Vxlan_hld.md) +- [SONiC VXLAN HLD](https://github.com/sonic-net/SONiC/blob/master/doc/vxlan/Vxlan_hld.md) - [RFC 7432](https://tools.ietf.org/html/rfc7432) - [RFC 8365](https://tools.ietf.org/html/rfc8365) diff --git a/doc/vxlan/Overlay ECMP with BFD.md b/doc/vxlan/Overlay ECMP with BFD.md index 28ab66ba75..073abe9bc3 100644 --- a/doc/vxlan/Overlay ECMP with BFD.md +++ b/doc/vxlan/Overlay ECMP with BFD.md @@ -41,7 +41,7 @@ | 1.6 | 04/23/2022 | Storm Liang | Update 2.6 BGP secion & add Test plan for BGP | # About this Manual -This document provides general information about the Vxlan Overlay ECMP feature implementation in SONiC with BFD support. This is an extension to the existing VNET Vxlan support as defined in the [Vxlan HLD](https://github.com/Azure/SONiC/blob/master/doc/vxlan/Vxlan_hld.md) +This document provides general information about the Vxlan Overlay ECMP feature implementation in SONiC with BFD support. This is an extension to the existing VNET Vxlan support as defined in the [Vxlan HLD](https://github.com/sonic-net/SONiC/blob/master/doc/vxlan/Vxlan_hld.md) # Definitions/Abbreviation @@ -61,7 +61,7 @@ This document provides general information about the Vxlan Overlay ECMP feature Below diagram captures the use-case. In this, ToR is a Tier0 device and Leaf is a Tier1 device. Vxlan tunnel is established from Leaf (Tier1) to a VTEP endpoint. ToR (Tier0), Spine (Tier3) are transit devices. -![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/OverlayEcmp_UseCase.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/OverlayEcmp_UseCase.png) ### Packet flow @@ -172,7 +172,7 @@ PROFILE = STRING ; profile name to be applie Overlay routes can be programmed via RestAPI or gNMI/gRPC interface which is not described in this document. A highlevel module interaction is shown below -![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/OverlayEcmp_ModuleInteraction.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/OverlayEcmp_ModuleInteraction.png) ## 2.4 Orchestration Agent Following orchagents shall be modified. @@ -215,7 +215,7 @@ VNET_ROUTE_TUNNEL_TABLE can provide monitoring endpoint IPs which can be differe ### Bfd HW offload -This design requires endpoint health monitoring by setting BFD sessions via HW offload. Details of BFD orchagent and HW offloading is captured in this [document](https://github.com/Azure/SONiC/blob/master/doc/bfd/BFD%20HW%20Offload%20HLD.md) +This design requires endpoint health monitoring by setting BFD sessions via HW offload. Details of BFD orchagent and HW offloading is captured in this [document](https://github.com/sonic-net/SONiC/blob/master/doc/bfd/BFD%20HW%20Offload%20HLD.md) ## 2.5 Monitoring and Health diff --git a/doc/vxlan/Vxlan_hld.md b/doc/vxlan/Vxlan_hld.md index a1942c3c3d..508ae43545 100644 --- a/doc/vxlan/Vxlan_hld.md +++ b/doc/vxlan/Vxlan_hld.md @@ -222,7 +222,7 @@ key = NEIGH_TABLE:name:ip_address ; Vnet nei family = IPv4/IPv6 ; Address family ``` -Please refer to the [schema](https://github.com/Azure/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. +Please refer to the [schema](https://github.com/sonic-net/sonic-swss/blob/master/doc/swss-schema.md) document for details on value annotations. ## 2.2 APP DB Two new tables would be introduced to specify routes and tunnel end points in VNet domain. @@ -300,7 +300,7 @@ PEER_LIST = \*vnet_name ; vnet nam Following orchagents shall be modified. Flow diagrams are captured in a later section. -![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_orch.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_orch.png) ### VxlanOrch This is the major subsystem for Vxlan that handles configuration request. Vxlanorch creates the tunnel and attaches encap and decap mappers. Seperate tunnels are created for L2 Vxlan and L3 Vxlan and can attach different VLAN/VNI or VRF/VNI to respective tunnel. @@ -327,7 +327,7 @@ Following orchagents shall be modified. Flow diagrams are captured in a later se The overall data flow diagram is captured below for all TABLE updates. - ![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_data_flow.png) + ![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_data_flow.png) ## 2.4 SAI @@ -404,13 +404,13 @@ Commands: # 3 Flows ## 3.1 Vxlan VNet peering -![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_cntrl_flow_1.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_cntrl_flow_1.png) -![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_cntrl_flow_2.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_cntrl_flow_2.png) -![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_route_delete.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_route_delete.png) -![](https://github.com/Azure/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_vnet_delete.png) +![](https://github.com/sonic-net/SONiC/blob/master/images/vxlan_hld/vnet_vxlan_vnet_delete.png) ## Layer 2 Vxlan TBD diff --git a/doc/warm-reboot/code_implementation.md b/doc/warm-reboot/code_implementation.md index 4bd451d284..f1e3ed2689 100644 --- a/doc/warm-reboot/code_implementation.md +++ b/doc/warm-reboot/code_implementation.md @@ -203,19 +203,19 @@ jipan@sonic-build:~/igbpatch/vs/sonic-buildimage/src/sonic-swss/tests$ ``` # Separate syncd and swss services, and warm start configDB support -https://github.com/Azure/sonic-buildimage/compare/master...jipanyang:warm-reboot +https://github.com/sonic-net/sonic-buildimage/compare/master...jipanyang:warm-reboot # swss-flushdb script support -https://github.com/Azure/sonic-utilities/compare/master...jipanyang:swss-warm-restart +https://github.com/sonic-net/sonic-utilities/compare/master...jipanyang:swss-warm-restart # swss data restore -https://github.com/Azure/sonic-swss/compare/master...jipanyang:idempotent +https://github.com/sonic-net/sonic-swss/compare/master...jipanyang:idempotent # RedisClient hmset and hgetallordered library support. -https://github.com/Azure/sonic-swss-common/compare/master...jipanyang:idempotent +https://github.com/sonic-net/sonic-swss-common/compare/master...jipanyang:idempotent # libsari redis API idempotency support -https://github.com/Azure/sonic-sairedis/compare/master...jipanyang:idempotent +https://github.com/sonic-net/sonic-sairedis/compare/master...jipanyang:idempotent diff --git a/doc/warm-reboot/open_issues.md b/doc/warm-reboot/open_issues.md index f5452ea5e3..21cb7c946e 100644 --- a/doc/warm-reboot/open_issues.md +++ b/doc/warm-reboot/open_issues.md @@ -92,9 +92,9 @@ Both approaches have been under development and testing. Current status: ## Idempotent libsairedis API ### Design doc: -[SONiC libsairedis API idempotence support](https://github.com/Azure/SONiC/blob/master/doc/warm-reboot/sai_redis_api_idempotence.md) +[SONiC libsairedis API idempotence support](https://github.com/sonic-net/SONiC/blob/master/doc/warm-reboot/sai_redis_api_idempotence.md) ### Draft code changes: -[libsairedis code changes](https://github.com/Azure/sonic-sairedis/compare/master...jipanyang:idempotent) +[libsairedis code changes](https://github.com/sonic-net/sonic-sairedis/compare/master...jipanyang:idempotent) ### Current status: A series of virtual switch test cases have been implemented, and end to end integration testing as to swss docker warm restart/upgrade have been done based on this solution. @@ -107,7 +107,7 @@ It is desired to be able to switch the feature on and off with one simple comman ### Code change: This file contains major part of the implementation (not complete): -[syncd_applyview.cpp](https://github.com/Azure/sonic-sairedis/blob/d54977f297301f972e2839d526d8130a5f66e893/syncd/syncd_applyview.cpp) +[syncd_applyview.cpp](https://github.com/sonic-net/sonic-sairedis/blob/d54977f297301f972e2839d526d8130a5f66e893/syncd/syncd_applyview.cpp) ### Design doc: Not available yet. diff --git a/doc/warm-reboot/system-warmboot.md b/doc/warm-reboot/system-warmboot.md index ef4ed76b9f..c401b637f6 100644 --- a/doc/warm-reboot/system-warmboot.md +++ b/doc/warm-reboot/system-warmboot.md @@ -74,13 +74,13 @@ Assumptions: 2. Focus on whole system reboot, in future will extend it to container level warm restart 3. Focus on one image warm reboot, and version upgrading warm reboot. No version downgrading warm reboot. -Structure of testbed: [design doc](https://github.com/Azure/sonic-mgmt/blob/master/docs/testbed/README.testbed.Overview.md#sonic-testbed-overview) +Structure of testbed: [design doc](https://github.com/sonic-net/sonic-mgmt/blob/master/docs/testbed/README.testbed.Overview.md#sonic-testbed-overview) ![Physical topology](img/testbed.png) ![Testbed server](img/testbed-server.png) Architect: - - Both warm-reboot and fast-reboot are written in ansible playbook [advanced-reboot.yml](https://github.com/Azure/sonic-mgmt/blob/master/ansible/roles/test/tasks/advanced-reboot.yml) - - The playbook will deploy a master python script [advanced-reboot.py](https://github.com/Azure/sonic-mgmt/blob/master/ansible/roles/test/files/ptftests/advanced-reboot.py) to PTF docker container and all the steps are running there + - Both warm-reboot and fast-reboot are written in ansible playbook [advanced-reboot.yml](https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/roles/test/tasks/advanced-reboot.yml) + - The playbook will deploy a master python script [advanced-reboot.py](https://github.com/sonic-net/sonic-mgmt/blob/master/ansible/roles/test/files/ptftests/advanced-reboot.py) to PTF docker container and all the steps are running there - The master python script will - ssh into DUT to execute reboot command - ssh into Arist EOS VM to observe and operate port, port channel and BGP sessions diff --git a/doc/xrcvd/OIDsforSensorandTransciver.MD b/doc/xrcvd/OIDsforSensorandTransciver.MD index 224ecec678..c7773f8cf6 100644 --- a/doc/xrcvd/OIDsforSensorandTransciver.MD +++ b/doc/xrcvd/OIDsforSensorandTransciver.MD @@ -58,7 +58,7 @@ As shown in the following diagram, we need to collect sensor and transceiver inf | 1.3.6.1.2.1.47.1.1.1.1.12.index | entPhysicalMfgName | Vendor Name in CLI or sfputil | FINISAR CORP | | 1.3.6.1.2.1.47.1.1.1.1.13.index | entPhysicalModelName | Vendor PN in CLI or sfputil| FCBN410QD3C02 | -ifindex is the ifindex in https://github.com/Azure/sonic-py-swsssdk/blob/master/src/swsssdk/port_util.py#L19 +ifindex is the ifindex in https://github.com/sonic-net/sonic-py-swsssdk/blob/master/src/swsssdk/port_util.py#L19 | Interface | Proposed index to use | | --- | --- | diff --git a/doc/xrcvd/transceiver-monitor-hld.md b/doc/xrcvd/transceiver-monitor-hld.md index b5ea73097f..d35d28aa6c 100644 --- a/doc/xrcvd/transceiver-monitor-hld.md +++ b/doc/xrcvd/transceiver-monitor-hld.md @@ -11,7 +11,7 @@ ## About This Manual ## This document is intend to provide general information about the Transceiver and Sensor Monitoring implementation. -The requirement is described in [Sensor and Transceiver Info Monitoring Requirement.](https://github.com/Azure/SONiC/blob/master/doc/xrcvd/OIDsforSensorandTransciver.MD) +The requirement is described in [Sensor and Transceiver Info Monitoring Requirement.](https://github.com/sonic-net/SONiC/blob/master/doc/xrcvd/OIDsforSensorandTransciver.MD) ## 1. Xcvrd design ## @@ -237,7 +237,7 @@ A thread will be started to periodically refresh the DOM sensor information. Detailed flow as showed in below chart: -![](https://github.com/Azure/SONiC/blob/d1159ca728112f10319fa47de4df89c445a27efc/images/transceiver_monitoring_hld/xcvrd_flow.svg) +![](https://github.com/sonic-net/SONiC/blob/d1159ca728112f10319fa47de4df89c445a27efc/images/transceiver_monitoring_hld/xcvrd_flow.svg) #### 1.4.1 State machine of sfp\_state\_update\_task process #### @@ -368,7 +368,7 @@ Another entPhySensorTable which is defined in [Entity Sensor MIB(RFC3433)](https | 1.3.6.1.2.1.99.1.1.1.4.index | entPhySensorValue | Same as above | 7998 | | 1.3.6.1.2.1.47.1.1.1.1.2.index | entPhysicalDescr | Show interfaces alias | DOM RX Power Sensor for DOM RX Power Sensor for Ethernet29/1 | -More detailed information about new table and new OIDs are described in [Sensor and Transceiver Info Monitoring Requirement](https://github.com/Azure/SONiC/blob/master/doc/xrcvd/OIDsforSensorandTransciver.MD#transceiver-requirements-entity-mib). +More detailed information about new table and new OIDs are described in [Sensor and Transceiver Info Monitoring Requirement](https://github.com/sonic-net/SONiC/blob/master/doc/xrcvd/OIDsforSensorandTransciver.MD#transceiver-requirements-entity-mib). ## 3. CLI change ## diff --git a/generate_sonic_image_links.sh b/generate_sonic_image_links.sh index 106d32bdfa..e43f4663f6 100644 --- a/generate_sonic_image_links.sh +++ b/generate_sonic_image_links.sh @@ -97,91 +97,91 @@ do echo "\"sonic-broadcom.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_BRCM}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-broadcom.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_BRCM}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_BRCM_2}"..."${COMMIT_BRCM_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_BRCM_2}"..."${COMMIT_BRCM_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_BRCM}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_BRCM_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-aboot-broadcom.swi\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_BRCM}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-aboot-broadcom.swi/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_BRCM}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_BRCM_2}"..."${COMMIT_BRCM_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_BRCM_2}"..."${COMMIT_BRCM_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_BRCM}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_BRCM_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-mellanox.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_MLNX}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-mellanox.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_MLNX}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_MLNX_2}"..."${COMMIT_MLNX_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_MLNX_2}"..."${COMMIT_MLNX_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_MLNX}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_MLNX_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-vs.img.gz\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_VS}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-vs.img.gz/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_VS}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_VS_2}"..."${COMMIT_VS_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_VS_2}"..."${COMMIT_VS_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_VS}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_VS_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-innovium.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_INNO}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-innovium.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_INNO}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_INNO_2}"..."${COMMIT_INNO_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_INNO_2}"..."${COMMIT_INNO_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_INNO}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_INNO_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-innovium-dbg.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_INNO}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-innovium-dbg.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_INNO}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_INNO_2}"..."${COMMIT_INNO_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_INNO_2}"..."${COMMIT_INNO_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_INNO}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_INNO_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-barefoot.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_BFT}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-barefoot.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_BFT}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_BFT_2}"..."${COMMIT_BFT_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_BFT_2}"..."${COMMIT_BFT_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_BFT}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_BFT_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-centec.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_CTC}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-centec.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_CTC}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_CTC_2}"..."${COMMIT_CTC_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_CTC_2}"..."${COMMIT_CTC_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_CTC}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_CTC_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-centec-arm64.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_CTC64}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-centec-arm64.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_CTC64}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_CTC64_2}"..."${COMMIT_CTC64_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_CTC64_2}"..."${COMMIT_CTC64_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_CTC64}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_CTC64_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-generic.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_GRC}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-generic.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_GRC}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_GRC_2}"..."${COMMIT_GRC_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_GRC_2}"..."${COMMIT_GRC_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_GRC}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_GRC_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-generic-dbg.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_GRC}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-generic-dbg.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_GRC}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_GRC_2}"..."${COMMIT_GRC_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_GRC_2}"..."${COMMIT_GRC_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_GRC}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_GRC_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-marvell-armhf.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_MRV}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-marvell-armhf.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_MRV}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_MRV_2}"..."${COMMIT_MRV_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_MRV_2}"..."${COMMIT_MRV_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_MRV}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_MRV_TS}\"" >> sonic_image_links.json echo " }," >> sonic_image_links.json echo "\"sonic-nephos.bin\": {" >> sonic_image_links.json echo " \"url\": \"$(echo "${ARTF_NPH}" | sed 's/format=zip/format=file\&subpath=\/target\/sonic-nephos.bin/')\"," >> sonic_image_links.json echo " \"build-url\": \"https://dev.azure.com/mssonic/build/_build/results?buildId=${BUILD_NPH}&view=results\"," >> sonic_image_links.json - echo " \"diff\": \"https://github.com/Azure/sonic-buildimage/compare/"${COMMIT_NPH_2}"..."${COMMIT_NPH_1}"\"," >> sonic_image_links.json + echo " \"diff\": \"https://github.com/sonic-net/sonic-buildimage/compare/"${COMMIT_NPH_2}"..."${COMMIT_NPH_1}"\"," >> sonic_image_links.json echo " \"build\": \"${BUILD_NPH}\"," >> sonic_image_links.json echo " \"date\": \"${BUILD_NPH_TS}\"" >> sonic_image_links.json echo " }" >> sonic_image_links.json diff --git a/index.html b/index.html index 2c088d2205..7eb0115741 100644 --- a/index.html +++ b/index.html @@ -71,30 +71,30 @@ SONiC
  • Users
  • Developers
    • @@ -105,11 +105,11 @@
  • Community Meeting Videos
  • Community Meeting Minutes
  • Workgroups
    • -
  • How To Contribute
    • -
  • Governance
    • -
  • SONiC Foundation Technical Charter
    • +
  • How To Contribute
    • +
  • Governance
    • +
  • SONiC Foundation Technical Charter
  • Security Process
    • -
  • License & Logo
    • +
  • License & Logo
    • @@ -146,12 +146,12 @@

    SONiC

    Software for Open Networking in the Cloud

    - +

    - Wiki + Wiki        - GitHub + GitHub        Linux Foundation

    @@ -272,7 +272,7 @@

    Rapidly Growing Ecosystem

    Presentations & Demos

    Software for Open Networking in the Cloud (SONiC) Moves to the Linux Foundation

    -

    SONiC Community Meetings

    +

    SONiC Community Meetings

    More Presentations

    OCP Virtual Summit 2020 SONiC Demos

    diff --git a/menu.html b/menu.html index 36dfeb92c8..f5b9d0f5da 100644 --- a/menu.html +++ b/menu.html @@ -21,30 +21,30 @@ SONiC
  • Users
  • Developers
  • @@ -54,9 +54,9 @@
  • Community Meeting Videos
  • Community Meeting Minutes
  • Workgroups
    • -
  • How To Contribute
    • -
  • Governance
    • -
  • SONiC Foundation Technical Charter
    • +
  • How To Contribute
    • +
  • Governance
    • +
  • SONiC Foundation Technical Charter
  • Security Process
  • License & Logo
    • diff --git a/pdf/newsletters/SONiC_newsletter_2019_10.html b/pdf/newsletters/SONiC_newsletter_2019_10.html index 17f0361c18..3afd7d7e32 100644 --- a/pdf/newsletters/SONiC_newsletter_2019_10.html +++ b/pdf/newsletters/SONiC_newsletter_2019_10.html @@ -296,7 +296,7 @@

    - + @@ -313,7 +313,7 @@

    - + @@ -330,7 +330,7 @@

    - + @@ -346,7 +346,7 @@

    - + @@ -362,7 +362,7 @@

    - + @@ -379,7 +379,7 @@

    - + @@ -395,7 +395,7 @@

    - + @@ -412,7 +412,7 @@

    - + diff --git a/pdf/newsletters/SONiC_newsletter_2019_12.html b/pdf/newsletters/SONiC_newsletter_2019_12.html index 838063db63..a27901e815 100644 --- a/pdf/newsletters/SONiC_newsletter_2019_12.html +++ b/pdf/newsletters/SONiC_newsletter_2019_12.html @@ -139,7 +139,7 @@ Features Merged - Build time improvements, Configurable drop counters, Egress mirroring and ACL action support check via SAI, HW resource monitor,L3 perf enhancement, Log analyzer to pytest, Management Framework, Management VRF, Platform test, sFlow, SSD diagnostic tolling and Sub-port support have been merged.
    Pending Features - MLAG,VRF and ZTP.

    -

    For current status of all features

    +

    For current status of all features

    @@ -165,7 +165,7 @@ 05 NOV 2019

    - +    Support for DPKG local caching   

    @@ -175,7 +175,7 @@ 12 NOV 2019

    - +   DPKG Caching Framework - BRCM     @@ -186,7 +186,7 @@ 19 NOV 2019

    - +   Thermal control design   @@ -208,7 +208,7 @@ 03 DEC 2019

    - +   Release tracking status      diff --git a/pdf/newsletters/SONiC_newsletter_2020_06.html b/pdf/newsletters/SONiC_newsletter_2020_06.html index 6e1c8454a6..65973e2529 100644 --- a/pdf/newsletters/SONiC_newsletter_2020_06.html +++ b/pdf/newsletters/SONiC_newsletter_2020_06.html @@ -110,7 +110,7 @@ Industry Demo Collection

    - + @@ -165,11 +165,11 @@

    -

    SONiC 202006 Release:

    Community has been working hard to complete the features planned in the     Roadmap which is being tracked in Release Tracking. A branch will be pulled by end of June 2020 with the completed features and the incomplete features shall catch the next train. +

    SONiC 202006 Release:

    Community has been working hard to complete the features planned in the Roadmap which is being tracked in Release Tracking. A branch will be pulled by end of June 2020 with the completed features and the incomplete features shall catch the next train.

    Features Planned - BFD SW 100ms interval from FRR, Build Improvements, Consistent ECMP support, Container warm restart, CoPP config/management, D-Bus to Host Communications, Debian 10 upgrade - base image, driver & dockers, Dynamic headroom calculation, Dynamic port breakout, Egress shaping, EVPN/VXLAN, FRR BGP NBI, Fw utils extension, Gearbox, L2 functional and performance enhancements, Management framework (Phase 2), Media enhancements, PDDF advance to SONiC Platform 2.0, BMC, PDK - Platform development environment, & driver development framework, Port mirroring, Pytest 100% moved from ansible to Pytest, RADIUS AAA, SPytest, System health & system LED, etc.,

    -

    SONiC 201911 Release:

    Special thanks to all community members who contributed to the Previous Release 201911. +

    SONiC 201911 Release:

    Special thanks to all community members who contributed to the Previous Release 201911.

    @@ -202,7 +202,7 @@ 28 Jan 2020

    - + DBUS HLD

    @@ -212,7 +212,7 @@ 04 Feb 2020

    - + Debian 10 buster HLD

    @@ -221,7 +221,7 @@ 11 Feb 2020

    - + SONiC Line card Hot Swap HLD

    @@ -239,7 +239,7 @@ 10 Mar 2020

    - + Monitoring, Auto-Mitigating Unhealthy Containers

    @@ -248,7 +248,7 @@ 17 Mar 2020

    - + Add QoS Scheduler and Shaper HLD

    @@ -257,7 +257,7 @@ 24 Mar 2020

    - + SONiC Port mirroring HLD

    @@ -266,7 +266,7 @@ 31 Mar 2020

    - + System Health and System LED Monitoring

    @@ -275,7 +275,7 @@ 07 Apr 2020

    - + AAA HLD

    @@ -284,7 +284,7 @@ 14 Apr 2020

    - + D-Bus Host to Container Communications HLD

    @@ -293,7 +293,7 @@ 21 Apr 2020

    - + Management Framework-Phase II HLD

    @@ -302,7 +302,7 @@ 28 Apr 2020

    - + Fine grained ECMP HLD

    @@ -311,7 +311,7 @@ 05 May 2020

    - + MCLAG Enhancements HLD

    @@ -320,7 +320,7 @@ 12 May 2020

    - + SONiC Configuration Replace HLD

    @@ -329,7 +329,7 @@ 19 May 2020

    - + Dynamic buffer calculation HLD

    @@ -338,7 +338,7 @@ 26 May 2020

    - + EVPN VXLAN HLD

    @@ -347,7 +347,7 @@ 02 June 2020

    - + BGP Unnumbered HLD

    @@ -386,4 +386,4 @@ - \ No newline at end of file + diff --git a/pdf/newsletters/SONiC_newsletter_2020_09.html b/pdf/newsletters/SONiC_newsletter_2020_09.html index 019a9698c2..efc3601e26 100644 --- a/pdf/newsletters/SONiC_newsletter_2020_09.html +++ b/pdf/newsletters/SONiC_newsletter_2020_09.html @@ -135,11 +135,11 @@

    -

    SONiC 202012 Release:
    Community is currently occupied with the features planned in the Roadmap which is being tracked in Release Tracking. A branch will be pulled by end of December 2020 with the completed features. +

    SONiC 202012 Release:
    Community is currently occupied with the features planned in the Roadmap which is being tracked in Release Tracking. A branch will be pulled by end of December 2020 with the completed features.

    Features Planned - AAA improvement,ACL enhancements: Policing, DHCP/PCP remark,BFD SW 100ms interval from FRR,Consistent ECMP support,Console Support for SONiC (Hardware,SSH forwarding),Container warm restart,CoPP Config/Management, Uniform Firmware upgrade Tool,Distributed VoQ Forwarding,Dynamic headroom calculation,Synchornous SAI APIs,Extending Entphysicaltable MIB table,Extend FW debug info in sysdump,EVPN/VXLAN,Flow-based Services,FRR BGP NBI,Gearbox,IPv6 Link Local and BGP Unnumbered,Kubernetes,L2 Dot1Q tunneling support,L2 functional and performance enhancements,MACSec support in Chassis,Management Framework (Phase 2),MC-LAG (L2),Media Enhancements,Python2->python3,Multi-ASIC,Multi-DB enhancement-Part 2,ONIE FW tools,PDDF advance to SONiC Platform 2.0, BMC,PDK - Platform Development Environment,PDK - Platform Driver Development Framework,RADIUS AAA,SONiC app extension,Support hardware reboot/reload reason (Streaming Telemetry),System health and system LED,Telemetry support for Multi-ASIC,VoQ Chassis Support in SONiC,VXLAN diff tool,VXLAN ping tool. etc.,

    -

    SONiC 202006 Release:
    Special thanks to all community members who contributed to the Previous Release 202006. +

    SONiC 202006 Release:
    Special thanks to all community members who contributed to the Previous Release 202006.

    @@ -164,12 +164,12 @@ - Members are requested to follow the New Design Document Template for all design documents + Members are requested to follow the New Design Document Template for all design documents 07 Jul 2020

    - + 202006 Release update & 202012 Release planning

    @@ -178,7 +178,7 @@ 14 Jul 2020

    - + 202006 CLI configuration guide updates

    @@ -187,7 +187,7 @@ 21 Jul 2020

    - + Multi-ASIC HLD

    @@ -196,7 +196,7 @@ 28 Jul 2020

    - + Code Coverage Rate HLD

    @@ -205,7 +205,7 @@ 04 Aug 2020

    - + 202012 Release Planning

    @@ -214,7 +214,7 @@ 11 Aug 2020

    - + SONiC Entity MIB Extension HLD

    @@ -223,7 +223,7 @@ 18 Aug 2020

    - + Distributed forwarding in a VOQ architecture HLD

    @@ -232,7 +232,7 @@ 25 Aug 2020

    - + Code refactoring to improve service container warm resart

    @@ -241,7 +241,7 @@ 01 Sep 2020

    - + SONiC-Console-Switch-High-Level-Design

    @@ -250,7 +250,7 @@ 08 Sep 2020

    - + VoQ HLD

    @@ -259,7 +259,7 @@ 22 Sep 2020

    - + Kubernetes-Support for SONiC

    @@ -268,7 +268,7 @@ 29 Sep 2020

    - + SONiC FW utility HLD

    @@ -283,4 +283,4 @@ - \ No newline at end of file + diff --git a/pdf/newsletters/SONiC_newsletter_2020_12.html b/pdf/newsletters/SONiC_newsletter_2020_12.html index e95be8e304..e89f100edf 100644 --- a/pdf/newsletters/SONiC_newsletter_2020_12.html +++ b/pdf/newsletters/SONiC_newsletter_2020_12.html @@ -110,7 +110,7 @@

    It has been a new normal year 2020 for us ! Appreciate all the community members for the excellent achievement for making two releases in the year amidst the pandemic.

    Contributions from the community has doubled in the year 2020, when compared to 2019. 50+ new features have been added in the year 2020 against 27 new features in 2019. Similarly number of Pull Request increased from 2480 to 4000+ PRs from 250+ active contributors in the current year. 10 new platforms have been added in the year to the SONiC portfolio. 13 new partners have joined hands with the SONiC community in this year.

    -

    Successfully participated in the OCP Virtual Submit, NetDev Virtual Conference, SONiC Eco-system Conference, OCP Tech Week and OCP China Day. Have demonstrated the SONiC capabilities to the world through an Industry Demo. +

    Successfully participated in the OCP Virtual Submit, NetDev Virtual Conference, SONiC Eco-system Conference, OCP Tech Week and OCP China Day. Have demonstrated the SONiC capabilities to the world through an Industry Demo.

    Created 5 new workgroups to have a focused feature specific community discussions and contributions, recent being Kubernetes & MPLS Workgroup!

    Wishing all our community members a wonderful New year 2021 & looking forward for another successful year ahead !

    More Community News: @@ -133,7 +133,7 @@

    -

    SONiC 202012 Release:

    Community is currently occupied with the features planned in the Roadmap which is being tracked in Release Tracking. A branch will be pulled in couple of days with the completed features. +

    SONiC 202012 Release:

    Community is currently occupied with the features planned in the Roadmap which is being tracked in Release Tracking. A branch will be pulled in couple of days with the completed features.

    Features Planned - Consistent ECMP support(fine grain ECMP), Container warm restart (BGP/TeamD/SWSS/SyncD), CoPP Config/Management, Console support for SONiC(Hardware), Console support for SONiC(ssh forwarding), Dynamic headroom calculation,Enable synchronous SAI APIs for error handling, EVPN/VXLAN, SONiC entity MIB extensions, FRR BGP NBI, Gearbox, Kubernetes (docker to be controlled by Kubernetes), MACSec support in chassis, Management Framework (Phase 2), MC-LAG (L2), Merge common lib for C++ and python (SWSS common lib), Move from Python2->python3, Multi-ASIC 202006, Multi-DB enhancement-Part 2, ONIE FW tools(Incl. CPLD, BIOS, SSD, Firmware upgrade[Uniform Tool]), PDDF advance to SONiC Platform 2.0, BMC, PDK - Platform Development Environment, RADIUS AAA, SONiC app extension(w/o orchagent), Support hardware reboot/reload reason (Streaming Telemetry), System health and system LED, PCIe Monitoring, Distributed forwarding in a VOQ architecture, Distributed VOQ architecture HLD, Platform Monitoring for Chassis systems, Routing/BGP for Chassis, Fabric Port support for SONiC, LAG Support for Chassis, Chassis infrastructure, T2 topologies and sample Testcases converted, Inband port support for Chassis, Everflow Support etc.,

    @@ -165,7 +165,7 @@ 06 Oct 2020

    - + SONiC TPID Configuration Support

    @@ -183,7 +183,7 @@ 20 Oct 2020

    - + Release 202012 Discussion

    @@ -192,7 +192,7 @@ 27 Oct 2020

    - + MACSEC Design

    @@ -201,7 +201,7 @@ 03 Nov 2020

    - + SONiC Application Extension

    @@ -219,7 +219,7 @@ 24 Nov 2020

    - + SONiC Application Extension

    @@ -228,7 +228,7 @@ 08 Dec 2020

    - + PMON enhancements for Chassis HLD

    @@ -237,7 +237,7 @@ 15 Dec 2020

    - + Release 202012 Discussion

    @@ -249,4 +249,4 @@ - \ No newline at end of file + diff --git a/pdf/newsletters/SONiC_newsletter_2021_03.html b/pdf/newsletters/SONiC_newsletter_2021_03.html index f589341bf2..1386164317 100644 --- a/pdf/newsletters/SONiC_newsletter_2021_03.html +++ b/pdf/newsletters/SONiC_newsletter_2021_03.html @@ -99,7 +99,7 @@

    It has been a good start for the year 2021 to all of us ! Appreciate all the community members for their ongoing contribution towards the current release.
    -

    Community was able to come up with release notes for 202012 release and SAI version 1.7.1

    +

    Community was able to come up with release notes for 202012 release and SAI version 1.7.1

    Created SONiC Yang Subgroup to have a focused specific community discussions and contributions.

    Wishing all our community members yet another successful release ahead !

    More Community News: @@ -120,7 +120,7 @@

    -

    SONiC 202106 Release:

    Community is currently occupied with the features planned in the Roadmap which is being tracked in Release Tracking. A branch will be pulled by end of June 2021 with the completed features. +

    SONiC 202106 Release:

    Community is currently occupied with the features planned in the Roadmap which is being tracked in Release Tracking. A branch will be pulled by end of June 2021 with the completed features.

    Features Planned - Telemetry for Multi-ASIC, Dynamic policy based hashing, DHCP IPv6 relay, App extension with Orchagent/SWSS,CLI generation tool & warmboot awareness, FRR running configuration to tech support, Enable/Disable auto negotiation & speed setting with number of lanes, TPID config support, Kubernetes enhancements, Deprecating Python2 platform daemons, MACSec support in Chassis, MACSEC enhancement: primary & fallback case, Error handling (swss), 100% SONiC YANG model, Debian11 branch, (Test) Upgrade to Python3 compliance, (Test) Ansible 2.10 upgrade, (Test) Testbed v2, Testcase/Testbed Infrastructure, SONiC fanout support, Link Training, Inband mgmt VRF, Sample Rate on mirror, Sflow with remote collector, V4/V6 L3 ACL optimization, SRv6 support, SONiC for MPLS Dataplane, Route scalability with multiple next-hops, IS-IS in the dataplane, Class-based forwarding, IPv6 Link Local and BGP Unnumbered, MC-LAG (L2), RPVST+, Storm Control , RADIUS AAA, Kernel programming performance enhancement, Static Anycast Gateway, BFD (SW - 100ms interval from FRR), STP/PVST, L2 functional and performance enhancements, Thresholds (statistics), PDK - Platform Development Environment, UI Content (UMF client), Broadcom silicon common config, DPB Reconcile, Dynamic CoPP reconcile, Mgmt FW Phase 3, Routed sub-interface reconcile, MultiDB reconcile, CPU Queues, ACL enhancements: Policing, DHCP/PCP remark, L2 ARP Refresh, Gearbox part 2, libebpf support & usage, PCIe Monitoring etc.,
    @@ -162,7 +162,7 @@ 19 Jan 2021

    - + Port auto negotiation HLD

    @@ -171,7 +171,7 @@ 02 Feb 2021

    - + Next hop group split HLD

    @@ -189,7 +189,7 @@ 16 Feb 2021

    - + cpu queue stats

    @@ -198,7 +198,7 @@ 23 Feb 2021

    - + SONiC Yang Model and related libraries

    @@ -207,7 +207,7 @@ 02 Mar 2021

    - + Weighted ECMP HLD

    @@ -216,7 +216,7 @@ 09 Mar 2021

    - + MPLS HLD initial revision

    @@ -225,7 +225,7 @@ 16 Mar 2021

    - + Inband Mgmt via mgmt VRF

    @@ -234,7 +234,7 @@ 23 Mar 2021

    - + Rollback for SONiC

    @@ -255,4 +255,4 @@ -

    -

    SONiC 202106 Release:

    Community is currently occupied with the features planned in the Roadmap which is being tracked in Release Tracking. A branch will be pulled by end of June 2021 with the completed features and the incomplete features shall catch the next train. +

    SONiC 202106 Release:

    Community is currently occupied with the features planned in the Roadmap which is being tracked in Release Tracking. A branch will be pulled by end of June 2021 with the completed features and the incomplete features shall catch the next train.

    Features Planned - Telemetry for Multi-ASIC, Dynamic port breakout, Dynamic policy based hashing, DHCP relay IPv6 support, App extension CLI generation tool, App extension with warmboot awareness, Add FRR running configuration to tech support, Enable/Disable auto negotiation and speed setting with number of lanes, TPID config support, Error handling (swss), SONiC YANG model, Testcase/Testbed Infrastructure, SONiC fanout support, Inband mgmt VRF, SRv6 support, SONiC for MPLS Dataplane, Better route scalability with multiple next-hops, IPv6 Link Local and BGP Unnumbered, MC-LAG (L2), RADIUS AAA, PDK - Platform Development Environment, Broadcom silicon common config, PCIe Monitoring, Event-mgmt infra, Klish CLI for show-tech support, Debug dump utility, Enhanced xcrvd SFP error flow, Entity sensor MIB extension. etc.,
    @@ -155,7 +155,7 @@ 13 Apr 2021

    - + Policy Based Hashing HLD

    @@ -164,7 +164,7 @@ 20 Apr 2021

    - + Event and Alarm Framework HLD

    @@ -173,7 +173,7 @@ 27 Apr 2021

    - + Generalizing config.bcm support for BRCM silicons

    @@ -191,7 +191,7 @@ 18 May 2021

    - + Debug dump utility HLD

    @@ -200,7 +200,7 @@ 01 Jun 2021

    - + SAI Failure Handling

    @@ -231,4 +231,4 @@ -

    -

    SONiC 202111 Release:
    Thanks to all the contributors in making one more successful release 202111. A branch has been created with the completed features given below.
    ACL orch redesign, App extension CLI generation tool, Automatic tech support & core dump creation, Better route scalability with multiple next-hops, Class-Based Forwarding, CLI level authorization, DHCP support IPv6, Dynamic Policy Based Hashing, Dynamic port breakout, EXP to TC QoS maps, EVPN VXLAN for platforms using P2MP tunnel, Handle port config change on fly, Host interface trap counter, L2 functional & performance enhancements, Debian11, Debug dump utility, Overlay ECMP, PDK - Platform Development Environment, PINS (P4 Integrated Network Stack), Reclaim reserved buffer for unused ports, Routed sub-interface naming convention, SONiC for MPLS Dataplane, SRv6 support (Cntd), Support for passing IS-IS, LDP & MicroBFD packets to CPU, Upgrade SONiC init flow & VXLAN src port configuration. The list of features and the related pull requests are tracked in the Release Tracking page. +

    SONiC 202111 Release:
    Thanks to all the contributors in making one more successful release 202111. A branch has been created with the completed features given below.
    ACL orch redesign, App extension CLI generation tool, Automatic tech support & core dump creation, Better route scalability with multiple next-hops, Class-Based Forwarding, CLI level authorization, DHCP support IPv6, Dynamic Policy Based Hashing, Dynamic port breakout, EXP to TC QoS maps, EVPN VXLAN for platforms using P2MP tunnel, Handle port config change on fly, Host interface trap counter, L2 functional & performance enhancements, Debian11, Debug dump utility, Overlay ECMP, PDK - Platform Development Environment, PINS (P4 Integrated Network Stack), Reclaim reserved buffer for unused ports, Routed sub-interface naming convention, SONiC for MPLS Dataplane, SRv6 support (Cntd), Support for passing IS-IS, LDP & MicroBFD packets to CPU, Upgrade SONiC init flow & VXLAN src port configuration. The list of features and the related pull requests are tracked in the Release Tracking page.

    -

    SONiC 202205 Release:
    Roadmap page contains the list of features that are planned for the 202205 release. Welcoming more and more contributors for design meetings and for reviewing the design and code for yet another sucessful release ! +

    SONiC 202205 Release:
    Roadmap page contains the list of features that are planned for the 202205 release. Welcoming more and more contributors for design meetings and for reviewing the design and code for yet another sucessful release !

    @@ -186,7 +186,7 @@ 20 July

    - + DHCPv6 Relay agent

    @@ -204,7 +204,7 @@ 03 Aug

    - + Class Based Forwarding HLD

    @@ -213,7 +213,7 @@ 10 Aug

    - + SONiC_SFP_refactoring HLD

    @@ -231,7 +231,7 @@ 24 Aug

    - + SAG - Static Anycast Gateway

    @@ -240,7 +240,7 @@ 31 Aug

    - + Show Running Command Enhancement

    @@ -258,7 +258,7 @@ 14 Sep

    - + ECMP Overlay BFD support

    @@ -352,4 +352,4 @@ - \ No newline at end of file + diff --git a/previous_presentations.html b/previous_presentations.html index 2a1b136675..762eb65146 100644 --- a/previous_presentations.html +++ b/previous_presentations.html @@ -91,10 +91,10 @@

    PREVIOUS PRESENTATIONS

    OCP China 2019 Summit - SONiC Enable Fast Evolution Of Cloud Networking (Microsoft Video)

    OCP China 2019 Summit - Network Innovation - Collaboration With SONiC (Alibaba Video in Chinese)

    OCP Summit 2018 - SONiC Programmability, Extensibility and Beyond

    -

    SONiC Workshop in Beijing 2018 October

    +

    SONiC Workshop in Beijing 2018 October

    SONiC - Enabling Fast Evolution in the Networks

    -

    OCP Summit 2018 and SONiC/SAI Workshop Slides

    -

    OCP Summit 2016 SONiC Presentation Slides

    +

    OCP Summit 2018 and SONiC/SAI Workshop Slides

    +

    OCP Summit 2016 SONiC Presentation Slides

    OCP 2020 Virtual Summit - Panel Discussion - Open Networking and SONiC

    SONiC Video From OCP Summit 2019

    OCP Amsterdam 2019 Regional Summit - Going SONiC Together

    @@ -152,4 +152,4 @@

    PREVIOUS PRESENTATIONS

    - \ No newline at end of file + diff --git a/thermal-control-design.md b/thermal-control-design.md index 31018218d8..f0ca891d9c 100644 --- a/thermal-control-design.md +++ b/thermal-control-design.md @@ -52,7 +52,7 @@ In most case fan is the device to cool down the switch when the temperature is r Fan target speed and speed tolerance was defined, by examining them we can know whether the fan reached at the desired speed. -same as the temperature info, a [table for fan](https://github.com/Azure/SONiC/blob/master/doc/pmon/pmon-enhancement-design.md#153-fan-table) also defined as below: +same as the temperature info, a [table for fan](https://github.com/sonic-net/SONiC/blob/master/doc/pmon/pmon-enhancement-design.md#153-fan-table) also defined as below: ; Defines information for a fan key = FAN_INFO|fan_name ; information for the fan