| 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]
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. [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. [drr] – ONUs power cycle for may reasons not just due to a “stupid OLT”. I’m just saying that power cycling should bring the ONU to a known state, regardless of what has happened in the past. [GK: ] If the OLT has turned an ONU’s channel off, we must assume it had a good reason to do so. ONU shall not undo that simply because user decided to power-cycle it.
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. [drr] – If this is the case (and the operator has failed to roll a truck to correct this situation) then the OLT should be smart enough not to re-discover this known ONU with a fault to do so on the faulty channel. [GK: ] Truck roll takes many hours. Meanwhile, a faulty ONU that is being rebooted by user every few minutes keeps bringing the entire network down, right? And by the way, how do you “not rediscover” this faulty ONU? There is no way to exclude an unregistered ONU from participating in discovery (except by instructing it to shut down one of its channels and then do the discovery on that exact channel!).
Enabling/disabling the channel is a key capability that affects network resilience. I would completely agree that provisioned ULIDs, classification rules, VLANs, etc. all should reset to their default states upon reboot. But not the channel states. MCRS channels are somewhat similar to ports on a switch or a bridge. And 802.3 requires port states to be preserved across power reset.
30.3.2.1.7 aPhyAdminState BEHAVIOUR DEFINED AS: A disabled PHY neither transmits nor receives. The PHY shall be explicitly enabled to restore operation. The acPhyAdminControl action provides this ability. The port enable/disable function as reported by this attribute is preserved across DTE reset including loss of power.
30.4.3.1.2 aPortAdminState BEHAVIOUR DEFINED AS: A disabled port neither transmits nor receives. The port shall be explicitly enabled to restore operation. The acPortAdminControl action provides this ability. The port enable/disable function as reported by this attribute is preserved across repeater reset including loss of power.
30.12.1.1.1 aLldpXdot3PortConfigTLVsTxEnable BEHAVIOUR DEFINED AS: … The value of this attribute is preserved across reset including loss of power. Glen
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 |