I don't disagree with anything you say below but you fail to point out a few pertinent points.
I agree that "it is not hard to devise a downstream message" but as it stands this is more properly stated as "it is not hard to devise a proprietary downstream message". Given the the standard says that an unregistered ONU, which we agree applies to this case, is only to listen to DISCOVERY messages anything else is outside the standard.
We certainly could "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" but right now we don't so that too is outside the standard at this time.
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.
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."