| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Duane,  Please, see below.  -Glen  From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]  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. [GK: ] Ah, so what you are saying is the ONU should be intelligent to save itself from the stupid OLT? Well, if ONU can have that intelligence, the very same intelligence can be placed in the OLT, cannot it? At least the OLT interfaces with NMS and has a view of the entire network.  OLT may perform discovery only on channel 0 if all ONUs can receive that channel. But if not all ONUs can receive channel 0, then OLT will perform discovery on other channels as well. OLT know which ONUs have channel 0 disabled.  A power cycle should always return a device to a known state.  [GK: ] It does. It returns it to the last state that operator provisioned. This is 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).  [GK: ] So, letâ??s say a malfunctioning ONU has a laser â??stuck in 1â??. If the OLT determined that a laser in ONU X has failed, it would turn it off and let the rest of the network operate. But if the ONU is allowed to return to its default state after reboot, then every time the user reboots, the ONU would take the network down again. OLT should be able to turn off channels and even brick the ONU if it is necessary in order to save the rest of EPON. The ONU may not like it, but it does not have as much information as available to the OLT.  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? [GK: ] As we discussed on the call, this is already handled by GATE Reception SD (see VALIDATE_CHANNELS state). The multi-channel GATE is still valid for other channels that are not disabled.   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. [GK: ] We have not had any discussion on what statistics we need to collect. How come we have adopted so many state diagram in MPCP, MCRS,  and PCS without discussing the associated collection of statistics, and now this becomes a roadblock for this one simple protocol?    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 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 |