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
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
