Pr 2119

.github/ISSUE_TEMPLATE/workgroup-request.md

@@ -13,7 +13,7 @@ assignees: lucyhyde
 
 **Working Group Details**
 <!-- 
-   Please fill working group scope and desriptions
+   Please fill working group scope and descriptions
 -->
 
 **--Working Group Name:**

CONTRIBUTING.md

@@ -36,7 +36,7 @@ For example:
 ## 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/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
+## Committing new test
 When committing a new feature with a new test, please complete a [test plan from the template](doc/SONiC%20Test%20Plan%20Template.md)
 
 

doc/BGP/BGP-route-aggregation-with-bbr-awareness.md

@@ -18,7 +18,7 @@
     - [CLI Design](#cli-design)
         - [Show CLI](#show-cli)
         - [Config CLI](#config-cli)
-- [Feature limitaion](#feature-limitaion)
+- [Feature limitation](#feature-limitation)
 
 
 ## Revision
@@ -46,7 +46,7 @@ This document describes how to leverage the SONiC config DB to add or remove BGP
 ## Overview
 In BGP, we can aggregate contributing routes into one single aggregated route. It has many advantages, for example reducing routes’ count.
 
-However, firstly, SONiC can’t configurate aggregated addresses via config DB and doesn’t have CLI support for it.
+However, firstly, SONiC can’t configure aggregated addresses via config DB and doesn’t have CLI support for it.
 
 Secondly, if we aggregated routes without BBR feature on device, we many got packet drop on this device due to contributing routes missing.
 
@@ -205,7 +205,7 @@ It's a string which should be the name of a prefix list, and the aggregate addre
 It's a string which should be the name of a prefix list, and the aggregate address will be append to the prefix list with prefix length filter to filter prefixes whose length greater or equal to the prefix length of the aggregate address.
 
 ### State DB Extension
-For every aggregated address, we track its state in state DB, it has two states active and inactive. Active state means the address is configurated in the bgp container, while inactive state means isn't.
+For every aggregated address, we track its state in state DB, it has two states active and inactive. Active state means the address is configured in the bgp container, while inactive state means isn't.
 
 #### State DB sample:
 ```json
@@ -359,5 +359,5 @@ Then we will implement test in sonic-mgmt repo to test if this feature works inc
 3. Remove aggregated address in config db and check whether the address will be removed from state db and bgp container.
 4. More tests details will be published in sonic-mgmt repo.
 
-## Feature limitaion
-In CLOS network, aggregate deployment without simultaneous operation on all devices in same layer could lead to traffic imbalance due to traffic prefers go to detail routes, please only use this feature in traffic insensitve scenario or ensure deploy aggregate routes on all devices in same layer simultaneously.
+## Feature limitation
+In CLOS network, aggregate deployment without simultaneous operation on all devices in same layer could lead to traffic imbalance due to traffic prefers go to detail routes, please only use this feature in traffic insensitive scenario or ensure deploy aggregate routes on all devices in same layer simultaneously.

doc/BGP/BGP-router-id.md

@@ -32,7 +32,7 @@ This document describes a mechanism to allow user explicitly configure BGP route
 ### Overview
 
 Currently, there are some BGP hard codings in SONiC:
-1. BGP router id was defined as a 32-bit value that uniquely identifies a BGP device. In single-asic device, SONiC uses Loopback0 IPv4 address as BGP router id. In mult-asic and uses Loopback4096 IPv4 address as BGP router id (for both iBGP and eBGP). This coupling prevents users from using customized router id. If IPv4 address of Loopback0 / Loopback4096 don't exist, BGP router id wouldn't be configured, then FRR would choose the largest IP address in device to be BGP router id. If the router id choosen by FRR is not unique, it would be considered an error.
+1. BGP router id was defined as a 32-bit value that uniquely identifies a BGP device. In single-asic device, SONiC uses Loopback0 IPv4 address as BGP router id. In mult-asic and uses Loopback4096 IPv4 address as BGP router id (for both iBGP and eBGP). This coupling prevents users from using customized router id. If IPv4 address of Loopback0 / Loopback4096 don't exist, BGP router id wouldn't be configured, then FRR would choose the largest IP address in device to be BGP router id. If the router id chosen by FRR is not unique, it would be considered an error.
 2. In single-asic device, SONiC wouldn't add BGP peer when there is not Loopback0 IPv4 exists. In multi-asic, SONiC wouldn't add eBGP peer when there is not Loopback0 IPv4 exists.
 
 Below is current workflow about BGP and router id in single-asic, only includes contents related to Loopback0.
@@ -67,7 +67,7 @@ Add support to allow user explicitly configure BGP router id.
 
 2 aspects enhancement:
 
-1. Add a field `bgp_router_id` in `CONFIG_DB["DEVICE_METADATA"]["localhost"]` to support explicitly configure BGP router id. For multi-asic devices, this configuraion would be added to correspond config_db for each asic. If `CONFIG_DB["DEVICE_METADATA"]["localhost"]["bgp_router_id"]` configured, always use it as BGP router id. With this change, the new BGP router id configuration behavior will be like follow table. To be clarified that when bgp_router_id doesn't be configured, the behavior is totally same as previously.
+1. Add a field `bgp_router_id` in `CONFIG_DB["DEVICE_METADATA"]["localhost"]` to support explicitly configure BGP router id. For multi-asic devices, this configuration would be added to correspond config_db for each asic. If `CONFIG_DB["DEVICE_METADATA"]["localhost"]["bgp_router_id"]` configured, always use it as BGP router id. With this change, the new BGP router id configuration behavior will be like follow table. To be clarified that when bgp_router_id doesn't be configured, the behavior is totally same as previously.
 
 |           | Loopback0/Loopback4096 IPv4 address exists | Loopback0/Loopback4096 IPv4 address doesn't exist |
 |--------------|-------|------------|

doc/BGP/BGP-supress-fib-pending.md

@@ -219,7 +219,7 @@ module sonic-device_metadata {
 /* end of module sonic-device_metadata
 ```
 
-This knob can only be set to ```"enable"``` when syncrhonous SAI configuration mode is on. This constraint is guaranteed by the ```must``` expression for this leaf.
+This knob can only be set to ```"enable"``` when synchronous SAI configuration mode is on. This constraint is guaranteed by the ```must``` expression for this leaf.
 
 <!-- omit in toc -->
 #### 6.4. CLI
@@ -295,7 +295,7 @@ B>q 0.0.0.0/0 [20/0] via 10.0.0.1, PortChannel102, weight 1, 00:04:46
   q                  via 10.0.0.13, PortChannel1011, weight 1, 00:04:46
 ```
 
-Once zebra is notified about successfull route offload status the *offload* flag is set:
+Once zebra is notified about successful route offload status the *offload* flag is set:
 
 ```
 admin@sonic:~$ vtysh -c "show ip route 100.1.0.25/32 json"
@@ -590,7 +590,7 @@ sequenceDiagram
   deactivate APPL_DB
 
   alt Suppression is disabled
-    Note left of RouteSync: Reply back immidiatelly <br>when this feature is disabled
+    Note left of RouteSync: Reply back immediately <br>when this feature is disabled
     RouteSync ->> zebra: Send back RTM_NEWROUTE<br> with RTM_F_OFFLOAD set
     zebra ->> RouteSync: <br>
   end

doc/BGP/Bgpcfgd-dyn-peer-modification-support.md

@@ -122,7 +122,7 @@ The following modifications will be made to bgpcfgd to support the new scenario:
 ```
 4. Note that the default behavior when no update template is defined, is one where nothing executes during update peer operations, thereby making this change fully backward compatible and requiring no breaking changes in terms of templates for users of bgpcfgd.
 4. We expose similar logic as listed in 1, 2 for a delete handling, ie we add a delete template under self.templates["delete"] if such a template exists in the directory structure
-5. Upon a delete peer ocurring, we render the delete template(instead of executing the current behavior of ```no neighbor {{ neighbor addr}}```), on the other hand if a delete template is not defined then the default behavior of ```no neighbor {{ neighbor addr}}``` applies as usual, thereby making this change backward compatible.
+5. Upon a delete peer occurring, we render the delete template(instead of executing the current behavior of ```no neighbor {{ neighbor addr}}```), on the other hand if a delete template is not defined then the default behavior of ```no neighbor {{ neighbor addr}}``` applies as usual, thereby making this change backward compatible.
 6. Bgpcfgd will write a State DB entry per the schema from section 2.2. This will be utilized by the SDN controller to identify what has been processed by bgpcfgd in terms of configuration.
 
 ## 2.5 Docker-FPM-FRR bgpd template:

doc/California-SB237/California-SB237.md

@@ -25,7 +25,7 @@
 	* 1.14. [Test Plan](#TestPlan)
 		* 1.14.1. [Unit Test cases](#UnitTestcases)
 		* 1.14.2. [System Test cases](#SystemTestcases)
-		* 1.14.3. [Pasword Change Flow](#PasswordChangeFlow)
+		* 1.14.3. [Password Change Flow](#PasswordChangeFlow)
 	* 1.15. [3rd Party Components](#rdPartyComponents)
 		* 1.15.1. [PW Force Expiration](#WForceExpire)
 		* 1.15.2. [Pam Unix](#PAMUNIX)
@@ -143,7 +143,7 @@ Not relevant
 
 
 ###  1.11. <a name='WarmbootandFastbootDesignImpact'></a>Warmboot and Fastboot Design Impact
-The feature can be triggered after sonic upgrade and warm reboot and feature doesn't affect trafic.
+The feature can be triggered after sonic upgrade and warm reboot and feature doesn't affect traffic.
 
 ###  1.12. <a name='RestrictionsLimitations'></a>Restrictions/Limitations
 The California law feature is not supported on remote AAA.
@@ -169,7 +169,7 @@ Check affecting password hardening feature:
   Check password hardening age is not affected
 
 
- #### 1.14.3. <a name='PasswordChangeFlow'></a>Pasword Change Flow
+ #### 1.14.3. <a name='PasswordChangeFlow'></a>Password Change Flow
 
  Example of password change during 1st login.
 

doc/DHCPv6_Relay/DHCPv6_Relay_HLD.md

@@ -55,7 +55,7 @@ This document describes the high level design of the DHCP Relay for IPv6 feature
 DHCP Relay for IPv6 feature in SONiC should meet the following high-level functional requirements:
 
 - Give the support for relaying DHCP packets from downstream networks to upstream networks using IPv6 addresses.
-- Provide the functionality as a seperate process running on dhcp-relay docker container.
+- Provide the functionality as a separate process running on dhcp-relay docker container.
 - Relaying messages to multiple unicast and multicast addresses.
 
 ## 1.2 Configuration and Management Requirements

doc/DHCPv6_relay/DHCPv6-relay-agent-High-Level-Design.md

@@ -41,7 +41,7 @@ DUID: DHCP Unique Identifier (Each DHCPv6 client and server has a DUID. DHCPv6 s
 
 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. However, these methods do not provide a simple way to extract a client's link-layer address. Providing option 79 in DHCPv6 Relay-Forward messages will help carry the client link-layer address explicitly. The server needs to know the client's MAC address to allow DHCP Reservation, which provides pre-set IP address to specific client based on its physical MAC address. The DHCPv6 relay agent is able to read the source MAC address of DHCPv6 messages that it received from client, and encapsulate these messages within a DHCPv6 Relay-Forward message, inserting the client MAC address as option 79 in the Relay-Forward header sent to the server.
 
-With heterogenous DHCP client implementation across the network, DUIDs could not resolve IP resource tracking issue. The two types of DUIDs, DUID-LL and DUID-LLT used to facilitate resource tracking both have link layer addresses embedded. The current client link-layer address option in DHCPv6 specification limits the DHCPv6 Relay to first hop to provide the client link layer address, which are relay agents that are connected to the same link as the client, and that limits SONiC DHCPv6 deployment to ToR/MoR switches for early stages. One solution would be to provide SONiC's own DHCPv6 relay agent feature. ISC DHCP currently has no support for option 79. Configuration wise, using ISC DHCP configuration requires restarting container as configuration is provided through the commandline. The plan is to eventually move away from ISC DHCP configuration, which is fairly complex, and provide SONiC's own configuration. 
+With heterogeneous DHCP client implementation across the network, DUIDs could not resolve IP resource tracking issue. The two types of DUIDs, DUID-LL and DUID-LLT used to facilitate resource tracking both have link layer addresses embedded. The current client link-layer address option in DHCPv6 specification limits the DHCPv6 Relay to first hop to provide the client link layer address, which are relay agents that are connected to the same link as the client, and that limits SONiC DHCPv6 deployment to ToR/MoR switches for early stages. One solution would be to provide SONiC's own DHCPv6 relay agent feature. ISC DHCP currently has no support for option 79. Configuration wise, using ISC DHCP configuration requires restarting container as configuration is provided through the commandline. The plan is to eventually move away from ISC DHCP configuration, which is fairly complex, and provide SONiC's own configuration. 
 
 # DHCPv6
 

doc/Dump-Utility.md

@@ -75,7 +75,7 @@ dump state port all
 3) This argument could either be a table-key or a unique-field-value present in either Conf DB or Appl DB.
    * Eg: For PORT, the second argument will be an interface name i.e 'Ethernet128' which is a table-key. On the other hand, the secondary argument for COPP will be a trap_id such as  'arp_req', which is a field-value and not a key of any table.
 4) The decision of what to pass as a secondary argument lies with the discretion of the one who is writing the module.
-6) The Command should also take a list of comma seperated inputs for the secondary argument
+6) The Command should also take a list of comma separated inputs for the secondary argument
 7) The Command should also accept an "all" value and which means it should print the unified view for every entry related to that feature.
 
 ```
@@ -644,7 +644,7 @@ class Port(Executor):
 2) MatchEngine / MatchRequest: Provided to abstract the heavy lifting in fetching the required data from redis-db/config-files. More info in the next section.
 3) verbose_print(str_): prints to the stdout based on verbosity provided by the user.
 4) handle_error(err_str, excep=False): Prints the error output to stdout, if any experienced by the module, Set excep = True, to raise an exception
-5) handle_multiple_keys_matched_error(err_str, key_to_go_with="", excep=False): When a filtering criteria specified by the module matches multiple keys, wherein it is expected to match ony one, this method can be used.
+5) handle_multiple_keys_matched_error(err_str, key_to_go_with="", excep=False): When a filtering criteria specified by the module matches multiple keys, wherein it is expected to match only one, this method can be used.
 ```
 
 ### 2.4 Match Infrastructure
@@ -672,7 +672,7 @@ To Abstract this functionality out, a MatchEngine class is created. A MatchReque
   "just_keys": "true|false"     # Mandatory, if true, Only Returns the keys matched. Does not return field-value pairs. Defaults to True
   "ns" : DEFAULT_NAMESPACE      # namespace argument, if nothing is provided, default namespace is used
   "match_entire_list" : False   # Some of the fields in redis can consist of multiple values eg: trap_ids = "bgp,bgpv6,ospf".
-  			          When this arg is set to true, entire list is matched incluing the ",".
+  			          When this arg is set to true, entire list is matched including the ",".
 				  When False, the values are split based on "," and individual items are matched with
 }
 ```
@@ -995,7 +995,7 @@ admin@sonic:~$ dump state acl_rule 'DATA_L3|R1' -t
 
 | S.No | Test case synopsis                                                                                                                      |
 |------|-----------------------------------------------------------------------------------------------------------------------------------------|
-|  1   | Verify MatchEngine funtionality in cases of invalid Request Objects                                                                     |
+|  1   | Verify MatchEngine functionality in cases of invalid Request Objects                                                                     |
 |  2   | Verify MatchEngine Match functionality is as expected                                                                                   |
 |  3   | Verify all the options in the CLI is working as expected                                                                                |
 |  4   | Verify the namespace arg is working as expected                                                                                         |