Some comments / feedback inline
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Thursday, September 2, 2021 11:29 AM
To: mxhajduczenia@xxxxxxxxx; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] Action item #13
Marek,
The attached contributions look good to me. Below are a few points of additional feedback.
- I am not sure both of the comments below have anything to do with the action item #13. [mh0902] Fair observation, I can certainly just submit them as standalone cleanup of the respective clauses but it would require me to pull out changes to Table 13-5 into a separate change set. Not a big deal, just saying
- It would be good to mention somewhere in clause 12 that OAM discovery only takes place once per ONU device and it uses primary MLID for that. [mh0902] Good point, text was added as shown below
- It is conceivable that as time passes, both OLT and ONUs will support multiple OAM versions. And it is also conceivable that an ONU may have a version newer than what the OLT supports. Without a version negotiation, how will the OLT and ONU agree on what version to use? This item is just an invitation to discussion. [mh0902] The easiest way to address it would be to bring back the version negotiation covered in 1904.1, 12.2.1.2.2. Looking through it, it seems like it does not require additional messages defined, just needs to be copied into the document and used. I wonder, though, how it is addressed today in DPoE systems, where the version conflict is conceivable (newer ONU with newer OAM running against OLT with older OAM version)
Also here are several questions related to item #13. Mostly, these are points that we need to discuss either on the reflector or on consensus call.
- Do we want one compound attribute to query multiple different capabilities, or we use separate attribute for each capability? [mh0902] I can see advantages to both approaches but I figured a single attribute is easier to find among all other attributes we already have. We have space in the TLV, so one could argue that have multiple separate TLVs increases overhead to get the same amount of information through. However, with the channel support likely punned to CCP, and fragmentation support punned to separate attributes (per ONU and per LLID), we might not need a generic capability attribute anymore.
- We already have Channel Control Protocol and CCPDU Query message in 802.3ca that allows us to query ONU’s channel support capabilities. Do we duplicate this functionality in Extended OAM, or just use CCPDUs for that? I see pros and cons for both methods. [mh0902] I see no reason to have CCP duplicated in OAM 😊
- For fragmentation support, we may need to know more than just a Boolean. Fragmentation requires dedicated memory and control logic per each fragmentable LLID. But ONU may not need or may not be able to provide that resource for every LLID. Also, do we need to support jumbo frame fragmentation for every LLID? This would require 10K buffer per LLID, which may be a huge waste of resources. So, I am thinking the capability query response would need to tell how much fragmentation memory it has in total, how many fragmentable LLIDs it can support (only matters for bidirectional LLIDs). This RO attribute would be under the ONU context. We probably will have to specify an additional attribute to provision fragmentation buffer size per LLID. This has to be a RW attribute to provision (W) and to query (R ) the fragmentation buffer size under the context of LLID. [mh0902] So to recap, the ONU-context attribute (RO) would need (a) total memory available for fragmentation buffers (in kB?), (b) number of LLIDs with fragmentation support; while the LLID-context attribute (RW) would need (a) size of fragmentation buffer (in kB?), (b) enable / disable fragmentation for the LLID. Am I missing anything? I think we should also add text somewhere in Clause 8 to discuss fragmentation and impact of it , ability to set fragmentation thresholds per LLID and in the function of the target MTU to be supported.
Glen
From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Wednesday, September 1, 2021 4:51 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: [1904.4 TF] Action item #13
Dear colleagues,
I started working on Action Item #13 and went through the cleanup of Clause 12 and Clause 13, resulting in the two following comments and attached contributions.
Technical | Yes | 229 | 12 | 1 | Action Item #13 requires updates to Clause 12 content as follows: | See tf4_2110_hajduczenia_01.pdf for all the tracked changes to Clause 12. |
Technical | Yes | 246 | 13 | 1 | Action Item #13 requires updates to Clause 13 content as follows: | See tf4_2110_hajduczenia_02.pdf for all the tracked changes to Clause 13. |
Apart from editorial and small technical changes (e.g., remove any references to profile, since we do not do profiles anymore in 1904.4), the largest change I wanted to signal was in Table 13-5 (Information TLV), which contains the eOAM version information. I suggest we use 0x30, which is backward compatible with 1904.1 versions used for Package A, and signals a new version block. I do not expect a lot of revisions to 1904.1, but we still have more than 10 possible minor revisions available. I believe it is plenty.
Now, Action Item #13 calls also for new ONU capability discovery
13 | Device and capability discovery | New 802.3ca behavior | New capabilities (fragmentation, multiple channels, etc.) |
covering fragmentation, multiple channels, etc. Rather than cram them into the Information TLV, I suggest we create a new capability TLV under 0xDB branch, and create entries for following capabilities:
Support for downstream fragmentation (Boolean)
Support for upstream fragmentation (Boolean)
Number of downstream channels supported (int, 1 byte)
Number of upstream channels supported (int, 1 byte)
These 4 entries exhaust the capabilities I can think of and that are not otherwise covered elsewhere. To follow up, we might want to allow for fragmentation to be disabled (R/W) in downstream and upstream directions, but I am struggling to find a reason to change the number of channels supported.
Are there any other capabilities we should be reporting for the ONU that are specific to 803.3ca systems?
Thank you
Marek
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1