| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I have an issue with one detail of this proposal and a question or two. On slide 3 you state “ONU shall preserve channel state across power cycle”. This is a very bad idea. We have often discussed that an OLT might only perform discovery on Ch0. If the NMS disables Ch0 and then
the ONU gets power cycled it will become stranded and force a truck roll and the “malfunctioning” ONU returned to the manufacturer for repair. A power cycle should always return a device to a known state. For the ONU this means it should be ready to be discovered
on any channel it is capable of operating on (unless we decide that discovery is only allowed on Ch0, which I wouldn’t recommend). The OLT should have a shadow copy of the ONUs provisioning and, after reregistration, return it to a specific configuration
if so desired (or maybe something else if pre-provisioning is allowed). My question has to do with what is an ONU to do if it gets conflicting information from the OLT, for example a GATE granting time on a disabled channel. Should such a GATE be considered invalid and thus time
granted in the same GATE on an enabled channel disallowed or should only the offending grant be disallowed? I would expect that the OLT would be intelligent enough to understand which channels each subtended ONU is able to use and thus this invalid granting
should not happen. But as we know errors occur. Will a statistics counter be added to the ONU to count GATES granting time on disabled channels? I believe these questions should be answered in the presentation before adoption. Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Dear colleagues, Attached please find the deck with two minor updates per discussion (thank you!) on the call today:
As the next step, I will work on a contribution to accompany a comment against D1.3 and bring in all missing details for subclause 144.4 Regards Marek From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Curtis, I would like to request 45 minutes’ slot on the call to go over the attached document on CCP. The main intention here is to go over the CCP functional requirements we covered some time ago, CCPDU details, and then expected CCP behavior.
Once we have consensus on these items, material for draft will be prepared and if in time – submitted against D1.3 for discussion at the meeting.
Regards Marek From: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>
Dear Colleagues, We have an 802.3ca consensus-building meeting this Thursday, August 16, 11:30 am MST. Please let me know by 5:00 pm MST Wednesday 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 |