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

Re: [1904.4 TF] 1904.4 Open action items



I was only thinking about the whole "MAU" sticking in the draft and not making much sense, honestly. I am OK keeping the attribute where it is, just renaming the group.

Also, I recall the discussion where we did not want to move stuff around much so that existing implementations could be re-used as much as possible (alignment between .1 and .4 you mentioned as well).

Marek

On 1/17/23 13:21, Glen Kramer wrote:

At some point, the grouping of attributes was supposed to reflect their grouping in Clause 30. There, the aMediaAvailable attribute is shown as part of the oMAU managed object class. The grouping of branch 0x07 in 1904.1/1904.4 now somewhat diverged. For example, there is no OAM management group in the 802.3. So I guess it is ok to rename this group.  

 

Please, also note that each group has a distinct range of leaf values. I don’t know if this is critical to maintain, but if we move aMediaAvailable to another existing group, this dependency will break.

 

Glen

 

From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Tuesday, January 17, 2023 12:02 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] 1904.4 Open action items

 

Hi Glen,

Attribute aPhyType (0x07/0x00-20) would have to go, indeed (together with PICS U-ME28 and T-ME28). I wonder, though, if there is much point to keep 14.3.3 MAU management as a section with just one attribute i.e., aMediaAvailable (0x07/0x00-47). The association between MAU and media is somewhat questionable. Perhaps we can rename "MAU management" to something more media related, perhaps "Medium management"?

Regards

Marek

On 1/17/23 10:30, Glen Kramer wrote:

Thank you, Marek. Are you planning to submit a comment to remove the aPhyType attribute?

 

 

From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Monday, January 16, 2023 1:36 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] 1904.4 Open action items

 

Hi Glen,

I did review the thread you pointed out and agree with your summary. We do not need to import any MAU attributes.

As far as your question is concerned ("So, I think first we should answer whether there is any value in ONU reporting a generic class of PHY as opposed to a specific module connected to it?"), I personally do not see much value in that. A generic class could be derived from specific class that is reported, while the inverse is not possible, i.e., we cannot figure out whether it is D/U and 1/2/3 power class knowing only it is PQ type. Given that aMediaTypeCapability (RO) and aMediaType (RW) are already using specific rather than generic values, I think we're covered with the draft as it is today.

It seems to me that unless there is a valid reason to make changes, we are covered today and could simply close this AI without further changes to the draft.

Regards

Marek

On 12/16/22 13:16, Glen Kramer wrote:

I searched our past discussions on the reflector archive and it turned out we already had a very extensive discussion about the aMauType attribute back in July 2021.

 

The discussion started with a proposal to add aMauType to 1904.4 (we never had this attribute in 1904.1) because the 802.3ca has updated this attribute with a lot of new optical module types.

The aMauType attribute is defined in 802.3 as a RW attribute that is used for selecting a particular MAU type. There is a RO attribute aMauTypeList that shows all supported MAU types (this is what we call a “capability attribute”).

The problem with simply reusing these attributes as defined in 802.3 was that they also contained a lot of MAU types that were old, obsolete, or had no relevance to EPON.

 

I suggest all to review this thread: https://www.ieee1904.org/4/email/msg00147.html

 

As a result of this discussion, we added to D0.5 two extended attributes: aMediaTypeCapability (RO) and aMediaType (RW).

(see the contribution https://www.ieee1904.org/4/meeting_archive/2021/08/tf4_2108_hajduczenia_5b.pdf)

 

These attributes replace the aMauType and aMauTypeList attributes.

But the 802.3 also has these two attributes: a PhyType and aPhyTypeList – both a RO.

 

The 802.3 aPhyType description says “A read-only value that identifies the PHY type. The value of this attribute maps to the value of aMAUType.” But while the MAU type identifies the specific type of optical module (i.e., 50/25GBASE-PQX-D3), the aPhyType lists it as a generic class “50/25GBASE-PQ” that includes all coexistence options {G or X}, all directions {D or U}, and all power classes {1, 2, or 3}.

 

So, I think first we should answer whether there is any value in ONU reporting a generic class of PHY as opposed to a specific module connected to it?

 

If we decide to keep aPhyType, we need to bring all new PHY codepoints over to 1904.4.  And we probably also need to import aPhyTypeList in this case.

But if aPhyType does not add anything useful beyond what aMediaTypeCapability and aMediaType attributes can report, maybe we should just delete it.

 

In either case, no need to import any MAU attributes.

 

Glen

 

 

From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Thursday, December 15, 2022 6:54 PM
To: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx; Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Subject: Re: [1904.4 TF] 1904.4 Open action items

 

The first option, i.e., update both MAU and PHY attributes to match whatever combination of devices we plan to support. I am still checking to see why we would even care about MAU to begin with (I have conflicting statements being made for now)

Marek

On 12/15/22 18:41, Glen Kramer wrote:

Hi Marek,

 

Not exactly clear what you are proposing. Is it to update both aMauType and aPhyType tables to bring in all the latest MAU and PHY types? Or is it something else?

 

Glen

 

From: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>
Sent: Thursday, December 15, 2022 3:54 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] 1904.4 Open action items

 

Marek,

Your plan sounds reasonable to me.

Curtis

 

 

From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Thursday, December 15, 2022 2:39 PM
To: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>; stds-1904-4-tf@xxxxxxxxxxxxxxxxx
Subject: Re: 1904.4 Open action items

 

Good morning, colleagues,

On item #45, which I took upon myself as Ryan's substitute, I have been looking at the way aPHY and aMAU are used in IEEE Std 802.3 and I cannot find any clear reason why we would need to even care about MAU value apart from some of legacy management attributes. Neither the MAU nor the AUI interfaces exist (apart, perhaps as notional entities for the purposes of thinking about layering the interface) in our modern PHYs and everything following Fast Ethernet is built around the MAC and PHY separation, with xMII in the middle. I think it might be one of these cases of having to just do it because of legacy reasons, closing the eyes and moving on

if we have consensus on just getting this done, i am happy to update the relevant table(s) via a comment on D1.2

Marek

On 12/14/22 09:07, Curtis Knittle wrote:

Colleagues,

Below you will find the current list of assigned and open action items.

Curtis

 

 

 

 

 

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

#whosaysicant

 


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


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


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


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