Re: [802.3_NGEPON] Comment # 552 againse D2.21
I am personally OK with simpler text, as long as it gives us sufficient level of detail of what to expect when the ONU is disabled. Also, please note that the operators do not treat standards as complete and comprehensive operational guidelines - we do create internal documents describing procedures covering specific use cases, situations, ONU recovery, etc. This would be no different and likely warrant a method of procedure description on how an ONU would be recovered in case it had to have all of its channels disabled.
To be honest, I am not sure we need such notes peppered in the text to begin with - yes, bad things will happen it one chooses to shut down all channels on ONU but that is only expected, right? We have (likely) plenty of other functions and mechanisms in place that when misused may result in a bricked ONU. I am not quite sure what is so special in this case that a warning note is really warranted.
Marek
-----Original Message-----
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Tuesday, September 10, 2019 8:01 AM
To: Duane Remein <dremein@xxxxxxxxx>; stds-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Cc: Curtis (CableLabs) <c.knittle@xxxxxxxxxxxxx>; Glen Kramer <gkramer@xxxxxxxxxxxx>; Hajduczenia, Marek <Marek.Hajduczenia@xxxxxxxxxxx>
Subject: RE: Comment # 552 againse D2.21
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