Requested revision
| Standard: | 802.1Qcp-2018 | Clause: | 48.6.3.2 |
| Clause title: | Incorrect traffic-class-table-grouping | ||
Rationale for revision
The nodes for traffic-class-table-grouping (page 52) use an incorrect
interpretation of the information model in 12.6.3. This makes it
difficult-to-impossible to use the nodes to implement a mapping
of traffic class to priority using YANG. In contrast, the nodes
in clause 17's ieee8021BridgeTrafficClassTable are correctly
aligned to 12.6.3, such that traffic class to priority mapping
can be configured with SNMP.
The mistake seems to have originated from use of Table 8-5 in 8.6.6.
Table 8-5 is intended to recommend a default mapping based on the
number of traffic classes (i.e. egress queues) supported by a product.
Table 8-5 does not represent the information model.
The "available traffic classes" of Table 8-5 is intended to be a
single value per port, as is reflected in ieee8021BridgePortNumTrafficClasses
of the MIB. In contrast, the YANG of traffic-class-table-grouping implements
Table 8-5 literally, with a list of all possible "available traffic class"
mappings (i.e. list of all possible default mappings). This sort of
list does not exist in an actual product. It is not clear if/how this list
can be used to configure an actual product.
Proposed text
The solution is to use the MIB as a guide to correctly model 12.6.3.
The following lists some proposed steps:
1. Add leaf "number-of-traffic-classes"
Add this leaf just above "container traffic-class" in the interface
augment (page 75). Type is uint8, range 1..8. Reference 12.6.3.1.
This leaf is analogous to ieee8021BridgePortNumTrafficClasses in MIB.
In MIB, ieee8021BridgePortNumTrafficClasses is read-write, with a
description that says "optionally read-only". The intent is presumably
that the default is the maximum supported by the product, but
configuration can write a smaller value. This raises the classical
problem of overlapping configuration with state, in that a write now
loses the information for the maximum supported. One could argue that
such overlap is not good practice for YANG. If that is a concern, we
can add an additional leaf "configure-number-of-traffic-classes"
(config true), and make "number-of-traffic-classes" config false
(read-only, to always obtain maximum).
2. Add new grouping "traffic-class-table-grouping-v2"
This grouping is similar to ieee8021BridgeTrafficClassTable in MIB.
It is a list indexed by priority. The elements of the list are
priority, and traffic class. Reference 12.6.3.2. In the description,
state that the default values for the table are specified in 8.6.6.
3. In the interface augment, add "container traffic-class-v2"
This uses traffic-class-table-grouping-v2.
4. Deprecate existing traffic-class table
In both "container traffic-class" and
"grouping traffic-class-table-grouping", add the statement
"status deprecated". As stated in RFC 7950 7.21.2:
""deprecated" indicates an obsolete definition, but it permits
new/continued implementation in order to foster interoperability
with older/existing implementations."
Impact on existing networks
As stated in item 4 above, if a product has successfully implemented
the 802.1Qcp-2018 traffic class mapping, that continues to operate as is.
Originator
| Name: | Rodney Cummings | Email: | Rodney.Cummings@ni.com |
| Affiliation: | National Instruments | ||
| Submitted: | 2019-06-06 | ||