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

Re: [802.3_NGEPON] 10/01/15 NG-EPON Consensus building meeting notes



Dear Colleagues,
 
What I pointed out on the NG-EPON consensus building call yesterday was that the current draft PAR states in the scope of the project '... operation at 25 Gb/s and 100 Gb/s MAC data rate ...'. If you can do everything you want using the existing 25 Gb/s and 100 Gb/s MAC data rates, that is you will not need to make changes to MAC Clause (Clause 4 or its associated Annex 4A), then I believe all is good.
 
What I however understood from the NG-EPON consensus building call yesterday was a desire to include operation at a 50 Gb/s MAC data rate. My personal opinion is that would (1) require changes to the MAC Clause to add the specification for 50Gb/s operation and therefore (2) would be beyond the currently stated project scope.
 
Best regards,
  David

-----

From: Dai, Eugene (CCI-Atlanta) [mailto:Eugene.Dai@xxxxxxx] 
Sent: 02 October 2015 21:02
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 10/01/15 NG-EPON Consensus building meeting notes

My concern to especially add 50G is that it will create possibly 3 more combinations we have to deliver. To deal with so many generations, co-existence at one time could cause delay of the project. Keep in mind what we really need in the foreseeable future is 25G EPON. To allow reduces rate between 25G and 100G means the architecture allow such sub-rate that we could define now or later. IEEE had nothing between 1G and 10G Ethernet for a long time, only recently 2.5G and 5G been added.  

Although I will not expect people interpret reduced rate to decimal point, probably for clarity we could mention reduce rate in 25G or 10G multiplex.

Eugene 

________________________________________
From: frank effenberger <frank.effenberger@xxxxxxxxxx>
Sent: Friday, October 2, 2015 3:24 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 10/01/15 NG-EPON Consensus building meeting notes 
 
Marek, 
 
That's a good point - we have to manage the perception of what we are trying to do.  
If the assembled group feels that a 50G MAC will not cause upset, then ok.  keeping in mind that it then implies that people will have to build 50G switch ports.    
 
Frank E.
 
 
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] 
Sent: Friday, October 02, 2015 3:03 PM
To: frank effenberger; STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_NGEPON] 10/01/15 NG-EPON Consensus building meeting notes
 
Frank, 
 
I think the main problem is relaying the idea of de-rating the MAC without creating impression that we will do anything between 25G and 100G, i.e., we do not want (I am quite sure of that) 27.5G option or 31.5577G option or any odd-ball number that might be coming out of a broadly understood "de-rating". This is what brought about the concern about open ended statement of data rate between 25G and 100G. This is also what prompted fixing the intermediate data rate of 50G - we know it is multiple of 25G baseline data rate and can be easily converted into whole number of data lanes. 
 
The whole point right now is to specify the scope in such a way  that (a) we clearly spell out what we set out to do, (b) we do not lock ourselves out right out of the bat from some of the technical choices that might be available down the road, and (c) we do not leave too much freedom to allow for "anything goes" proposals. I know these look quite contradictory . but this is what it is . 
 
Marek
 
From: frank effenberger [mailto:frank.effenberger@xxxxxxxxxx] 
Sent: Friday, October 02, 2015 2:50 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 10/01/15 NG-EPON Consensus building meeting notes
 
Glen, 
I know how 10GEPON works.  I even got an award for it.  (And what luxury - a whole piece of 8.5x11 paper, with color printing, even!)  
Let's not forget that everything in the standard is only a reference implementation.  What you actually build is up to you, as long as it behaves as it should.  This is particularly true for EPON.  
So, for the concern on the "whole data path running at 100G" - come on. that's not how it would be done.  
 
