For 1) and 2) I tend to agree with Marek in that we keep it simple, at least for this attribute. Something else I was thinking about is some of the different
PMDs as part of 25G/50G (i.e. ##/## PQ30G vs. PQ30X) and would it makes sense to add another attribute to include some of that information, although it could be overkill. This could be a way to provide some of that additional context you were referring to
although it may still point back to the transceiver support. I was going to bring that up as a strawman topic on the call just to see what type of interest there was on it.
As for 3), yes I missed that.
For 4) as Marek mentioned, I was thinking that we could just reuse the current attributes for 1904.1. Since the OLT also has to support these functions it would
probably be able to also infer which attributes to probe in terms of support on the ONU.
Ryan
From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Tuesday, July 13, 2021 2:38 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Cc: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>; Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [EXTERNAL] Re: [1904.4 TF] Action Item #23
CAUTION: The e-mail below is from an external source. Please exercise caution before
opening attachments, clicking links, or following guidance.
As far as 4) is concerned, we already have a way to query such an ONU, just using a separate branch of attributes we already have defined in 1904.1. Otherwise, it would be more natural to just extend 1904.1 existing attributes to support
Nx25G-EPON and not create separate attribute branches.
In the case of 2) and 1), I think we report only what the ONU can physically do, i.e., even if the ASIC is 50G capable, the ONU cannot do 50G because it is limited by installed optics. It makes little sense to me to report it can do 50G
and all intermediate other rates if the ONU as a whole has no way to participate in the other data channels.
For 3), yes, I believe we should nuke it - I overlooked it
It is still not entirely clear. I break it into few specific examples:
1)
Let’s take as an example an ONU consisting of 802.3ca-compliant ASIC that can do both 25G and 50G. The optics is 25G only. Do we report it as supporting 25G upstream and 25G
downstream only?
2)
If an ONU reports that it is 50G capable, does this also implies 25G capable? Under what circumstances the
sDownstream25G sub-attribute won’t be reported as “yes”?
3)
The 802.3ca does not provide the 10G downstream option. Do we need the
sDownstream10G sub-attribute?
4)
I am not completely sure about this one, but if an ONU has registered and is operating on a 25G-EPON, don’t we want an ability to query that ONU to know that it can also register
and operate at 1G or 10G? I know it is very unlikely that ONU’s optical module will include all .3ca and .3av wavelengths. But I think there is a difference between being able to ask, even if the answer is almost always no, and not being able to ask at all.
Glen
Removed 1G and 2G rates and updated bit alignment.
Ryan
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
Sent: Monday, July 12, 2021 8:40 PM
To: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Cc: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>;
STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] Re: [1904.4 TF] Action Item #23
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?
Hi Ryan,
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.
Regards,
Glen
Hi All
I’ve attached my suggested updates for Item 23 on the action log.
Please let me know if there are any questions/concerns/suggestions.
Thanks
Ryan
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
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
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
|