Requested revision
Standard: | 802.1Q-2018 | Clause: | 8.6.5.1 |
Clause title: | Per-stream filtering and policing |
Rationale for revision
Figure 8-13 is missing the the stream_handle parameter (8.6.5.1.1b),
thus making it impossible to determine the difference between frames
handled in the first box (Stream ID 1) and the second box (Stream ID 2).
The Stream ID field (8.6.5.1.1a) is an index into the stream filter table;
in this case we are talking about the first two entries in that table (Stream
ID 1 & Stream ID 2).
The priority (8.6.5.1.1c) is the same in both boxes, so that can't be used
to determine which entry the frame should use.
Read the last paragraph on page 195, right before NOTE 2. It says that the
stream_handle and priority parameters are used to determine which stream filter
(Stream ID index into table) to use. This supports my argument that we are
missing the stream_handle from the boxes.
The other fields (Gate ID, Filters, Meter ID, Counters) are used, once the
table entry is looked up, to decide where to send the frame next.
Since the stream_handle (8.6.5.1.1b) is missing from this diagram it is
impossible to determine which of the first two table entries a priority 3
frame would use.
I believe this happened between D1.1 and D1.2 of Qci when we added
stream_handle, but never updated the figure.
My guess would be that when we worked on Qci we knew it was CB's
stream_handle that we needed and somehow falsely assumed
that Stream ID was really stream_handle, therefore we could use it to
send the frames through the appropriate box. That is incorrect.
Proposed text
Update Figure 8-13 to add stream_handle to each of the four boxes within the
dashed Stream Filters box. In the first two boxes we should assign different
stream_handles and add a note to the figure that says those stream_handle
values are assigned via 802.1CB.
The third box should also use a unique stream_handle since it matches every
priority and the earliest matching entry will be used; if we put a wild_card
stream_handle here then no frames would go to the fourth box.
FYI: From the paragraph on page 195 before NOTE 2: "If the stream_handle
and priority parameters associated with a received frame match more than one
stream filter, the stream filter that is selected is the one that appears earliest
in the ordered list."
Since Stream ID 3 is earlier in the list than Stream ID N, no frames would
go to Stream ID N if stream_handle and priority are both wild_carded.
The fourth box could assign the wild-card value "*" to the stream_handle, just
so we have an example of that in the figure. That would say that all priority 2
frames use this box.
FYI: NOTE 3 on page 195 defines the stream_handle wild-card value as the
null value, however we use "*" in the figure.
Impact on existing networks
None. There is no other way this could be implemented, therefore it is
just "understood" by those that worked on the standard.
Originator
Name: | Craig Gunther | Email: | craiggunther@yahoo.com |
Affiliation: | Craig Gunther Consulting | ||
Submitted: | 2020-01-14 |