| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I grabbed the wrong attachment, please ignore the previous one. Sorry. Best Regards Duane From: Duane Remein Marek, See attached. This includes specific wording about the requirement which I now see is not quite what I had read it as earlier. Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Duane, This requirement does come from the last contribution version discussed on Thursday – please check the last slide in the deck. All I did was put some language around it, to make sure it looks more standard-like. Recall that the consensus
on the call was that the ONU would not have any defaults, and would always wait for the announcement from the OLT to collect necessary sync pattern information. The OLT would have defaults set that can be used unless the vendor wants to override these defaults
with their own optimized settings. Again, we discussed it multiple times before.
Comments on PDF would be welcome – I will consume them, update the document, and send out a revised version, when possible.
Regards Marek From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Marek, Thank you for this preview. I have one major comment. You have the requirement: “By default, the OLT shall announce the two Sync Pattern zones, i.e., SP1 and SP2, setting SpCount in the SYNC_PATTERN MPCPDU to the value of two (2).” I think this is backwards, the requirement should be on the ONU to use this as the default so the OLT doesn’t need to announce anything if it so chooses. The OLT can use something different if it so chooses,
in which case it needs to announce that, otherwise it can skip all transmission of SYNC_PATTERN MPCPDUs. I also have several other, less critical, comments which I can provide in a PDF mark-up or I can make after this gets into the draft. Just let me know your preference. Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
… and here is the last part of the contribution, covering burst structure for Clause 143, together with the drawings.
From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
... and here is the updated PDF with changes to Clause 144 to address the latest version of the proposal. PDF with changes to Clause 143 is pending and should be available after the weekend
Regards Marek From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Curtis et al., Attached please find the updated deck from today’s call, including all changes needed to address comments received. Now that we have tentative consensus and no new open technical concerns were raised I will update the Frame source for MPCP
and PCS clauses and share them on the reflector in the coming days for preview and discussion on the next call.
Regards Marek From: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>
Dear Colleagues, Apologies for the late request for agenda topics. We have an 802.3ca consensus-building meeting this Thursday, April 12, 11:30 am MST. Please let me know by 5:00 pm MST today if you have any contributions for this meeting. Curtis Curtis Knittle VP Wired Technologies – R&D CableLabs desk: +1-303-661-3851 mobile: +1-303-589-6869 Stay up to date with CableLabs: Read the blog and
follow us on Twitter To unsubscribe from the STDS-802-3-NGEPON list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 To unsubscribe from the STDS-802-3-NGEPON list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 To unsubscribe from the STDS-802-3-NGEPON list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 To unsubscribe from the STDS-802-3-NGEPON list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 |
Attachment:
hajduczenia_3ca_3d_0518_drr.pdf
Description: hajduczenia_3ca_3d_0518_drr.pdf