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

Re: [802.3_EPOC] Action item for September 2012 meeting (draft structure)



Marek,

One of EPoC objective indicates that we may need to add minimal augmentation to OAM to support EPoC. Therefore, we may need to 
add a place holder for OAM changes the same way we have one for MPCP changes. 

Thanks

Hesham


-----Original Message-----
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx] 
Sent: Friday, July 27, 2012 8:39 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Action item for September 2012 meeting (draft structure)

Duane, 

As indicated before, it is the first pass based on what we know right now and it will be polished as we progress with selection of baseline proposals and have better understanding of individual functions and sublayers. I see making CLT and CNU PMDs identical as simplification of the current subclause outline and certainly not precluded at this time. 

As for specific changes you suggested:

- 95.6, indeed, it should reference RF and not optical; fixed in the attached document
- 95.7.2, I stuck this as boilerplate for discussion. If indeed we find there is nothing there to discuss, I am all fine to remove it. I just do not understand enough about RF cabling plant to make a forward assumption that it is inherently safe and there are no consideration we need to make here.
Your suggestion to follow EFM is a good one, though EFM was not defined for coaxial cable, so we might want to have discussion before we assume there is no need for RF safety subclause. 
- 95.8 - It was not an annex in 10G-EPON, even though all we did was reference external cabling specs ... I would think we would do exactly the same here i.e. reference cable specs for which the model is expected to work. Nothing less, nothing more. 
- 96.2.3 - that is correct, most are expected to point to 10G-EPON (I would hope, that all would be just pointers to 10G-EPON), but I do not know enough to make this assumption right now. 
- 96.3.2.2 - please, do see the note in the text. If the reference to 64b66b is offending, I will simply make that into a line code of choice to avoid further discussion and looking for hidden meanings. 

Marek

-----Original Message-----
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: 27 July 2012 00:45
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Cc: Duane Remein
Subject: RE: [802.3_EPOC] Action item for September 2012 meeting (draft
structure)

Marek,
Thank you for being so proactive on this important task. However, I think we should not get to far down this path nor should we make too many assumptions and those we make should be clearly stated. Quite often you seem to be doing this but not in all cases. For example you have obviously assumed that the PMD at the CLT is different from the PMD at the CNU. Others have clearly stated that these may in fact be identical. We need to be careful here that the outline does not set us on a particular technical path; and that anyone reading this outline is clearly aware that no technical decisions have yet been made.
A few very minor comments:
95.6 probably will not discuss optical parameters, likewise the list of parameters in this section are probably misleading at this point.
95.7.2	RF safety - do you really think the RF levels we will be dealing
with pose a safety risk? I've stood within 50-100' from a high power long range air search radar without any obvious negative effects, I don't think the RF levels we would produce will be a risk. In this vane I think grounding and lightning will be issues we might need to consider in this clause. Traditional Ethernet copper interfaces have never been exposed to lightning, perhaps we can borrow something from the EFM copper clauses but a quick scan didn't reveal anything useful.
95.8 - Shouldn't this be an annex? I don' think this will contain any normative requirements but only describes the channel under which we defined the standard.
96.2.3 - most of this will be references yes?
96.3.2.2/96.3.3.6	64B/66B Encode/Decode? Really? On what are you
basing this decision?

Best Regards,
Duane

FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC

-----Original Message-----
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Thursday, July 26, 2012 9:43 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [802.3_EPOC] Action item for September 2012 meeting (draft
structure)

Dear colleagues, 

Following the action item I took during July's plenary, I am sharing with you the first look at the draft structure for EPoC, following closely on my contribution hajduczenia_01_0712.pdf.  

Please note that it is a very preliminary proposal for the future document structure and by no means final. I attempted to emulate existing 10G-EPON clause structure as close as possible, while avoiding going into details of how specific functions are implemented. We will have enough time to deal with that later on.  

Please let me know if you have any specific suggestions of changes or just comments. I will try to keep the document updated based on received feedback. 

Regards

Marek

________________________________________________________________________

To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1

________________________________________________________________________

To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1

________________________________________________________________________

To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1