Merge branch 'sonic-net:master' into master

doc/config-generic-update-rollback/SONiC_Generic_Config_Update_and_Rollback_Design.md

@@ -908,19 +908,19 @@ N/A
 | 14        | Dynamic port breakout as described [here](https://github.com/Azure/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. |
-| 18        | Updating AAA configs. |
-| 19        | Updating DHCP configs. |
+| 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) |
 | 20        | Updating IPv6 configs. |
 | 21        | Updating monitor configs (EverflowAlaysOn). |
 | 22        | Updating BGP speaker configs. |
-| 23        | Updating BGP listener configs. |
-| 24        | Updating Bounce Back Routing configs. |
-| 25        | Updating control-plane ACLs (NTP, SNMP, SSH) configs. |
+| 23        | [Updating BGP listener configs.](https://github.com/Azure/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) |
 | 26        | Updating Ethernet interfaces configs. |
-| 27        | Updating VLAN interfaces configs. |
-| 28        | Updating port-channel interfaces configs. |
-| 29        | Updating loopback 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) |
 | 30        | Updating BGP prefix hijack configs. |
 | 31        | Updating QoS headroom pool and buffer pool size. |
 | 32        | Add/Remove Rack. |

doc/crm/Critical-Resource-Monitoring-High-Level-Design.md

@@ -104,7 +104,7 @@ Monitoring process should periodically poll SAI counters for all required resour
 
 ```"<Date/Time> WARNING <Process name>: THRESHOLD_EXCEEDED for <TH_TYPE> <%> Used count <value> free count <value>"```
 
-```"<Date/Time> NOTICE <Process name>: THRESHOLD_CLEAR for <TH_TYPE> <%> Used count <value> free count <value>"```
+```"<Date/Time> WARNING <Process name>: THRESHOLD_CLEAR for <TH_TYPE> <%> Used count <value> free count <value>"```
 
 ```<TH_TYPE> = <TH_PERCENTAGE, TH_USED, TH_FREE>```
 

doc/hld_template.md

@@ -66,6 +66,7 @@ Paste a preliminary manifest in a JSON format.
 
 This sub-section covers the addition/deletion/modification of CLI changes and YANG model changes needed for the feature in detail. If there is no change in CLI for HLD feature, it should be explicitly mentioned in this section. Note that the CLI changes should ensure downward compatibility with the previous/existing CLI. i.e. Users should be able to save and restore the CLI from previous release even after the new CLI is implemented. 
 This should also explain the CLICK and/or KLISH related configuration/show in detail.
+https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md needs be updated with the corresponding CLI change.
 
 #### Config DB Enhancements  
 
@@ -88,4 +89,4 @@ Example sub-sections for unit test cases and system test cases are given below.
 ### Open/Action items - if any 
 
 
-NOTE: All the sections and sub-sections given above are mandatory in the design document. Users can add additional sections/sub-sections if required.
+NOTE: All the sections and sub-sections given above are mandatory in the design document. Users can add additional sections/sub-sections if required.

doc/pins/p4rt_app_hld.md

