Marek, Just to let you know I did not forget about this. I will provide my feedback by the end of the week. Thanks, Glen Thank you, Glen Here is the second pass at the AI#13 Regards Marek Hi Marek, What you wrote in red below is principally correct. I may have additional feedback when I see the complete proposal. I agree that the fragmentation support will be a big new section. I am not sure C8 is the right place for it. It seems to me this material belongs to C6. But this is a separate task. Glen From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx> Sent: Thursday, September 30, 2021 12:49 PM To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx Subject: Re: [1904.4 TF] Action item #13 Just checking back if you have any additional feedback before I make updates to the proposed solution Some comments / feedback inline 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
![](pngmonHmGA8JZ.png)
- 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 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: - remove "12.2.1 DPoE eOAM management" (no more profiles) and promote all subclauses by one level - remove "12.3.1 Software upgrade using DPoE eOAM management" (no more profiles) and promote all subclauses by one level, merge text from under 12.3.1 into 12.3 - replace all references to 1G/10G-EPON MPCP with 802.3ca, 144.3.7 - fix cross references to all figures and subclauses in Clause 12 itself - replace references to 13.4 and 14.4 (no more profiles) with Clause 13 and Clause 14, respectively - update all references to subclauses and tables in Clause 13 and Clause 14 with proper references - replace "The eOAM version negotiation phase, such as the one described in 12.2.1, is not used in this profile, and tThe OLT is expected to support all the versions of the eOAM management suite that are supported by the fielded ONUs connected to its ports. " with "The OLT is expected to support all the versions of the eOAM management suite that are supported by the fielded ONUs connected to its ports. " since there are no more profiles. - strike 4 instances of "complying with the requirements of this profile" - there are no more profiles - strike "for this profile " - there are no more profiles | See tf4_2110_hajduczenia_01.pdf for all the tracked changes to Clause 12. Update PICS (not covered in this contribution) | Technical | Yes | 246 | 13 | 1 | Action Item #13 requires updates to Clause 13 content as follows: - remove all references to profile by striking the following statements: "specified in this profile" (3x), ", and defined by this profile" (3x), " used by this profile", "specified for this profile" (3x), "for this profile" (3x), and "required for compliance with this profile " - we do not have profiles anymore - revise Table 13-5, Version field, to use only value 0x30 to signal compliance with IEEE Std 1904.4. All other values are reserved for backward compatibility | See tf4_2110_hajduczenia_02.pdf for all the tracked changes to Clause 13. Update PICS (not covered in this contribution) |
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
|