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

Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes



Duane, et al.,

 

Attached is the revised deck which I hope addresses some of your concerns. You will notice the maximum values were removed from repeat count fields for individual sync patterns and they will not be present in Frame file either. If there are additional restrictions we need to place on the values, my recommendation would be to add these in PCS clause, where we define pattern values, and describe how individual sync pattern zones work. These restrictions should be transparent to MPCP clause definitions, since MPCP does not care what the actual value is carried in the message, as long as it fits into the prepared field in it.

 

Further comments are welcome. Given the changes in the deck, I would like to go over the deck again on the next call and emphasize changes done

 

Regards

 

Marek

 

From: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxx>
Sent: Thursday, April 19, 2018 1:43 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

Duane,

 

In 10G-EPON, just like in 25G, laser_on time and burst preamble (AGC and CDR) were all variable quantities. We have only maximum limits specified for Ton, Treceiver_settling, and Tcdr. The actual values were implementation dependent and they were announced to the ONU. 

 

The delay line in 10G-EPON ONU Data Detector was not fixed to any value. The ONU needed to set it based on SyncTime parameter it received first in the DISCOVERY GATE, then again (and possibly a different value) in the REGISTER message. Marek's proposal follows the same idea, only instead of a single SyncTime parameter, we now split it in 3 values to allow different patterns.  

So, as I said earlier, if .3ca sets maximum permissible values for Ton, Tsettling, and Tcdr, that will implicitly set the maximum limit for the DD delay line (again, as it was done in 10G-EPON).

 

Glen

(Sent from Samsung Galaxy far, far away, where typos are normal)

 

On Thu, Apr 19, 2018, 12:18 PM Duane Remein <Duane.Remein@xxxxxxxxxx> wrote:

Glen,

Perhaps you missed my first comment.  I copy it here for your convenience (empheis added).

 

In 10G-EPON we incorporated the Data Detector mechanism to determine when the beginning of the burst should occur.  The mechanism depended on a delay line that essentially matched the duration of burst preamble, burst delimiter and laser on time (i.e., sync time).  In 10G-EPON this was a fixed duration.  We have now made that duration variable and of arbitrary size through the setting of SP1, SP2 and SP3 and any repeats. 

What will the ONU be expected to accommodate with respect to maximum delay needed?  

Without placing a bound on this total time I don’t see how we can claim technical feasibility.  If some OLT vendor decides a very long sync time is OK per the standard and an ONU cannot accommodate that long time interoperability is not achieved, neither device is non-compliant and we have not achieved our goals.

Best Regards

Duane

 

From: Glen Kramer [mailto:glen.kramer@xxxxxxxxxxxx]
Sent: Thursday, April 19, 2018 12:32 PM
To: Duane Remein <Duane.Remein@xxxxxxxxxx>; STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

Duane,

 

First, a suggestion to reduce the field size. Then limiting the total of SP1, SP2, and SP3. It is clear you are trying to solve some problem, but it is not clear what that problem is. Can you explain it first?

 

 

For the SP1, SP2, and SP3 lengths, we must have individual limits. The limit on the total size will naturally follow from that.

 

Thank you,

-Glen

 

From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Thursday, April 19, 2018 7:43 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

I suggest we limit the aggregate of SP1 + SP2 + SP3 to 2.5 us.  This is over twice what Glen suggested (and what was considered easy to accomplish in 2002 where the default was ~850 ns).

Best Regards

Duane

 

From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Sent: Wednesday, April 18, 2018 3:41 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

All the points Glen is bringing up are very valid. Just to add, should any value range restriction be needed, we can set the range in the field definition on the draft, and be done with it. However with pad still available, there is very little reason to skimp on field size.

 

Marek

 

From: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxx>
Sent: Wednesday, April 18, 2018 12:48 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

Because

There is plenty of padding left in a message. If we don’t use it for any fields, we just send zeroes anyway.

All fields are even, so the frame can be parsed on word boundary instead of byte boundary.

Vendors/developers can use the values exceeding the spec limit for system bring-up/debugging (assuming both ends of the link can handle this).

 

What would be the reasons to reduce these fields to 1 byte?

 

Thank you,

-Glen

 

From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Wednesday, April 18, 2018 11:26 AM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Cc: Duane Remein <Duane.Remein@xxxxxxxxxx>
Subject: RE: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

Glen,

I would be happy with these values, at least for starters.  But then my question become why do you need 16 bits to express a number that can be easily expressed in 7 bits?

Best Regards

Duane

 

From: Glen Kramer [mailto:glen.kramer@xxxxxxxxxxxx]
Sent: Wednesday, April 18, 2018 2:18 PM
To: Duane Remein <Duane.Remein@xxxxxxxxxx>; STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

I am not sure what the issue is. The bound comes from the definitions of Ton, Treceiver_settling, and Tcdr. I am sure we will have a separate discussion on that. The bound does not come from the MPCPDU field size. In 10G-EPON, SyncTime field was 2 bytes, but the maximum allowed value was 76 TQ (800 ns Treceiver_settling, 400 ns Tcdr, and 16 ns Burst Delimiter).

 

The only thing that needs to change in Marek’s presentation is that it should not say that the entire range from 0 to 2^16 is allowed. It does say it now.

 

Thank you,

-Glen

 

From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Wednesday, April 18, 2018 11:02 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

Marek,