Now, what's wrong with saying that there is a 100G MAC, that then only uses a subset of its capability?  In our view, that's how you'd build any of these sub-rated things.  I think there is a false argument here, that somehow people are going to build a dedicated 50G EPON.   Do you think the industry is going to do such incremental advances?  I don't think so, particularly not for the silicon.    
We expect that the 25G single channel technology will be developed, and that a way to combine them into higher speeds will be developed. 
The 100G MAC is the large enough bucket that can accommodate 4 25's, and four is a proven modularity. 
And so, anybody who is interested in building any of these sub-rated systems would end up using 100Gb/s switch-ports.  
 
I can say that some of this may depend on exactly how the channel combining is done.  Some people may be thinking of "hard bonding" - that is, the designer decides how many channels will be tied together, and once they are combined, any ONU that wants to use those channels must listen to all of them.  This is how 100G Ethernet works, and that is fine for point to point.  They become an indivisible block, and that (maybe) motivates the thinking about a 50G MAC.  I think this is a very poor design choice for PON.  The whole point of PON is to allow bandwidth flexibility.  It is much better to have a scheme of "soft bonding" - that is, the operator decides which ONUs work on which set of channels, and it can change over time.  In addition, it is likely that there can be 1, 2, and 4 channel ONUs, all sharing the available channels in an efficient manner.  If one "hard bonds" 2 channels together, then the single channel ONUs can't listen to those channels - you'd have to have a s!
 ingle channel to take care of them.  And then there is no space for the 4 channel bonded group.  We would quickly paint ourselves into a corner.  
 
So, back to the scope:  If the scope is a maximum, then 100G is a fine maximum. If we do the right thing regarding how the 100G MAC gets reduced, all the desired use cases will be supported.  And that is what really matters.      
 
Sincerely,
Frank E
 
 
From: Glen Kramer [mailto:gkramer@xxxxxxxxxxxx] 
Sent: Friday, October 02, 2015 1:51 PM
To: frank effenberger; STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: RE: 10/01/15 NG-EPON Consensus building meeting notes
 
Frank,
 
10G-EPON uses exactly the same MAC as is used in 10G point-to-point. This MAC runs at exactly 10Gb/s, no matter what the actual data throughput. The PHY adds an overhead due to FEC, so the effective throughput is lower. The data is throttled above MAC to make sure it does not overrun PHY capacity. But the MAC spits bits (idles if there is no data) out at exactly 10Gb/s. In other words, the data path in 10G-EPON runs at 10Gb/s.
 
Since the PAR scope is the upper bound and what the project is allowed to cover (as David clarified on the call), the existing scope limits us to only 25G and 100G MACs and nothing else. 
If we don't add 50G MAC, then we will have the MAC and the entire data path running at either 25Gb/s or 100Gb/s, no matter how many wavelengths are activated. This is what we try to avoid. We need to allow another generation between 25G and 100G.
 
Glen
 
From: frank effenberger [mailto:frank.effenberger@xxxxxxxxxx] 
Sent: Friday, October 02, 2015 10:27 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGEPON] FW: 10/01/15 NG-EPON Consensus building meeting notes
 
It bounced for some reason.
 
From: frank effenberger 
Sent: Friday, October 02, 2015 1:18 PM
To: 'Curtis Knittle'; STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: RE: 10/01/15 NG-EPON Consensus building meeting notes
 
Sorry we missed the call.  
 
I would note that explicitly adding 50G at this time invites "no" votes right now, as there are no other 50G MAC projects.  
The existing idea was that the 100G PHY would be made in such a way as to allow reduced rate (i.e., fewer channel) operation.  Why does this not suffice?  
Also, such degradation would not require seeking special permission from the parent group.  As a case in point, 10GEPON actually is a 8.7GEPON.  We chose to do FEC sub-rating. 
So the actual MAC rate is lower than normal, using the forcing of larger inter-packet gaps.  Again, why do we think the reduce rate 100G would be any different?  
 
Thanks, 
Frank E.
 
 
From: Curtis Knittle [mailto:C.Knittle@xxxxxxxxxxxxx] 
Sent: Friday, October 02, 2015 12:20 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGEPON] 10/01/15 NG-EPON Consensus building meeting notes
 
