| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Duane, I believe Glen’s email answers these more eloquently. Marek From: Duane Remein <Duane.Remein@xxxxxxxxxx> Marek, I clearly did not ask for a list of any sort. I ask 2 questions (numbered below for your understanding) and an observation that a power on reset that does not return the unit to a known state is a bad idea.
Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx] Duane, Are you then suggesting that we need to make a list of all the bad things that the NMS may choose to do (for whatever silly reason) and break the system? We added provisions for the ONU state to be discovered once registered, so that the OLT knows what the ONU can and cannot do. At the same time, if the primary channel is disabled by NMS, there is clearly something wrong with the NMS and given that the request comes from MAC Control client we do not prescribe the behavior of, I am not sure what we need to do in the spec to prevent that from doing without getting into second-guessing the NMS to begin with. The better question is what happens with the ONU if the primary channel fails – should be just dead or move the primary channel to another channel? Marek From: Duane Remein <Duane.Remein@xxxxxxxxxx> Marek/Glen, 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 |