Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Removed 1G and 2G rates and updated bit alignment. Ryan From: Tucker, Ryan R
Gentlemen 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. Ryan From:
stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
On Behalf Of Marek Hajduczenia
CAUTION: The e-mail below is from an external source. Please exercise caution before
opening attachments, clicking links, or following guidance. Glen, 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?
Marek On Mon, Jul 12, 2021 at 6:28 PM Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
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 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 |
Attachment:
tf4_2108_tucker_01.docx
Description: tf4_2108_tucker_01.docx