| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear Dr. Lin, The email archive for this reflector is located at: http://www.ieee802.org/3/epoc/email/thrd1.html. You can access all past emails together with their attachments. As for solving the problems with your email, I’d personally suggest to unsubscribe from the list and then subscribe again – that typically fixes the problems with any settings on the side of the sender. Instructions can be found at: http://www.ieee802.org/3/epoc/reflector.html. On your side, I’d suggest you check the SPAM filter settings. On individual proposed changes: - I am OK with the change to HFC definition, but would propose some tweaks for better readability: “An access network, comprising a cascade of optical fiber trunk and coaxial cable distribution, used for RF signal transmission between the headend and subscribers. In such a network architecture, optical nodes perform optical to RF conversion.” - I am OK with the change of CDN to CCDN. Also, I will use this opportunity to distribute R11 of the definitions, addressing changes suggested to me since R10 was released. Marek From: rujianlin@xxxxxxxxxx [mailto:rujianlin@xxxxxxxxxx] Sent: Friday, August 31, 2012 04:23 To: MarekHajduczenia Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx Subject: Re:Re: [802.3_EPOC] Agenda for this morning's meeting Marek: This the last time in this month I see your mail on the website STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx. Since 2012-08-08, I have not received any mail regarding EPoC SG. Maybe this was due to my mailbox almost fully loaded once, causing transmission fail. Could you help in consulting with the administrator of STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx. to solve my problem. I am still keeping track the discussion going on in EPoC SG, knowing the information by receiving the transferred mails from my colleage Samuel Zeng. Regarding the Definition v09, I would like proposed minor modifications to the term "HFC" and "CDN" as following: 1) Making the definition to HFC in more detail like " An access network configued as cascade of optical fiber trunk and coaxial cable distribution network for RF signal transmission between headend and subscribers in which the optical nodes perform optical to RF conversion. 2) Change the name CDN to CCDN (coaxial cable distribution network), because in computer network domain CDN is widely used to refer "Content Distribution Network". Even though here CDN (Coax Didtribution Network) in EPoC is the counterpart of ODN (Optical Distribution Network) in EPON, I suggest the minor modification to avoid confusion. Thanks, Rujian Lin Chief Scientist Luster Teraband Photonics Co., Ltd.,Shanghai Add: Build D,1355 Chengbei Rd, Jiading, Shanghai, China Tel: +86 13901930706 -------- 原始邮件 -------- 发件人: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx> 发送时间: 2012-08-08 03:20 收件人: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx 主 题: Re:Re: [802.3_EPOC] Agenda for this morning's meeting Andrea, I do not know why people keep bringing in something “MAC delay”. The only delay in 802.3 MAC is related with serialization of data received from above the MAC. Nothing more. Nothing else. I am not sure what additional “MAC implications” you reference but if there any, it is not an 802.3 MAC we are talking about. Potentially, you might be referring to MAC Control, which is a separate beat altogether. Please clarify On the EPON delay component itself – I am not sure what this exercise is supposed to give to EPoC as a project. It will not help reach decisions for designing EPoC PHY in any way. All we need to do is nail down the delay budget for the EPoC PHY / link and leave EPON alone. It is done and changing it is not within the scope of EPoC project. Yes, Saif can now go after me because I speak again of the scope. I do. A project without a scope never ends and has always one more thing to do before it is over. This is not the way 802.3 works. Marek From: Garavaglia, Andrea [mailto:andreag@xxxxxxxxxxxx] Sent: 07 August 2012 09:43 To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx Subject: RE: [802.3_EPOC] Agenda for this morning's meeting Thanks Marek for your feedback, Let me try to clarify what maybe was not well evident to who did not attend the call: the exercise we are doing is a delay (and efficiency) model to improve the spreadsheet according to the receive feedback (this is captured in slide 3). In that regard, a key component is the PHY delay of the coax portion from which we have started. Another key component is MAC implications related to EPoC, which we will work on after PHY model is stable – this is where our effort is going. Eventually, as desire was expressed in that direction, additional delays due to EPON and OCU can be added on top but I share the same opinion that it is not meant to enter into the detail of such part – in fact, OCU model suggested by Saif (see slide 4) is to just have a delay parameter each one can configure based on own scenario/implementation/interest. I hope that is clear and common understanding for everybody – I am open to further suggestions otherwise. Thanks, Andrea From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] Sent: Tuesday, August 07, 2012 06:23 To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx Subject: Re: [802.3_EPOC] Agenda for this morning's meeting Joe, When reading the notes (and I apologize in advance for not being able to participate in the calls, trying to take some time off until the 9th of August), I get the impression that we are getting into way too many details when considering delay budget, focusing on items which are clearly outside the scope of the project. Encryption, for once, is defined in 802 by 802.1X and it lies above layers of 802.3, and as such, we do not specify them. We can freely discuss what we believe the “right” number is, but at the end of the day, it is implementation dependent and does not affect the work we have to do. That said, why do we even need to bother with encryption delay? The other thing that concerns me is the constant attempt to calculate the delay budget between OLT and CNU. Please understand, the delay budget and jitter budget for EPON part of that link is well known and bounded under 802.3av and there is nothing that this project can do to change it. For us, it is fixed. We can take the maximum value and that is the most we can do. There is no analysis needed here, the values are already in the standard. The only part of the link we should be concerned with is the CLT to CNU. The way it is going right now, we are pretty much on the way to write a product spec, rather than a standard. Perhaps my impressions are incorrect, but I base them only on the notes, not having the benefit of the participation on the call. Regards Marek From: Solomon, Joe [mailto:Joe_Solomon@xxxxxxxxxxxxxxxxx] Sent: 06 August 2012 09:30 To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx Subject: Re: [802.3_EPOC] Agenda for this morning's meeting Meeting notes and updated Action/Issues Register are attached. Joe From: Solomon, Joe [mailto:Joe_Solomon@xxxxxxxxxxxxxxxxx] Sent: Monday, August 06, 2012 9:00 AM To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx Subject: [802.3_EPOC] Agenda for this morning's meeting Team, Proposed agenda for this morning is below: 1. EPoC Performance Model Updates – Andrea G. 2. EPoC List of Definitions – Marek H. 3. EPoC Draft Outline – Marek 4. Review/update open actions/issues Joe Solomon Senior Technical Writer Comcast – T + PD Access Technology 303-242-7037 _____ <="" p=""> _____ _____ <="" p=""> _____ < wa?SUBED1="STDS-802-3-EPOC&A=1" cgi-bin listserv.ieee.org https: link: following the click list, STDS-802-3-EPOC unsubscribe To> ________________________________________________________________________ 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
Attachment:
EPoC_1209_hajduczenia_01_R11.docx
Description: EPoC_1209_hajduczenia_01_R11.docx