Ryan, I like it. Below are a few adjustments (in red) to address the following: 1) align with the text of the attribute that follows this introduction text (“data rate”, Gbps instead of just G). 2) “must” is deprecated per IEEE Style manual. 3) Still don’t like using “configuration” here per the earlier discussion. See if you agree with “capabilities” in place of “configuration” “This attribute represents the EPON mode(s) supported by the given ONU. The ONU must only reports the data rate at which the ONU can fully instantiate. Full instantiation of a particular rate can depends on factors such as hardware capabilities configuration, both internal and pluggable to the ONU, software capabilities configuration, and other factors. As an example, an ONU that which has internal hardware capable of supporting a 50 Gb/s data rate, but an optical module only capable of supporting a 25 Gb/s rate must is not permitted to report a 25G 50 Gb/s data rate capability. ” Note that the draft uses Gb/s everywhere (>900 places). Gbps only used 18 times and all in this attribute. We should change it to Gb/s. Do we want to add a statement that reporting a support for a certain data rate does not imply that there is a service port (or UNI port) capable of operating at that rate? For example, a 25G ONU may only have 10G UNIs. Or is this part clear as is? Thank you, Glen Sorry, I’ve been tied up most of today and didn’t chime in. I’m going to try getting a little more wordy. Thoughts on this proposal: “This attribute represents the EPON mode(s) supported by the given ONU. The ONU must only report the rate at which the ONU can fully instantiate. Full instantiation of a particular rate can depend on factors such as hardware configuration, both internal and pluggable to the ONU, software configuration and other factors. As an example, an ONU which has internal hardware capable of supporting a 50G rate, but an optical module only capable of supporting a 25G rate must report a 25G rate capability. ” Thoughts? Ryan CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. Not quite. Mentioning non-volatile memory does not work either. The ONU could still implement a 'self-configure' and store the result of its finding into NVM. This way, the ONU would always boot with the last working mode. In this case you want to allow the ONU to declare support for multiple modes even-though it changes the content of NVM. The use of NVM is implementation detail. To me the distinction is more about if the ONU has some 'auto-detection' capability ('self-configure' as you call it) as opposed to a configuration change coming from outside. What about "This attribute represents the EPON mode(s) supported by the given ONU, i.e., the mode(s) that ONU can register under without any external intervention" ? I believe we are in agreement of what actions are not allowed in order for the ONU to declare support for multiple modes. The discussion we are having is about how to describe these clearly and concisely. I have concerns with both options that you proposed earlier. Option 1: This attribute represents the EPON mode(s) supported by the given ONU, i.e., the mode(s) that ONU can register under without any changes to any of ONU’s hardware, the installed firmware, or current configuration. “Current configuration” includes the present state of all ONU’s parameters/variables. And a change in configuration can be something completely benign, such as provisioning or removing a service port. Adding “or current configuration” is too broad and puts extremely high restriction on ability to declare mode as supported. I think any non-persistent changes in configuration are irrelevant here. Option 2: This attribute represents the EPON mode(s) supported by the given ONU in its current state This is similarly restrictive. An ONU that is currently operating in 25/25G mode is in 25/25G state. Clearly if it registers in 25/10 mode, it will be in a different state. To me “Current state” and “current configuration” are very similar concepts –basically an instantaneous snapshot of all ONU’s parameters. So, how about this proposal: This attribute represents the EPON mode(s) supported by the given ONU, i.e., the mode(s) that ONU can register under without any changes to any of ONU’s hardware, the installed firmware, or the contents of non-volatile memory. Does this capture what we were discussing? It is certainly not a common understanding nor something that can be implemented ;-) I am putting an explanation as PS. Definition of 'Firmware' aside, almost any existing ONU allow for some local configuration (web server/UNI port, CLI/UART,...) The use case is for a technician on site to activate the ONU (allow it on the PON), troubleshoot it or configure it. This could be used to change the behavior of the ONU wrt 25/10 and/or 25/20 registration. Let's first assume that the Firmware is restricted to one type of downloadable file. It does not mean it is the only type of downloadable file. It does not mean either that the file is exclusively composed of executable code. It can be a combo of application, bootloader, personality data,... Whatever it is, it is one file. Furthermore, this file has one version that the ONU can report using the sub-attribute aOnuFwVersion.sFirmwareVersion (2 Octets slim). Still under this assumption, if you subsequently download a personality file, then the sFirmwareVersion is not modified. Same for any other type of file, as long as it is not of type 'Firmware'. Now let's go with the assumption that 'anything downloadable' is part of firmware. Under this assumption, a download of a personality file would change the current 'firmware' and therefore modify sFirmwareVersion. sFirmwareVersion would actually have to uniquely identify the set of 'downloadables' currently present on the ONU. Again this sub-attribute is 2 Octets slim. Oh, yes, with that I agree. But I assumed the personality file, or BIOS, or boot initialization data, all fall under a wider umbrella term “firmware”. Firmware is everything downloadable into the ONU. If that is not a common understanding, we should clarify that. You are correct, I only consider configuration something that is done externally. If it is internal, then I see it as nothing more than a variable. One example of configuration would be: - the download of a file. In my previous life at BRCM, we could download a personality file to the ONU. - a web server accessible via wifi or uni port where you can change some settings. Some existing ONUs have such interface for a firmware upgrade or MAC address changes. So in your example, if the ONU does not have the 'self-configure' function but could support either mode via a change of configuration (again done externally), then I would not think that the ONU should report that it supports anything else than the mode it is currently configured in. Does this make more sense? I’d like to clarify what you propose. Let’s say an ONU currently runs in 25/25G mode. But it can also register in 25/10G mode without any changes to HW or the SW. However, to register under 25/10G mode, the ONU would parse the DISCOVERY GATE and based on the Discovery Info, it would self-configure. For example, it would change the upstream EQT from 2.56 ns to 6.4 ns. Would that self-configuration violate the condition “without any changes to … current configuration”? If this auto-configuration is ok, could you give an example of a configuration action that would not be ok for declaring a mode as supported? I think you also need to add « or current configuration ». Alternatively, you can simply say « … supported by the given ONU in its current state » Further to our discussion on clarifying the aLineRateMode meaning, how about we use the following introduction sentence: This attribute represents the EPON mode(s) supported by the given ONU, i.e., the mode(s) that ONU can register under without any changes to any of ONU’s hardware or the installed firmware. Removed 1G and 2G rates and updated bit alignment. Great points on the 1G and 2G as this is a different branch and aren’t needed for implementations that may require those different rates. The branches in 1904.1 are unique and still provide attributes that can be used if 802.3ah/802.3av versions need to be supported in a particular implementation. I will refactor the assignments and update the discussion item. If time permits, I think it would still be good to discuss on the consensus call this evening. CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. Perhaps my view is a tad naive but ... I thought 1904.1 covered 1G-EPON (802.3ah) and 10G-EPON (802.3av) while 1904.4 would cover Nx25G-EPON only (802.3ca). That is what the PAR says right now - we have references to .3ca, Nx25G-EPON all over the place but no references to 1G-EPON and/or 10G-EPON at all. In this case, the whole point of distinguishing 10G rate from .3av and 10G rate from .3ca is kind of moot - the attribute is in a different branch and we likely might need to strike 1G rates altogether since they are not part of Nx25G-EPON spec right now. The NMS receiving response from this branch knows that the ONU is a Nx25G-EPON device, and not a 10G-EPON device in disguise. If there was a hypothetical device able of supporting .3ca and .3av, I would think that it would be discovered on either of the rates, i.e., NMS would discover 1904.1 devices first and then 1904.4 devices, and provision depending on the selected mode of operation it desires for the ONU, using the target branch attributes specific to 1904.1 or 1904.4 spec. I would really prefer we do not muddy waters by introducing .3av specific modes into .3ca management spec. Granted, we do share the OUI with Package A from 1904.1 so that does add a bit of a contention right now and potential source of confusion - we do re-use some of the basic attributes (0x07) and basic actions (0x09) between 1904.1 and 1904.4, but even some of them might be changed. For example, action item #32 resulted in a suggestion to drop the aFecMode attribute, which makes no sense for Nx25G-EPON at all. It does make sense in 1G-EPON and 10G-EPON. Do we need a new "Basic Attribute" branch that does not include aFecMode? Perhaps this attribute should be marked as not supported in Nx25G-EPON, simply, if we want to maintain this branch and all attributes contained within unchanged? Thank you for sharing the contribution. The added options are all fine and the description is consistent with what we had before. But as I was reading through this document, I realized that it is not clear what exactly this attribute represents. This attribute (as is the entire branch 0xDB) can only be used when ONU operates in 25G or 50G mode (i.e., compliant with 1904.4). But if the ONU is operating in 25G mode and this attribute reports that 10G downstream and 10G upstream are supported, does this mean that ONU ASIC supports these rates, or both ASIC and optics support them? Does it also mean that hardware can support both 802.3ca and 802.3av and the software can fully support both 1904.4 and 1904.1? I think we should use our consensus call tomorrow (if we have time) to discuss and clarify the exact meaning of “supported mode”. I am thinking that we should define it as a mode that ONU device can register under without any changes to any of its hardware or the installed firmware. We also may need to distinguish 802.3av from 802.3ca flavor for the 10G upstream rate. I’ve attached my suggested updates for Item 23 on the action log. Please let me know if there are any questions/concerns/suggestions. The contents of this e-mail message and
any attachments are intended solely for the
addressee(s) and may contain confidential
and/or legally privileged information. If you
are not the intended recipient of this message
or if this message has been addressed to you
in error, please immediately alert the sender
by reply e-mail and then delete this message
and any attachments. If you are not the
intended recipient, you are notified that
any use, dissemination, distribution, copying,
or storage of this message or any attachment
is strictly prohibited.
The contents of this e-mail message and
any attachments are intended solely for the
addressee(s) and may contain confidential
and/or legally privileged information. If you
are not the intended recipient of this message
or if this message has been addressed to you
in error, please immediately alert the sender
by reply e-mail and then delete this message
and any attachments. If you are not the
intended recipient, you are notified that
any use, dissemination, distribution, copying,
or storage of this message or any attachment
is strictly prohibited.
The contents of this e-mail message and
any attachments are intended solely for the
addressee(s) and may contain confidential
and/or legally privileged information. If you
are not the intended recipient of this message
or if this message has been addressed to you
in error, please immediately alert the sender
by reply e-mail and then delete this message
and any attachments. If you are not the
intended recipient, you are notified that
any use, dissemination, distribution, copying,
or storage of this message or any attachment
is strictly prohibited.
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
|