From 2572a804bd8b34ce637010fce1057cca6a999320 Mon Sep 17 00:00:00 2001 From: dplore Date: Tue, 24 Sep 2024 13:08:29 -0700 Subject: [PATCH 1/7] Add ingress policer to qos overview --- doc/qos_overview.md | 185 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 179 insertions(+), 6 deletions(-) diff --git a/doc/qos_overview.md b/doc/qos_overview.md index a43eebf26..bca8f5bf3 100644 --- a/doc/qos_overview.md +++ b/doc/qos_overview.md @@ -1,11 +1,18 @@ # Overview of OpenConfig QoS -Contributors: aashaikh†, robjs† +Contributors: aashaikh†, robjs†, dloher† † @google.com -December ‘17 +September 2024 # Overview of the QoS Model +## Schema of the QoS Model + +The schema of the QoS model can be visualized with this diagram which +highlights the relationships between the objects in the model. + +![QoS schema relationships](img/qos_schema.svg) + The OpenConfig quality of service model is made up of two sets of definitions: - Primitives that describe elements of QoS policy: includes definitions of @@ -19,9 +26,11 @@ The OpenConfig quality of service model is made up of two sets of definitions: correspond to each of the instantiated elements (e.g., schedulers, or queues). This is located under `/qos/interfaces`. -The flow of the QoS model is shown in the diagram below: +## Flow of data through the QoS Model -![Overview of QoS model](img/qos_layout.svg) +The flow of packets through of the QoS model is shown in the diagram below. + +![QoS model data flow](img/qos_layout.svg) When a packet arrives at an interface it is initially classified according to the classifier that is described under @@ -52,7 +61,7 @@ to virtual output queues that are instantiated for remote interfaces. In this case, statistics for each egress interface are reported within the ingress interface's entry in the `/qos/interfaces/interface` list. -# Annotated QoS Example +# Annotated QoS Examples ## Ingress Classification with Egress Scheduling @@ -60,7 +69,7 @@ The example QoS configuration below shows the configuration of an interface, assumed to be facing a customer which has ingress classification based on DSCP markings. The same interface has an egress scheduler policy applied to it. -``` +```json { # # The standard definition of an interface, assumed to be facing the customer. @@ -422,3 +431,167 @@ markings. The same interface has an egress scheduler policy applied to it. } } ``` + +## Ingress Classification with Ingress Scheduling (Policer) + +The example QoS configuration below shows the configuration of an interface, +assumed to be facing a customer which has ingress classification based on DSCP +markings. The same interface has an ingress scheduler policy applied to it +which implementes a ONE_RATE_TWO_COLOR policer. + +In this scenario, the device does not have hardware or software to implement +in ingress queue. To satisfy the OC schema requirements, a dummy or "fake" +queue is created. + +```yaml +--- +openconfig-qos: + classifers: + - classifer: “dest_A” + config: + name: “dest_A” + terms: + - term: + config: + id: "match_1_dest_A1" + conditions: + next-hop-group: + config: + name: "nhg_A1" # new OC path needed, string related to /afts/next-hop-groups/next-hop-group/state/next-hop-group-id (what about MBB / gribi is not transactional, a delete might fail and and add might succeed) + actions: + config: + target-group: "input_dest_A" + - term: + config: + id: "match_1_dest_A2" + conditions: + next-hop-group: + config: + name: "nhg_A2" # new OC path needed, string related to /afts/next-hop-groups/next-hop-group/state/next-hop-group-id + actions: + config: + target-group: "input_dest_A" + + - classifer: “dest_B” + config: + name: “dest_B” + terms: + - term: + config: + id: "match_1_dest_B1" + conditions: + next-hop-group: + config: + name: "nhg_B1" # new OC path needed, string related to /afts/next-hop-groups/next-hop-group/state/next-hop-group-id + actions: + config: + target-group: "input_dest_B" + - term: + config: + id: "match_1_dest_B2" + conditions: + next-hop-group: + config: + name: "nhg_B2" # new OC path needed, string related to /afts/next-hop-groups/next-hop-group/state/next-hop-group-id + actions: + config: + target-group: "input_dest_B" + + + forwarding-groups: + - forwarding-group: "input_dest_A" + config: + name: "input_dest_A" + output-queue: dummy_input_queue_A + - forwarding-group: "input_dest_B" + config: + name: "input_dest_B" + output-queue: dummy_input_queue_B + + queues: + - queue: + config: + name: "dummy_input_queue_A" + - queue: + config: + name: "dummy_input_queue_B" + + scheduler-policies: + - scheduler-policy: + config: + name: "limit_1Gb" + schedulers: + - scheduler: + config: + sequence: 1 + type: ONE_RATE_TWO_COLOR + inputs: + - input: "my input policer 1Gb" + config: + id: "my input policer 1Gb" + input-type: QUEUE + # instead of QUEUE, how about a new enum, FWD_GROUP (current options are QUEUE, IN_PROFILE, OUT_PROFILE) + queue: dummy_input_queue_A + one-rate-two-color: + config: + cir: 1000000000 # 1Gbit/sec + bc: 100000 # 100 kilobytes + queuing-behavior: POLICE + exceed-action: + config: + drop: TRUE + + - scheduler-policy: + config: + name: "limit_2Gb" + schedulers: + - scheduler: + config: + sequence: 1 + type: ONE_RATE_TWO_COLOR + inputs: + - input: "my input policer 2Gb" + config: + id: "my input policer 2Gb" + # instead of QUEUE, how about a new enum, FWD_GROUP (current options are QUEUE, IN_PROFILE, OUT_PROFILE) + input-type: QUEUE + queue: dummy_input_queue_B + one-rate-two-color: + config: + cir: 2000000000 # 2Gbit/sec + bc: 100000 # 100 kilobytes + queuing-behavior: POLICE + exceed-action: + config: + drop: TRUE + + interfaces: # this is repeated per subinterface (vlan) + - interface: "PortChannel1.100" + config: + interface-id: "PortChannel1.100" + input: + classifers: + - classifier: + config: + name: "dest_A" + type: "IPV4" + scheduler-policy: + state: + name: limit_group_A_1Gb + - interface: "PortChannel1.200" + config: + interface-id: "PortChannel1.200" + input: + classifers: + - classifier: + config: + name: "dest_B" + type: "IPV4" + scheduler-policy: + state: + name: limit_group_B_2Gb + + scheduler-policy: + state: + name: limit_group_A_1Gb +``` From 8fbb339346cd132947cdb864220140bb37142366 Mon Sep 17 00:00:00 2001 From: dplore Date: Tue, 24 Sep 2024 13:11:03 -0700 Subject: [PATCH 2/7] add schema svg --- doc/img/qos_schema.svg | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 doc/img/qos_schema.svg diff --git a/doc/img/qos_schema.svg b/doc/img/qos_schema.svg new file mode 100644 index 000000000..b3db9cf01 --- /dev/null +++ b/doc/img/qos_schema.svg @@ -0,0 +1,4 @@ + + + +
Interface
Input
Interface...
Forwarding Group
Forwarding Group
Queue
Queue
Scheduler Policy
Scheduler Policy
Interface
Output
Interface...
Classifier
(remarking)
Classifier...
QoS
Interface Input
QoS...
QoS
Interface Output
QoS...
Scheduler Policy
Scheduler Policy
Classifier
(remarking)
Classifier...Queue
Classifier
Classifier
Forwarding Group
Forwarding GroupClassifier
Scheduler Policy
(policing)
Scheduler Polic...child-schedulerqueue/config/nameoutput-fwd-groupscheduler-policy/config/name/qos/interfaces/interface/inputclassifier/config/nameinput/config/queueconfig/output-queueText is not SVG - cannot display \ No newline at end of file From 13b125a34aca5d8a71277e24f8e996549cef9dc6 Mon Sep 17 00:00:00 2001 From: dplore Date: Tue, 24 Sep 2024 13:24:24 -0700 Subject: [PATCH 3/7] revise annotations --- doc/qos_overview.md | 43 +++++++++++++++++++++++++------------------ 1 file changed, 25 insertions(+), 18 deletions(-) diff --git a/doc/qos_overview.md b/doc/qos_overview.md index bca8f5bf3..0028d2684 100644 --- a/doc/qos_overview.md +++ b/doc/qos_overview.md @@ -4,8 +4,6 @@ Contributors: aashaikh†, robjs†, dloher† † @google.com September 2024 -# Overview of the QoS Model - ## Schema of the QoS Model The schema of the QoS model can be visualized with this diagram which @@ -61,9 +59,9 @@ to virtual output queues that are instantiated for remote interfaces. In this case, statistics for each egress interface are reported within the ingress interface's entry in the `/qos/interfaces/interface` list. -# Annotated QoS Examples +## Annotated QoS Examples -## Ingress Classification with Egress Scheduling +### Ingress Classification with Egress Scheduling The example QoS configuration below shows the configuration of an interface, assumed to be facing a customer which has ingress classification based on DSCP @@ -432,19 +430,23 @@ markings. The same interface has an egress scheduler policy applied to it. } ``` -## Ingress Classification with Ingress Scheduling (Policer) +### Ingress Classification with Ingress Scheduling (Policer) The example QoS configuration below shows the configuration of an interface, -assumed to be facing a customer which has ingress classification based on DSCP -markings. The same interface has an ingress scheduler policy applied to it -which implementes a ONE_RATE_TWO_COLOR policer. +assumed to be facing a customer which has ingress classification based on +the next-hop group the packet is being sent to. The same interface has an +ingress scheduler policy applied to it which implementes a ONE_RATE_TWO_COLOR +policer. -In this scenario, the device does not have hardware or software to implement +In this scenario, the device is does not have hardware or software to implement in ingress queue. To satisfy the OC schema requirements, a dummy or "fake" -queue is created. +queue is created. ```yaml --- +# First we define classifiers which match packets based on a condition and +# define an action to "send" the packets to a forwarding-group +# (target-group). openconfig-qos: classifers: - classifer: “dest_A” @@ -457,7 +459,7 @@ openconfig-qos: conditions: next-hop-group: config: - name: "nhg_A1" # new OC path needed, string related to /afts/next-hop-groups/next-hop-group/state/next-hop-group-id (what about MBB / gribi is not transactional, a delete might fail and and add might succeed) + name: "nhg_A1" actions: config: target-group: "input_dest_A" @@ -467,7 +469,7 @@ openconfig-qos: conditions: next-hop-group: config: - name: "nhg_A2" # new OC path needed, string related to /afts/next-hop-groups/next-hop-group/state/next-hop-group-id + name: "nhg_A2" actions: config: target-group: "input_dest_A" @@ -482,7 +484,7 @@ openconfig-qos: conditions: next-hop-group: config: - name: "nhg_B1" # new OC path needed, string related to /afts/next-hop-groups/next-hop-group/state/next-hop-group-id + name: "nhg_B1" actions: config: target-group: "input_dest_B" @@ -492,12 +494,15 @@ openconfig-qos: conditions: next-hop-group: config: - name: "nhg_B2" # new OC path needed, string related to /afts/next-hop-groups/next-hop-group/state/next-hop-group-id + name: "nhg_B2" actions: config: target-group: "input_dest_B" - + # Here we define a forwarding-group. The purpose of this is to allow + # one to group multiple classifiers together and associate them with a + # queue. In concept, the forwarding-group "sends traffic" to a queue. + # See the qos data flow diagram to help visualize this. forwarding-groups: - forwarding-group: "input_dest_A" config: @@ -516,6 +521,9 @@ openconfig-qos: config: name: "dummy_input_queue_B" + # Here we define 2 scheduler-policies. + # The first has a 1Gb policer for traffic on dummy_input_queue_A + # The second has a 2Gb policer for traffic on dummy_input_queue_B scheduler-policies: - scheduler-policy: config: @@ -530,7 +538,6 @@ openconfig-qos: config: id: "my input policer 1Gb" input-type: QUEUE - # instead of QUEUE, how about a new enum, FWD_GROUP (current options are QUEUE, IN_PROFILE, OUT_PROFILE) queue: dummy_input_queue_A one-rate-two-color: config: @@ -553,7 +560,6 @@ openconfig-qos: - input: "my input policer 2Gb" config: id: "my input policer 2Gb" - # instead of QUEUE, how about a new enum, FWD_GROUP (current options are QUEUE, IN_PROFILE, OUT_PROFILE) input-type: QUEUE queue: dummy_input_queue_B one-rate-two-color: @@ -565,7 +571,8 @@ openconfig-qos: config: drop: TRUE - interfaces: # this is repeated per subinterface (vlan) + # Here we map interfaces to an input classifer and input scheduler-policy + interfaces: - interface: "PortChannel1.100" config: interface-id: "PortChannel1.100" From 0fbf1a90f42437276d1bfed1ddc27c73fb00e858 Mon Sep 17 00:00:00 2001 From: dplore Date: Wed, 2 Oct 2024 13:41:09 -0700 Subject: [PATCH 4/7] convert ingress config to legal json --- doc/qos_overview.md | 256 +++++++++++++++++--------------------------- 1 file changed, 97 insertions(+), 159 deletions(-) diff --git a/doc/qos_overview.md b/doc/qos_overview.md index 0028d2684..c84dadfbc 100644 --- a/doc/qos_overview.md +++ b/doc/qos_overview.md @@ -442,163 +442,101 @@ In this scenario, the device is does not have hardware or software to implement in ingress queue. To satisfy the OC schema requirements, a dummy or "fake" queue is created. -```yaml ---- -# First we define classifiers which match packets based on a condition and -# define an action to "send" the packets to a forwarding-group -# (target-group). -openconfig-qos: - classifers: - - classifer: “dest_A” - config: - name: “dest_A” - terms: - - term: - config: - id: "match_1_dest_A1" - conditions: - next-hop-group: - config: - name: "nhg_A1" - actions: - config: - target-group: "input_dest_A" - - term: - config: - id: "match_1_dest_A2" - conditions: - next-hop-group: - config: - name: "nhg_A2" - actions: - config: - target-group: "input_dest_A" - - - classifer: “dest_B” - config: - name: “dest_B” - terms: - - term: - config: - id: "match_1_dest_B1" - conditions: - next-hop-group: - config: - name: "nhg_B1" - actions: - config: - target-group: "input_dest_B" - - term: - config: - id: "match_1_dest_B2" - conditions: - next-hop-group: - config: - name: "nhg_B2" - actions: - config: - target-group: "input_dest_B" - - # Here we define a forwarding-group. The purpose of this is to allow - # one to group multiple classifiers together and associate them with a - # queue. In concept, the forwarding-group "sends traffic" to a queue. - # See the qos data flow diagram to help visualize this. - forwarding-groups: - - forwarding-group: "input_dest_A" - config: - name: "input_dest_A" - output-queue: dummy_input_queue_A - - forwarding-group: "input_dest_B" - config: - name: "input_dest_B" - output-queue: dummy_input_queue_B - - queues: - - queue: - config: - name: "dummy_input_queue_A" - - queue: - config: - name: "dummy_input_queue_B" - - # Here we define 2 scheduler-policies. - # The first has a 1Gb policer for traffic on dummy_input_queue_A - # The second has a 2Gb policer for traffic on dummy_input_queue_B - scheduler-policies: - - scheduler-policy: - config: - name: "limit_1Gb" - schedulers: - - scheduler: - config: - sequence: 1 - type: ONE_RATE_TWO_COLOR - inputs: - - input: "my input policer 1Gb" - config: - id: "my input policer 1Gb" - input-type: QUEUE - queue: dummy_input_queue_A - one-rate-two-color: - config: - cir: 1000000000 # 1Gbit/sec - bc: 100000 # 100 kilobytes - queuing-behavior: POLICE - exceed-action: - config: - drop: TRUE - - - scheduler-policy: - config: - name: "limit_2Gb" - schedulers: - - scheduler: - config: - sequence: 1 - type: ONE_RATE_TWO_COLOR - inputs: - - input: "my input policer 2Gb" - config: - id: "my input policer 2Gb" - input-type: QUEUE - queue: dummy_input_queue_B - one-rate-two-color: - config: - cir: 2000000000 # 2Gbit/sec - bc: 100000 # 100 kilobytes - queuing-behavior: POLICE - exceed-action: - config: - drop: TRUE - - # Here we map interfaces to an input classifer and input scheduler-policy - interfaces: - - interface: "PortChannel1.100" - config: - interface-id: "PortChannel1.100" - input: - classifers: - - classifier: - config: - name: "dest_A" - type: "IPV4" - scheduler-policy: - state: - name: limit_group_A_1Gb - - interface: "PortChannel1.200" - config: - interface-id: "PortChannel1.200" - input: - classifers: - - classifier: - config: - name: "dest_B" - type: "IPV4" - scheduler-policy: - state: - name: limit_group_B_2Gb - - scheduler-policy: - state: - name: limit_group_A_1Gb +```json +{ + "openconfig-interfaces": [ + { + "config": { + "name": "tunnel1_if_name", + "tunnel": { + "config": { + "dst": "tunnel1_outer_ip_dst", + "gre-key": "tunnel1_outer_gre_key", + "src": "tunnel1_outer_ip_src", + "ttl": "tunnel1_outer_ttl" + }, + "ipv4": { + "addresses": [ + { + "address": null, + "config": { + "ip": "tunnel1_interface_ipv4", + "prefix-length": "tunnel1_interface_ipv4_prefixlen" + } + } + ], + "config": { + "mtu": "tunnel1_inner_mtu" + } + }, + "ipv6": { + "addresses": [ + { + "address": { + "config": { + "ip": "tunnel1_interface_ipv6", + "prefix-length": "tunnel1_interface_ipv6_prefixlen" + } + } + } + ], + "config": { + "mtu": "tunnel1_inner_mtu" + } + } + } + }, + "interface": null, + "name": "tunnel1_if_name" + } + ], + "openconfig-qos": { + "interfaces": [ + { + "config": { + "interface-id": "PortChannel1.100" + }, + "input": { + "classifiers": [ + { + "classifier": "dest_A", + "config": { + "name": "dest_A", + "type": "IPV4" + } + } + ], + "scheduler-policy": { + "config": { + "name": "limit_group_A_1Gb" + } + } + }, + "interface": "PortChannel1.100" + }, + { + "config": { + "interface-id": "PortChannel1.200" + }, + "input": { + "classifiers": [ + { + "classifier": "dest_B", + "config": { + "name": "dest_B", + "type": "IPV4" + } + } + ], + "scheduler-policy": { + "config": { + "name": "limit_group_B_1Gb" + } + } + }, + "interface": "PortChannel1.200" + } + ] + } +} ``` From 5ee69240f60a4a52ebb7d61171f10cecaf5b5d34 Mon Sep 17 00:00:00 2001 From: dplore Date: Wed, 2 Oct 2024 15:45:35 -0700 Subject: [PATCH 5/7] clarify the two scenarios are separate examples --- doc/qos_overview.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/doc/qos_overview.md b/doc/qos_overview.md index c84dadfbc..5592058c0 100644 --- a/doc/qos_overview.md +++ b/doc/qos_overview.md @@ -61,7 +61,7 @@ interface's entry in the `/qos/interfaces/interface` list. ## Annotated QoS Examples -### Ingress Classification with Egress Scheduling +### Example 1: Ingress Classification with Egress Scheduling The example QoS configuration below shows the configuration of an interface, assumed to be facing a customer which has ingress classification based on DSCP @@ -430,17 +430,19 @@ markings. The same interface has an egress scheduler policy applied to it. } ``` -### Ingress Classification with Ingress Scheduling (Policer) +### Example 2: Ingress Classification with Ingress Scheduling (Policer) on a VOQ device The example QoS configuration below shows the configuration of an interface, assumed to be facing a customer which has ingress classification based on the next-hop group the packet is being sent to. The same interface has an -ingress scheduler policy applied to it which implementes a ONE_RATE_TWO_COLOR -policer. +ingress scheduler policy applied to it which implements an +`ONE_RATE_TWO_COLOR` policer. -In this scenario, the device is does not have hardware or software to implement -in ingress queue. To satisfy the OC schema requirements, a dummy or "fake" -queue is created. +In this scenario, the device has a VOQ architecture is does not have hardware +or software to implement in ingress queue. To satisfy the OC schema +requirements, a dummy or "fake" queue is created for the ingress side of the +pipeline. Note, an egress queue could still be defined on the egress side, +but it is not included here for simplication. ```json { From d06803cce756104c2150960b97fedf846e89c3f0 Mon Sep 17 00:00:00 2001 From: dplore Date: Thu, 3 Oct 2024 14:56:22 -0700 Subject: [PATCH 6/7] fix json --- doc/qos_overview.md | 228 ++++++++++++++++++++++++++++++++++++-------- 1 file changed, 189 insertions(+), 39 deletions(-) diff --git a/doc/qos_overview.md b/doc/qos_overview.md index 5592058c0..1ec202a66 100644 --- a/doc/qos_overview.md +++ b/doc/qos_overview.md @@ -446,62 +446,213 @@ but it is not included here for simplication. ```json { - "openconfig-interfaces": [ - { - "config": { - "name": "tunnel1_if_name", - "tunnel": { - "config": { - "dst": "tunnel1_outer_ip_dst", - "gre-key": "tunnel1_outer_gre_key", - "src": "tunnel1_outer_ip_src", - "ttl": "tunnel1_outer_ttl" + "openconfig-qos": { + "classifers": [ + { + "classifer": "“dest_A”", + "config": { + "name": "“dest_A”" + }, + "terms": [ + { + "term": null, + "config": { + "id": "match_1_dest_A1" + }, + "conditions": { + "next-hop-group": { + "config": { + "name": "nhg_A1" + } + } + }, + "actions": { + "config": { + "target-group": "input_dest_A" + } + } }, - "ipv4": { - "addresses": [ - { - "address": null, + { + "term": null, + "config": { + "id": "match_1_dest_A2" + }, + "conditions": { + "next-hop-group": { "config": { - "ip": "tunnel1_interface_ipv4", - "prefix-length": "tunnel1_interface_ipv4_prefixlen" + "name": "nhg_A2" } } - ], + }, + "actions": { + "config": { + "target-group": "input_dest_A" + } + } + } + ] + }, + { + "classifer": "“dest_B”", + "config": { + "name": "“dest_B”" + }, + "terms": [ + { + "term": null, "config": { - "mtu": "tunnel1_inner_mtu" + "id": "match_1_dest_B1" + }, + "conditions": { + "next-hop-group": { + "config": { + "name": "nhg_B1" + } + } + }, + "actions": { + "config": { + "target-group": "input_dest_B" + } } }, - "ipv6": { - "addresses": [ + { + "term": null, + "config": { + "id": "match_1_dest_B2" + }, + "conditions": { + "next-hop-group": { + "config": { + "name": "nhg_B2" + } + } + }, + "actions": { + "config": { + "target-group": "input_dest_B" + } + } + } + ] + } + ], + "forwarding-groups": [ + { + "forwarding-group": "input_dest_A", + "config": { + "name": "input_dest_A", + "output-queue": "dummy_input_queue_A" + } + }, + { + "forwarding-group": "input_dest_B", + "config": { + "name": "input_dest_B", + "output-queue": "dummy_input_queue_B" + } + } + ], + "queues": [ + { + "queue": null, + "config": { + "name": "dummy_input_queue_A" + } + }, + { + "queue": null, + "config": { + "name": "dummy_input_queue_B" + } + } + ], + "scheduler-policies": [ + { + "scheduler-policy": null, + "config": { + "name": "limit_1Gb" + }, + "schedulers": [ + { + "scheduler": null, + "config": { + "sequence": 1, + "type": "ONE_RATE_TWO_COLOR" + }, + "inputs": [ { - "address": { - "config": { - "ip": "tunnel1_interface_ipv6", - "prefix-length": "tunnel1_interface_ipv6_prefixlen" - } + "input": "my input policer 1Gb", + "config": { + "id": "my input policer 1Gb", + "input-type": "QUEUE", + "queue": "dummy_input_queue_A" } } ], - "config": { - "mtu": "tunnel1_inner_mtu" + "one-rate-two-color": { + "config": { + "cir": 1000000000, + "bc": 100000, + "queuing-behavior": "POLICE" + }, + "exceed-action": { + "config": { + "drop": true + } + } } } - } + ] }, - "interface": null, - "name": "tunnel1_if_name" - } - ], - "openconfig-qos": { + { + "scheduler-policy": null, + "config": { + "name": "limit_2Gb" + }, + "schedulers": [ + { + "scheduler": null, + "config": { + "sequence": 1, + "type": "ONE_RATE_TWO_COLOR" + }, + "inputs": [ + { + "input": "my input policer 2Gb", + "config": { + "id": "my input policer 2Gb", + "input-type": "QUEUE", + "queue": "dummy_input_queue_B" + } + } + ], + "one-rate-two-color": { + "config": { + "cir": 2000000000, + "bc": 100000, + "queuing-behavior": "POLICE" + }, + "exceed-action": { + "config": { + "drop": true + } + } + } + } + ] + } + ], "interfaces": [ { + "interface": null, "config": { "interface-id": "PortChannel1.100" }, "input": { "classifiers": [ { - "classifier": "dest_A", + "classifier": null, "config": { "name": "dest_A", "type": "IPV4" @@ -513,17 +664,17 @@ but it is not included here for simplication. "name": "limit_group_A_1Gb" } } - }, - "interface": "PortChannel1.100" + } }, { + "interface": null, "config": { "interface-id": "PortChannel1.200" }, "input": { "classifiers": [ { - "classifier": "dest_B", + "classifier": null, "config": { "name": "dest_B", "type": "IPV4" @@ -535,8 +686,7 @@ but it is not included here for simplication. "name": "limit_group_B_1Gb" } } - }, - "interface": "PortChannel1.200" + } } ] } From 3f914346a275385afa4055ce7738c950b24455b0 Mon Sep 17 00:00:00 2001 From: dplore Date: Thu, 3 Oct 2024 16:03:05 -0700 Subject: [PATCH 7/7] add comments to JSON --- doc/qos_overview.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/doc/qos_overview.md b/doc/qos_overview.md index 1ec202a66..7df665c1b 100644 --- a/doc/qos_overview.md +++ b/doc/qos_overview.md @@ -446,6 +446,10 @@ but it is not included here for simplication. ```json { + # + # A classifer is created to match packets belonging to certain + # next-hop-groups and map them either forwarding-group input_dest_A or + # input_dest_B "openconfig-qos": { "classifers": [ { @@ -537,6 +541,9 @@ but it is not included here for simplication. ] } ], + # + # Forwarding groups are created named input_dest_A and input_dest_B. + # These are mapped to 'fake' queues "forwarding-groups": [ { "forwarding-group": "input_dest_A", @@ -567,6 +574,9 @@ but it is not included here for simplication. } } ], + # + # Two scheduler policies are created, limit_1Gb and limit_2Gb + # and are associated with the dummy queue they are servicing. "scheduler-policies": [ { "scheduler-policy": null, @@ -643,6 +653,8 @@ but it is not included here for simplication. ] } ], + # + # Interfaces input are mapped to the desired classifier and scheduler. "interfaces": [ { "interface": null,