Folks, 
Please let me know if I need to add to or revise the notes below. Note, Marek's contribution for the meeting is attached.
 
Curtis
 
 
 
10/01/2015
IEEE 802.3 NG-EPON Study Group Work Items and Socialization
 
.         Review of Guidelines for IEEE-SA meetings. 
o   https://development.standards.ieee.org/myproject/Public/mytools/mob/preparslides.pdf
o   Has anyone not seen these Guidelines? Everyone has seen the guidelines
.         November meeting
o   Study Group meeting times (tentative but likely): 
.  Tuesday, 11/10, 1 pm - 5:30 pm
.  Wednesday, 11/11, 9 am - 5:30 pm
.  Thursday, 11/12, 9:00 am - 12:00 pm
.         CSD/PAR/Objectives timeline

.         Deliverables for Plenary
o   Comments due from 802 by 6:30 pm 11/10. Comments resolved by 6:30 pm 11/11
.         Critical/Baseline decisions (reference Marek's presentation attached to email)
o   Pros and cons of channel bonding at different sublayers - below MII, above MII, above MAC
o   Terminology
o   Fiber data (see slide 8)
o   Channel model (see slide 8)
o   See Marek's presentation for additional key baseline decisions
.         Leads for areas
o   Group was asked to consider high level areas for which a lead would be identified to drive the contributions and decisions for that area. Examples are architecture, features, baseline, etc. 
o   This would be different from creating ad hoc committees. While less formal than ad hocs, there would be improved organization with leads identified
o   Task force members can contribute wherever they want - there are no restrictions.
.         Miscellaneous
o   Scope of PAR: might need to add something to the scope to allow for rates between 25G and 100G, or something about degraded rates. Exceeding the scope by doing 50G, for example, when we've only mentioned 25G and 100G, could bring some "no" votes because it doesn't match the scope.
.  Two augmentations to the scope: intermediate MAC rates, "symmetric and/or asymmetric operation" (like in .3av)
o   Risk: if we don't change the scope, then we risk not getting approval in 2 years when we do sponsor ballot. If we do change the PAR, people might think it's too big of a change and vote no. The commenting process is used to make changes to the PAR all the time. We need to make sure we have a good story regarding these changes.
o   Group initially considered scope as a minimum, which allowed operation at 50 Gbps, but it turns out this is not the case. The scope places upper bounds on the project. 
o   Proposed scope change: The scope of this project is to amend IEEE Std 802.3 to add physical layer specifications and management parameters for symmetric and/or asymmetric operation at 25 Gb/s, 50 Gb/s, and 100 Gb/s MAC data rates on point-to-multipoint passive optical networks.
 
 
 
Name
Employer/Affiliation
Alan Brown
CommScope
Bill Powell
ALU
Bruce Chow 
Corning 
Barry Colella
Source Photonics
Curtis Knittle
CableLabs
David Law
HP
Derrick Cassidy
BT
Doug Jones
Comcast
Duane Remein
Huawei
Ed Harstead
ALU
Fernando Villarruel
Cisco
Francois Menard
Aeponyx
Glen Kramer
Broadcom
Hesham ElBakoury
Huawei
Jeff Finkelstein
Cox
Jorge Salinger
Comcast
Kevin Bourg
Corning
Kevin Noll
TWC
Marek Hajduczenia
Bright House Networks
Mark Laubach
Broadcom
Michael Peters
Sumitomo
Mike Emmendorfer
Arris
Moiz Lokhandwala
TWC
Phil Miguelez
Comcast
Philip Oakley
Virgin Media
Ryan Hirth
Broadcom
Ryan Tucker
Charter
Saif Rahman
Comcast
 
 
 
 
 
 
 
Curtis Knittle
Director, Optical Technologies
 
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
Office: 303-661-3851
Mobile: 303-589-6869
Email: c.knittle@xxxxxxxxxxxxx