Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_NGEPON] Comment # 552 againse D2.21



Duane,

 

You cannot change your vote as there are still 3 unsatisfied comments against D2.0 recorded to your name. Maybe some of those comments got further resolved through later changes in D2.1, and you are now satisfied with the resolution.  But you need to tell Marek that, so he can record the new status.

 

You can see the remaining unsatisfied comments against D2.0 here: http://www.ieee802.org/3/ca/comments/802d3ca_D2_0_unsatisfied_20190912.pdf

Thank you. We missed you here.

 

-Glen

 

From: Duane Remein [mailto:dremein@xxxxxxxxx]
Sent: Thursday, September 12, 2019 10:12 AM
To: mxhajduczenia@xxxxxxxxx; Glen Kramer <glen.kramer@xxxxxxxxxxxx>; stds-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Cc: Curtis (CableLabs) <c.knittle@xxxxxxxxxxxxx>; Glen Kramer <gkramer@xxxxxxxxxxxx>; 'David Law' <David_Law@xxxxxxxx>
Subject: Re: Comment # 552 againse D2.21

 

Curtis/Marek,

Given the approved response to Comment 552 against Draft 2.1 please mark this comment response as accepted by me.  I would also like to change my vote on the draft to approve with comments.

Best Regards

Duane

On 9/10/2019 4:42 PM, Duane Remein wrote:

I would not view that as an acceptable response to a required comment.

Duane

On 9/10/2019 12:52 PM, Marek Hajduczenia wrote:

Would we be then OK to have the note struck altogether and not even get into the debate in what is – after all – nothing more than an informative note?

 

Marek

 

From: Duane Remein <dremein@xxxxxxxxx>
Sent: Tuesday, September 10, 2019 10:50 AM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; 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

 

Glen,

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.

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
-- 
Duane Remein
Raleigh, NC
-- 
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