| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Glen, I don't disagree with anything you say below but you fail to
point out a few pertinent points. I find myself agreeing with Merak; there is really no need to go into if and how an ONU could be remotely reset, or re-provision this case. The KISS principle applies here I think. Best Regards, Duane On 9/10/2019 10:01 AM, Glen Kramer
wrote:
Duane, Let's break this into two separate questions. The first one is whether it is possible to re-enable an ONU remotely. The second question is whether we should describe this in the 802.3ca draft. #1. If an ONU has all of its transmit channels disabled (but not all receive channels), it will become deregistered, either explicitly by the NMS or due to MPCP timeout. That part is true. But it does continue listening to the downstream channels, and it is not hard to devise a downstream message or a sequence of messages that by convention would cause the ONU to re-enable one or all of its transmit channels. As an example, we can require the ONU to re-enable UC0 if it receives a DISCOVERY MPCPDU with the DISC_PLID and the DA matching the MAC address of that specific ONU. Another possibility is to send CC_REQUEST to that ONU on DISC_PLID and unicast MAC. This is not very different from the rogue ONU mitigation mechanisms in G.Sup49: "Those ONUs should remain Disabled and not transmit data on the PON until directed to by the OLT. The OLT may further attempt to enable the suspected ONUs one-by-one in order to identify the rogue ONU." #2. Even though it is possible to re-enable an ONU remotely, maybe there are reasons to not cover it in 802.3ca. I think the TF should discuss this at the meeting this week. If we decide to not describe this in the .3ca draft, then your proposed text is reasonable. -Glen -----Original Message----- From: Duane Remein [mailto:dremein@xxxxxxxxx] Sent: Monday, September 09, 2019 11:33 AM To: stds-802-3-NGEPON@xxxxxxxxxxxxxxxxx Cc: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>; Glen Kramer <gkramer@xxxxxxxxxxxx>; Marek Hajduczenia <Marek.Hajduczenia@xxxxxxxxxxx> Subject: Comment # 552 againse D2.21 I take issue with the proposed response to this comment: NOTE-Persistently disabling all downstream channels in an ONU makes that ONU nonoperational and may require ONU replacement or a specific re-initialization via a local craft port. Persistently disabling all upstream channels in an ONU (but not all downstream channels) also makes that ONU non-operational. However, it may be possible to reinitialize such ONU remotely. Both the remote and the local re-initialization procedures are outside the scope of this standard. I do not see how the following statement can be true "However, it may be possible to reinitialize such ONU remotely". First off the persistent nature of the action requires reprovisioning, not simply a reset, remote or otherwise. The standard clearly states that if the US channel is disabled the ONU should be de-registered and require a new Discovery. Once de-registered the ONU should only listen for Discovery windows per the draft. How then can this statement be true? " if the OLT and ONU are compliant with the standard? I would be OK with the following: "NOTE-Persistently disabling all downstream or all upstream channels in an ONU makes that ONU nonoperational and may require ONU replacement or a specific re-initialization via a local craft port." -- Duane Remein Raleigh, NC 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 |