@@ -16,6 +16,7 @@ _Rev v0.1_
   * [Response path](#response-path)
 - [APPL DB Schema High-Level Design](#appl-db-schema-high-level-design)
 - [Testing Requirements/Design](#testing-requirements-design)
+- [Configuring P4RT Application](#configuring-p4rt-application)
 - [Open/Action items - if any](#open-action-items---if-any)
 
 ## Revision
@@ -164,6 +165,29 @@ P4RT application introduces new tables that are written to APPL_DB for the table
 
 The P4RT application code will have unit & component tests that together will give >80% code coverage.
 
+## Configuring P4RT Application
+
+The P4RT application is configured at the start-up by reading the P4RT configuration from the CONFIG_DB. If no valid config exists in CONFIG_DB, it uses the default values. The configuration can be added to the CONFIG_DB by being manually added to the config_db.json file. The P4RT container will need to be restarted if the configuration is changed.
+
+Below is an example of adding P4RT configuration to config_db.json. The user can modify this block based on their environment settings. 
+
+```
+"P4RT": {
+  "certs": {
+    "server_crt": "/keys/server_cert.lnk",
+    "server_key": "/keys/server_key.lnk",
+    "ca_crt": "/keys/ca_cert.lnk",
+    "cert_crl_dir": "/keys/crl"
+  },
+  "p4rt_app": {
+    "port": "9559",
+    "use_genetlink": "false",
+    "use_port_ids": "false",
+    "save_forwarding_config_file" : "/etc/sonic/p4rt_forwarding_config.pb.txt",
+    "authz_policy": "/keys/authorization_policy.json"
+  }
+}
+```
 
 ## Open/Action items - if any
 

doc/psud/PSU_daemon_design.md

@@ -1,27 +1,35 @@
 # SONiC PSU Daemon Design #
 
-### Rev 0.1 ###
+### Rev 0.2 ###
 
 ### Revision ###
 
  | Rev |     Date    |       Author       | Change Description                |
  |:---:|:-----------:|:------------------:|-----------------------------------|
  | 0.1 |             |      Chen Junchao  | Initial version                   |
-
+ | 0.2 | August 4st, 2022 | Stephen Sun | Update according to the current implementation |
 
 ## 1. Overview
 
 The purpose of PSU daemon is to collect platform PSU data and trigger proper actions if necessary. Major functions of psud include:
 
 - Collect constant PSU data during daemon boot up, such as PSU number.
-- Collect variable PSU data periodically.
-- Monitor PSU event, set LED color and trigger syslog according to event type.
+- Collect variable PSU data periodically, including:
+  - PSU entity information
+  - PSU present status and power good status
+  - PSU power, current, voltage and voltage threshold
+  - PSU temperature and temperature threshold
+- Monitor PSU event, set LED color and trigger syslog according to event type, including:
+  - PSU present status and power good status
+  - whether the PSU voltage exceeds the minimal and maximum thresholds
+  - whether the PSU temperature exceeds the threshold
+  - whether the total PSU power consumption exceeds the budget (modular switch only)
 
 ## 2. PSU data collection
 
 PSU daemon data collection flow diagram:
 
-![](https://github.com/Azure/SONiC/blob/master/doc/pmon/daemon-flow.svg)
+![](PSU_daemon_design_pictures/PSU-daemon-data-collection-flow.svg)
 
 Now psud collects PSU data via platform API, and it also support platform plugin for backward compatible. All PSU data will be saved to redis database for further usage.
 
@@ -34,13 +42,23 @@ PSU information is stored in PSU table:
 	; Defines information for a psu
 	key                     = PSU_INFO|psu_name              ; information for the psu
 	; field                 = value
-	presence                = BOOLEAN                        ; presence of the psu
+	presence                = BOOLEAN                        ; presence state of the psu
 	model                   = STRING                         ; model name of the psu
 	serial                  = STRING                         ; serial number of the psu
+    revision                = STRING                         ; hardware revision of the PSU
 	status                  = BOOLEAN                        ; status of the psu
 	change_event            = STRING                         ; change event of the psu
 	fan                     = STRING                         ; fan_name of the psu
 	led_status              = STRING                         ; led status of the psu
+    is_replaceable          = STRING                         ; whether the PSU is replaceable
+    temp                    = 1*3.3DIGIT                     ; temperature of the PSU
+    temp_threshold          = 1*3.3DIGIT                     ; temperature threshold of the PSU
+    voltage                 = 1*3.3DIGIT                     ; the output voltage of the PSU
+    voltage_min_threshold   = 1*3.3DIGIT                     ; the minimal voltage threshold of the PSU
+    voltage_max_threshold   = 1*3.3DIGIT                     ; the maximum voltage threshold of the PSU
+    current                 = 1*3.3DIGIT                     ; the current of the PSU
+    power                   = 1*3.3DIGIT                     ; the power of the PSU
+
 
 Now psud only collect and update "presence" and "status" field.
 
@@ -72,10 +90,10 @@ The current output for "show platform psustatus" looks like:
 
 ```
 admin@sonic:~$ show platform psustatus
-PSU    Status
------  --------
-PSU 1  OK
-PSU 2  OK
+PSU    Model          Serial        HW Rev      Voltage (V)    Current (A)    Power (W)  Status    LED
+-----  -------------  ------------  --------  -------------  -------------  -----------  --------  -----
+PSU 1  MTEF-PSF-AC-A  MT1629X14911  A3                12.09           5.44        64.88  OK        green
+PSU 2  MTEF-PSF-AC-A  MT1629X14913  A3                12.02           4.69        56.25  OK        green
 ```
 
 ## 5. PSU LED management
@@ -147,4 +165,4 @@ Supervisord takes charge of this daemon. This daemon will loop every 3 seconds a
 
 - The psu_num will store in "chassis_info" table. It will just be invoked one time when system boot up or reload. The key is chassis_name, the field is "psu_num" and the value is from get_psu_num(). 
 - The psu_status and psu_presence will store in "psu_info" table. It will be updated every 3 seconds. The key is psu_name, the field is "presence" and "status", the value is from get_psu_presence() and get_psu_num().
-- The daemon query PSU event every 10 seconds via platform API. If any event detects, it should set PSU LED color accordingly and trigger proper syslog.
+- The daemon query PSU event every 3 seconds via platform API. If any event detects, it should set PSU LED color accordingly and trigger proper syslog.

doc/srv6/SRv6_uSID.md

@@ -0,0 +1,112 @@
+# SONiC uSID
+
+## Table of Content
+- [Overview](#Overview)
+- [Scope](#Scope)
+- [Design](#Design)
+- [Example](#Example)
+
+## Revision
+
+| Rev  |   Date    |              Author              | Change Description           |
+| :--: | :-------: | :------------------------------: | :--------------------------: |
+| 0.1  | 7/17/2022 | Shitanshu Shah, Reshma Sudarshan |  Initial version             |
+| 0.2  | 7/24/2022 | Shitanshu Shah, Reshma Sudarshan |  Incorporate review comments |
+
+## Overview
+SRv6 uSID (micro-segment) is extension of the SRv6 network programming model, refer to IETF drafts [Compressed SRv6 Segment List Encoding]( draft-ietf-spring-srv6-srh-compression-02) and [SRv6 uSID instructions IETF draft](https://datatracker.ietf.org/doc/draft-filsfils-spring-net-pgm-extension-srv6-usid/). uSID is a compressed SID value which can be for example carried in 16-bits (unlike full IPv6 address to represent a SID). uSID as is designed scales well with much lower MTU overhead required per uSID carrier. uSID carrier is 128-bit IPv6 address that can carry upto 6 uSIDs [Refer to Example for more details]
+
+## Scope
+The scope of this document is to enhance orchagent to support uSID programming instructions in this IETF draft. Current SAI API definitions already support uSID instructions. No SAI API change required in scope of this document. Current version of routing protocols in SONiC does not support SRv6, it is not in the scope of this document to add such a support for FRR routing stack.
+
+## Design
+Current srv6orch is designed, per [SRv6 HLD](https://github.com/sonic-net/SONiC/blob/master/doc/srv6/srv6_hld.md), to support SRv6 programming instructions as described in RFC 8754 and RFC 8986. This design extends SRv6 Network Programming with a new type of SRv6 SID behaviors defined as uSID.
+
+SRv6 uSID fully leverages current SRv6 control-plane, without any change, as is implemented by srv6orch.
+Following uSID behaviors are added,
+uN  - uN behavior is implemented with PSP and USD flavor
+uA  - uA local behavior is implemented with PSP and USD flavor
+uDT - uDT local behavior is implemented exactly same as that of End.DT4/End.DT6
+uDX - uDX local behavior is implemented exactly same as that of End.DX4/End.DX6
+
+PSP and USD end behavior flavors are already supported by SAI API today. End.DT4/6 and End.DX4/6 end behaviors are supported by SAI APIs as well. Thus there is no additional change required in SAI to support uN, uA, uDT and uDX behaviors.
+
+Changes in orchagent,
+- While processing MYSID entries, from SRV6_MY_SID_TABLE off of APPDB, handling of new actions uN, uA, uDT and uDX added in srv6orch. No APPDB schema changes required.
+- SAI end behavior and end behavior flavor are determined, before calling SAI APIs, to program MYSID entries
+
+```text
+const map<string, sai_my_sid_entry_endpoint_behavior_t> end_behavior_map =
+{
+    {"end",                SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_E},
+    {"end.x",              SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_X},
+    {"end.t",              SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_T},
+    {"end.dx6",            SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DX6},
+    {"end.dx4",            SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DX4},
+    {"end.dt4",            SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DT4},
+    {"end.dt6",            SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DT6},
+    {"end.dt46",           SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DT46},
+    {"end.b6.encaps",      SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_B6_ENCAPS},
+    {"end.b6.encaps.red",  SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_B6_ENCAPS_RED},
+    {"end.b6.insert",      SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_B6_INSERT},
+    {"end.b6.insert.red",  SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_B6_INSERT_RED},
++    {"udx6",               SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DX6},
++    {"udx4",               SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DX4},
++    {"udt6",               SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DT6},
++    {"udt4",               SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DT4},
++    {"udt46",              SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_DT46},
++    {"un",                 SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_UN},
++    {"ua",                 SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_UA}
+};
+
+const map<string, sai_my_sid_entry_endpoint_behavior_flavor_t> end_flavor_map =
+{
+    {"end",                SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_FLAVOR_PSP_AND_USD},
+    {"end.x",              SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_FLAVOR_PSP_AND_USD},
+    {"end.t",              SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_FLAVOR_PSP_AND_USD},
++    {"un",                 SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_FLAVOR_PSP_AND_USD},
++    {"ua",                 SAI_MY_SID_ENTRY_ENDPOINT_BEHAVIOR_FLAVOR_PSP_AND_USD}
+};
+```
+
+## Example
+uSID carrier is 128-bit IPv6 address which is specified in following format:
+```text
+<uSID-Block><Active-uSID><Next-uSID>...<Last-uSID><End-of-Carrier>[...<End-of-Carrier>]
+```
+- uSID Block:     An IPv6 prefix (defines a block of SRv6 uSIDs)
+- Active uSID:    The first uSID
+- Next uSID:      The next uSID after the Active uSID.
+- Last uSID:      The last uSID in the carrier before the End-of-Carrier
+- End-of-Carrier: A globally reserved uSID that marks the end of a uSID list. The End-of-Carrier ID is 0000. As many End-of-Carriers as required to complete full 128-bits IPv6 address
+
+![](images/SRv6_uSID_Example.png)
+
+- uSID block:  2001:41f0
+- Active uSID: 0100
+- Next uSID:   0200
+- Last uSID:   0A00
+- 2 End-of-Carriers (0000) to complete full 128-bits IPv6 address
+
+A node with local uSID of 2001:41f0:0100 is to be programmed with following SRV6_MY_SID_TABLE entry, with appropriate uSID end behavior. Following shown two separate examples with 2 different end behaviors.
+
+```text
+Note: prefix of "16:8:8:8" is (locator_block_len:locator_node_len:function_len:args_len) as is currently consumed by srv6orch.
+
+If end-behavior "un"
+"SRV6_MY_SID_TABLE" : {
+    "16:8:8:8:2001:41f0:0100::" : {
+       "action": "un",
+    }
+}
+
+If end-behavior is "udt46"
+"SRV6_MY_SID_TABLE" : {
+    "16:8:8:8:2001:41f0:0100::" : {
+       "action": "udt46",
+       "vrf":  "VRF-1001"
+    }
+}
+
+A node with local uSID of 2001:41f0:0200 is to be programmed with appropriate uSID end behavior, similarly for node with 2001:41f0:0500, and for node with 2001:41f0:0A00
+```

index.html

@@ -95,7 +95,7 @@
 				<li><a style="color: black" href="https://github.com/Azure/SONiC/wiki/Building-Guide">Building Guide</a></li>  				
 				<li><a style="color: black" href="https://github.com/Azure/SONiC/wiki/Testing-Guide">Testing Guide</a></li>  								
 				<li><a style="color: black" href="https://github.com/Azure/SONiC/wiki/technical_faq">Technical FAQ</a></li>				
-				<li><a style="color: black" href="https://azure.github.io/SONiC/sonic_latest_images.html">SONiC Latest Images</a></li>
+				<li><a style="color: black" href="https://sonic-net.github.io/SONiC/sonic_latest_images.html">SONiC Latest Images</a></li>
               </ul>
             </li>            
 			<li class="dropdown">
@@ -149,11 +149,11 @@ <h2 style="color: #FFFFFF; font-size: 125%">Software for Open Networking in the
         <!-- <a target="_blank" href="https://github.com/Azure/SONiC/wiki" class="mu-read-more-btn">Read More</a> -->
 
 		<p style="display: -webkit-inline-box;">
-			<a class="mu-read-more-btn bbutton" target="_blank" href="https://github.com/Azure/SONiC/wiki">Wiki</a>		
+			<a class="mu-read-more-btn bbutton" style="white-space: nowrap; font-size: 90%" target="_blank" href="https://github.com/Azure/SONiC/wiki">Wiki</a>		
 			&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-			<a class="mu-read-more-btn bbutton" target="_blank" href="https://github.com/Azure/SONiC/blob/master/sourcecode.md">GitHub</a> 
+			<a class="mu-read-more-btn bbutton" style="white-space: nowrap; font-size: 90%" target="_blank" href="https://github.com/Azure/SONiC/blob/master/sourcecode.md">GitHub</a> 
 			&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-			<a class="mu-read-more-btn bbutton" style="white-space: nowrap;" target="_blank" href="https://www.linuxfoundation.org/">Linux Foundation</a>
+			<a class="mu-read-more-btn bbutton" style="white-space: nowrap; font-size: 90%" target="_blank" href="https://www.linuxfoundation.org/">Linux Foundation</a>
 		</p>
 
       </div>