| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Seems like a valid scenario to me, Glen. Thanks for brining it up! From: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxx> Duane, I’ve been thinking about the channel control protocol flexibility and your comments below. I am still convinced that EPON operators should have the ability to turn off a malfunctioning or malicious ONU channels permanently to keep the rest of EPON operational. But I also see a situation where this can have unintended consequences. Here is one hypothetical scenario: Let’s say, an operator is hunting for a rogue ONU in a network. To find such rogue ONU, the operator may need to temporary disable transmit channels in all ONUs one by one. Once a rogue ONU is determined (say, by analyzing the receive signal power signature), all good ONUs need to be brought back (i.e., their channels enabled). But in the meantime, if a good ONU is reset by user, this ONU will become unregistered with its transmit channel disabled and it won’t be able to register again. I am thinking we need to add a Persistence bit to our Action Code. We currently use only 2 bits out of 8. We can allocate one bit for Persistence flag. The persistence bit would have these values: 0 – Requested action persists until ONU reset, then revert back to the default state. 1 – Requested action persists until explicitly changed by the OLT. Another way to look at it – When persistence bit is 1, the ONU shall implement the requested action and change its default state to be the new channel state. When persistence bit is 0, ONU implements the requested action, but does not change its default. Upon reboot, ONU always starts it its default state. To hunt for Rogue ONU, the OLT will disable channels on all ONUs with persistence 0. If/when a rogue ONU is found, the OLT will disable its channels with persistence 1. Any thoughts? -Glen From: Glen Kramer [mailto:glen.kramer@xxxxxxxxxxxx] 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 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 |