Fix typos in Integrated-Circuit_pipeline_aggregated_counters_guide (#…

…1069)

doc/Integrated-Circuit_pipeline_aggregated_counters_guide.md

@@ -1,4 +1,4 @@
-# Intergrated Circuit aggregated pipeline counters guide
+# Integrated Circuit aggregated pipeline counters guide
 ## Introduction
 This guide discusses semantics of different counters provided under the
 `openconfig-platform/components/component/integrated-circuit/pipeline-counters` container.
@@ -36,21 +36,21 @@ The increments of this counter are typically signal of some form of attack with
 The increments of this counter are expected during convergence events as well as during stable operation. However rapid increase in drop rate **may** be a signal of network being unhealthy and typically requires further investigation. 
 The further break down of this counter, if available as vendor extension under `/openconfig-platform:components/component/integrated-circuit/openconfig-platform-pipeline-counters:pipeline-counters/drop/vendor` container could help to further narrow-down cause of drops. 
 
-If prolonged packet drops are found to be caused by lack of FIB entry for incomming packets, this suggest inconsistency between Network Control plane protocols (BGP, IGP, RSVP, gRIBI), FIB calculated by Controller Card and FIB programmed into given Integrated Circuit.
+If prolonged packet drops are found to be caused by lack of FIB entry for incoming packets, this suggest inconsistency between Network Control plane protocols (BGP, IGP, RSVP, gRIBI), FIB calculated by Controller Card and FIB programmed into given Integrated Circuit.
 
-If implemetation supports `urpf-aggregate` counter, packets discarded due to uRPF should not be counted as `packet-processing-aggregate`. Else, uRPF discarded oacket should be counted against this counter.
+If an implementation supports `urpf-aggregate` counter, packets discarded due to uRPF should not be counted as `packet-processing-aggregate`. Else, uRPF discarded oacket should be counted against this counter.
 
 #### congestion-aggregate
 
 
 ##### Usability
-The increments of this counter are signal of given Integrated Circuit being overhelmed by incomming traffic and complexity of packet processing that is required. 
+The increments of this counter are signal of given Integrated Circuit being overhelmed by incoming traffic and complexity of packet processing that is required. 
 
 #### adverse-aggregate
 ##### Usability
 The increments of this counter are generally a signal of a hardware defect (e.g. memory errors or signal integrity issues) or (micro)code software defects. 
 
-#### Queue tail and AQM drops exeption discussion.
+#### Queue tail and AQM drops exception discussion.
 Drops associated with QoS queue tail or AQM are the result of egress interface congestion.   This is NOT the same as I-C congestion, and should be counted using /interfaces counters as it is expected state from the platform (router) point of view. It may be not expected state from a network design point of view but from the INTEGRATED_CIRCUIT, it is behaving according to design.   
 
 The OpenConfig definition for [congestion-aggregate](https://github.com/openconfig/public/blob/5d38d8531ef9c5b998262207eb6dbdae8968f9fe/release/models/platform/openconfig-platform-pipeline-counters.yang#L1096-L1099) excludes "queue drop counters". It desirable to  not count QoS queue drops under this `congestion-aggregate` in order to maintain a clear signal of hitting I-C performance limitations, rather then blend it with basic, simple egress interface speed limitations.