The point is not that the OLT has to use both bytes, the point is it legally can and the ONU is duty bound to accommodate that.  Without some upper bound that can come to over 2 seconds of delay.  Clearly this is excessive.

Best Regards

Duane

 

From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Sent: Wednesday, April 18, 2018 1:53 PM
To: Duane Remein <Duane.Remein@xxxxxxxxxx>
Cc: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

Duane, 

 

What would be then "reasonable"? It is not like OLT has to use all 2 octets provided for specific values. 

 

Marek

 

On Wed, Apr 18, 2018 at 11:51 AM, Duane Remein <Duane.Remein@xxxxxxxxxx> wrote:

Marek,

I previously commented on the 2 byte repeat parameter in the SP messages and, at the time, it was suggested that this really didn’t matter.  However, I have to disagree with that opinion.

 

In 10G-EPON we incorporated the Data Detector mechanism to determine when the beginning of the burst should occur.  The mechanism depended on a delay line that essentially matched the duration of burst preamble, burst delimiter and laser on time (i.e., sync time).  In 10G-EPON this was a fixed duration.  We have now made that duration variable and of arbitrary size through the setting of SP1, SP2 and SP3 and any repeats.

 

What will the ONU be expected to accommodate with respect to maximum delay needed?

 

Without placing a bound on this total time I don’t see how we can claim technical feasibility.  If some OLT vendor decides a very long sync time is OK per the standard and an ONU cannot accommodate that long time interoperability is not achieved, neither device is non-compliant and we have not achieved our goals.

 

I suggest we place a reasonable limit on the total sync time in the standard and size the repeat parameters accordingly.

 

Best Regards

Duane

 

From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Sent: Thursday, April 12, 2018 5:31 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

Dear colleagues,

 

Attached please find the updated version of the general presentation and detailed changes to MPCP Clause, modified following the feedback on the call today. All and any comments on the content are welcome

 

Marek

 

From: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>
Sent: Thursday, April 12, 2018 12:34 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes

 

All,

 

Please let me know if I need to revise or add to the following notes:

 

 

4/12/2018

IEEE 802.3ca 100G-EPON Task Force Work Items and Socialization ad hoc conference call

 

·        Review of Patent Policy.

o   Curtis Knittle read the Call for Potentially Essential Patents – no response to call.

·        MPCP Changes (M. Hajduczenia)

·        Deadlines:

o   Contribution deadline for requesting time on the agenda and draft PDF files: Monday, May 14, 2018 AoE

§  See http://www.ieee802.org/3/ca/3ca_presentproc.shtml for details on submissions

o   Draft 1.0 Comment deadline is May 7. For details, please see http://www.ieee802.org/3/ca/email/msg00766.html

·        Action Items:

o    

 

 

Name

Employer/Affiliation

Alan Brown

Adtran, Inc.

Allard van der Horst

Semtech

Alexander Umnov

Corning

Andre Lessard

CommScope

Bill Powell

Nokia

Bruce Chow

Corning

Barry Colella

Source Photonics

Claudio Desanti

Google

Curtis Knittle

CableLabs

Dave Baran

Arris

David Claussen

Charter

David Law

HPE

Dekun Liu

Huawei

Derrick Cassidy

BT

Dora Van Veen

Nokia

Doug Jones

Comcast

Duane Remein

Huawei

Earl Parsons

CommScope

Ed Harstead

Nokia

Ed Walter

AT&T

Fernando Villarruel

Cisco

Francois Menard

Aeponyx

Frank Effenberger

Huawei

Glen Kramer

Broadcom

Greg LeCheminant

Keysight

Hal Roberts

Calix

Hesham ElBakoury

Huawei

Jesus Cotano

Telefonica

Jean-Christophe Marion

Tibit Communications

Jeff Finkelstein

Cox

Joe Jensen

Buckeye Communications

John D’Ambrosia

Futurewei subsidiary of Huawei

John Johnson

Broadcom

Jorge Salinger

Comcast

Junwen Zhang

ZTE

Kenneth Jackson

Sumitomo

Kevin Bourg

Corning

Kevin Noll

Tibit Communications

Lilin Yi

Fiberhome

Marek Hajduczenia

Charter

Mark Laubach

Broadcom

Matt Sheppard

Virgin Mobile

Michael Peters

Sumitomo

Mike Darling

Shaw

Mike Emmendorfer

Arris

Moiz Lokhandwala

Charter

Moon Park

OE Solutions America

Pete Pondillo

Corning

Phil Miguelez

Comcast

Philip Oakley

Virgin Media

Qing Xu

Belden

Richard Zhou

Charter

Roger Stafford

Charter

Ryan Hirth

Broadcom

Ryan Tucker

Charter

Saif Rahman

Comcast

Sebnem Ozer

Comcast

Sergio Prieto

Telefonica

Shan Wey

ZTE

Shawn Esser

Finisar

Victor Hou

Broadcom

Vincent Houtsma

Nokia

Wang Suyi

Fiberhome

Xiang Liu

Huawei

Yong Kim

 

Zhou Zhen

Fiberhome

 

 

 

 

 

 

 

Curtis Knittle

VP Wired Technologies – R&D

CableLabs

desk: +1-303-661-3851

mobile: +1-303-589-6869

c.knittle@xxxxxxxxxxxxx

 

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


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

Attachment: hajduczenia_3ca_1n_0518.pptx
Description: application/vnd.openxmlformats-officedocument.presentationml.presentation