Re: [STDS-802-3-EPOC] Any presentations for tomorrow's scheduled PHY Sub-Group Conference Call?
Duane,
please see a few comments inline
Regards
Marek Hajduczenia, PhD
Network Architect, Principal Engineer
Bright House Networks
*Office +1-813-295-5644 <%2B1-813-295-5644> Cell +1-813-465-0669
<%2B1-813-465-0669>*
On 9 January 2014 10:58, Duane Remein <Duane.Remein@xxxxxxxxxx> wrote:
> Marek,
>
> Generally I agree with you – details below. New submission in the works.
>
> Best Regards,
>
> Duane
>
> *From:* Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
> *Sent:* Wednesday, January 08, 2014 8:15 AM
> *To:* Duane Remein; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
> *Subject:* RE: [STDS-802-3-EPOC] Any presentations for tomorrow's
> scheduled PHY Sub-Group Conference Call?
>
>
>
> Duane,
>
>
>
> Thank you for putting these together, I have a few comments, though.
>
>
>
> All comments below are on
> http://www.ieee802.org/3/bn/private/Drafts/D0.3/Comments/remein_3bn_04_0114.pdf,
> since I understand that the other presentation is merely an overview:
>
>
>
> ====================================
>
>
>
> Register 1.4: there is nothing complex here IMO, we just create a new
> register 1.4.10 (now reserved) with definition as follows:
>
>
>
> 1.4.10 | 10GBASE-XR capable | 1 = PMA/PMD is capable of operating as
> 10GBASE-XR | RO
>
> 0 = PMA/PMD
> is not capable of operating as 10GBASE-XR
>
>
>
> Note that I copied it diligently from 2BASE-TL definition, which is also
> (I believe) a variable rate PHY.
>
>
>
> DRR – Agreed new table included
>
> ====================================
>
>
>
> Table 45-7 as shown in your contribution is not the latest version of this
> register. This is what it looks like with the latest amendments in place.
> This accounts for P802.3bk, P802.3bj, and P802.3bm projects:
>
>
>
> I suggest we reserve at least 4 register positions, under the assumption
> that TDD and FDD PHYs will be labelled separately for downstream and
> upstream. Given where the register position is right now, we get the
> privilege of opening the 11xxxx block. I suggest we reserve the following
> bit combinations:
>
> 110000 – 10GBASE-XRF-D
>
> 110001 – 10GBASE-XRT-D
>
> 110010 – 10GBASE-XRF-U
>
> 110011 – 10GBASE-XRT-U
>
> 110100 onwards remain reserved
>
>
>
> DRR – As I mentioned on the phone I would prefer to have this as a two
> entries; one for US and one for DS. No change at this time pending TF vote..
>
[mh0109] TF needs to finally decide on how many PMDs we are producing. Some
still believe we need to specify a single PMD within the amendment. As
indicated before, the text of the amendment should describe things in the
most sensible fashion, while leaving product implementation free to combine
individual PMDs as implementers see fit. I would prefer to see PMDs
optimized for FDD and TDD, and perhaps a PMD that can do FDD and TDD and
let the market figure out which are needed. As far as I am concerned, this
implies separate PMDs, hence the suggestion to treat them separately as far
as spec is concerned.
> ====================================
>
>
>
> Register 1.11 – unless it is clearly defined what these “extended
> abilities” are, I do not see much need to touch Register 1.11. We do not
> extend generic PHY or PCS, we rather build it anew. Note that for EPoC, we
> should ride on the definition of 1.11.9 “P2MP ability” and then extend
> register 1.12 accordingly. You seem to have omitted that option altogether
> for some reason.
>
>
>
> I would suggest we leave 1.11 as it is right now, and modify register 1.12
> to add a new register as such:
>
>
>
> | 1.12.11 | EPoC ability | 1 = PMA/PMD is able to perform 10GBASE-XR |
> XR
>
> 0 = PMA/PMD is not able
> to perform 10GBASE-XR
>
>
>
> And if needed, later on we create a new ability register dedicated to
> EPoC, referenced from 1.12.11. That way, we are also prepared for NG-EPON
> in the future. There is not enough space in 1.12.xx to continue to expand
> it much further, unless we want to grow register size and read it together
> with some other register (I would not mind that option either). This is
> also where your Register 1.16 could come into play …
>
>
>
> DRR – I agree that an EPoC PHY should indicate P2MP ability but I’m not
> sure I like putting it into table 1.12 and implying it si 10G-EPON. My
> opinion is that the “OFDMness” make EPoC unique from EPON. No change for
> now, let’s discuss in the TF.
>
[mh0109] In that case, we should entry in 1.11 for "P2MP EPoC ability" and
point to whatever table describes then the EPoC abilities ...
> ====================================
>
>
>
> Register 1.110 – given that we have free registers 1.17 up to 1.32 and
> could also create a separate section just for EPoC, is there any specific
> reason why you picked 1.100 for this control register? The location is a
> bit strange – now it would be located immediately after a block of 2B
> extended PMD parameters and right before 10GBASE-T.
>
>
>
> DRR – location picked just after 2B PMA/PMD tables, seemed somewhat
> logical to me but I don’t think it makes much difference either way.
>
>
>
> Register 1.110.1 – it is not clear what it means: “PHY is registered on
> the COAX network” – does it mean that the PHY was seen by PLC? If that is
> a case, there should be a separate PLC status register – clumping a bunch
> of registers together is rather strange.
>
>
>
> DRR – There is a comment to change the wording from discovery to initial
> ranging which I’ve proposed to accept. This would probably be better
> terminology.
>
> How about “Initial ranging and fine tuning complete”?
>
[mh0109] Much better than implying some none existent registration :)
>
>
> Note that 45.2.1.60a.1, 45.2.1.60a.2, and 45.2.1.60a.3 have the same
> register number (1.110.4).
>
> DRR – good catch, DS FFT Size was actually repeated, will fix.
>
>
>
> In 45.2.1.60a.5, there is wrong register name “TPHY” ?
>
> DRR - Fixed
>
>
>
> ====================================
>
>
>
> Some of the propose tables have RO and RW registers, yet the definition
> under the table indicates “RO – Read only”. Probably an oversight … for
> example, look at table in Register 1.111
>
> DRR – I’ll scan the submission again for this cut & paste error. But 1.111
> looks OK (1.111.15 is reserved and RO, this is consistent with what is
> currently in Cl 45 yes?).
>
>
>
> ====================================
>
>
>
> I suggest that register 1.111 be called “Downstream control register” and
> respectively, register 1.112 – “Upstream control register”. Register 1, 2,
> 3 are meaningless …
>
> DRR - Used DS/US OFDM control register as I suspect we will have a bunch
> more control registers.
>
>
>
> ====================================
>
>
>
> 45.2.1.60c.2, 45.2.1.60c.3 have wrong name – rather than “DS” these should
> be “US” since register 1.112 covers upstream transmission channel.
>
> DRR - @$#% cut & paste J Thanks
>
>
>
> ====================================
>
>
>
> Please scrub the document carefully, since you have plenty of typos,
> incorrect references (seem to have been modified by hand, e.g., page 7,
> line 9). Some cross references are hooked to a wrong table.
>
> DRR - Will give it one more read thru and am happy to fix anything you can
> point out.
>
>
>
> ====================================
>
>
>
> I have an issue with the number of options being introduced through
> register 45.2.1.60c.2 and similar ones – I have stated it before and I will
> restate it again. Each configuration option effectively doubles the testing
> time for compliant equipment, which increases cost. At this time, I would
> suggest we focus on narrowing down options to the minimum required and not
> embedding ton of optionality in register definitions.
>
>
>
> DRR – hence I put these in as Editors notes and not firm content. Let’s
> see what the will of the TF is on this. I agree that fewer settings would
> be good but I suspect one is too restrictive for the environment we will be
> working in.
>
>
>
> Regards
>
> Marek Hajduczenia, PhD
> Network Architect, Principal Engineer
> Bright House Networks
>
> *Office +1-813-295-5644 <%2B1-813-295-5644> Cell +1-813-465-0669
> <%2B1-813-465-0669>*
>
>
>
> *From:* Duane Remein [mailto:Duane.Remein@xxxxxxxxxx<Duane.Remein@xxxxxxxxxx>]
>
> *Sent:* Tuesday, January 07, 2014 1:28 PM
> *To:* STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
> *Subject:* Re: [STDS-802-3-EPOC] Any presentations for tomorrow's
> scheduled PHY Sub-Group Conference Call?
>
>
>
> Mark,
>
> If there are no other presentation I’d like to go over my presentation on
> Cl 45 (remein_3bn_03_0114 & remein_3bn_04_0114). These were submitted
> along with my comments.
>
> Best Regards,
>
> Duane
>
>
>
> FutureWei Technologies Inc.
>
> duane.remein@xxxxxxxxxx
>
> Director, Access R&D
>
> 919 418 4741
>
> Raleigh, NC
>
>
>
> *From:* Mark Laubach [mailto:laubach@xxxxxxxxxxxx <laubach@xxxxxxxxxxxx>]
> *Sent:* Tuesday, January 07, 2014 12:51 PM
> *To:* STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
> *Subject:* [STDS-802-3-EPOC] Any presentations for tomorrow's scheduled
> PHY Sub-Group Conference Call?
>
>
>
> Dear IEEE P802.3bn Task Force Participants,
>
>
>
> Our scheduled PHY sub-group conference call is tomorrow at 10AM Pacific.
> We have not seen any presentations for socialization on the email reflector
> and I have no additional topics.
>
>
>
> If you have any presentations for socialization or other topics, please
> send them on the reflector by 5PM Pacific today. If we see nothing, I will
> cancel the call for tomorrow.
>
>
>
> Please be familiar with the IEEE SA Patent Policies at:
>
>
> https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.pdf
>
>
>
> WebEx Meeting Number: 920 271 005
>
> To start: https://broadcom.webex.com/broadcom/j.php?J=920271005
>
>
>
> Yours truly,
>
> Mark Laubach, Chair
>
> IEEE P802.3bn EPoC PHY Task Force
>
>
>
> Broadband Communications Group
>
> Broadcom Corporation
>
> 1351 Redwood Way
>
> Petaluma, CA, 94954
>
> [image: broadcom.jpg]
>
> Tel: +1.707.792.9093
>
> Cell: +1.650.996.2219
>
>
>
>
> ------------------------------
>
> <="" p="">
>
>
> ------------------------------
>
________________________________________________________________________
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
