Sorry, I missed the “-like” part. Yes, agree with you plan. But if this is a new extended attribute, it should be in 0xDB branch, not in 0x07.
From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Wednesday, July 14, 2021 4:42 PM
To: 'Glen Kramer' <glen.kramer@xxxxxxxxxxxx>; 'Glen Kramer' <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; 'Tucker, Ryan R' <Ryan.Tucker@xxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
Glen,
Note that I was careful to use “-like” statement in my text. Perhaps that did not reflect the intent correctly, though, in the retrospect.
I will take the first crack at the attribute and will but it into branch 0x07 per discussion before. I will also take a stab at the list of MAU types, and then we can beat that to smithereens and decide what is missing
Marek
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Wednesday, July 14, 2021 5:37 PM
To: mxhajduczenia@xxxxxxxxx; Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
Marek,
I agree with what you said below. And yes, it is a long list to enumerate.
There are two things to consider:
1) Many of the MAU Types in the aMauType and aMauTypeList attributes are old, obsolete, and will never be used in EPON.
2) Redefining the aMauType from RW to RO creates a conflict with 802.3.
So, maybe the best course is to define our own extended attributes that operate like aMauTypeList and aMauType (RO side) but only using the types that we need to SIEPON.4. Just an idea.
The context for these attributes will be either PON port or service port
Glen
From: mxhajduczenia@xxxxxxxxx <mxhajduczenia@xxxxxxxxx>
Sent: Wednesday, July 14, 2021 4:19 PM
To: 'Glen Kramer' <glen.kramer@xxxxxxxxxxxx>; 'Glen Kramer' <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; 'Tucker, Ryan R' <Ryan.Tucker@xxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
Thank you, Glen
That is a good point. With this in mind, aMAUTypeList-like attribute would be closer to what we need, i.e. provide a list of modes supported by the PON interface optics. All we need is really assign the numeric values to individual target MAU types and create an enumeration list in an attribute. If we decide to support this attribute with UNI port context as well, the list will likely need to cover all possible MAU types from 802.3, 30.5.1.1.2 and that is a long list already.
I personally do not see the need for aMAUType-like attribute in Write mode, but when we do get a list of supported MAU types on the given interface, how do we find out which one it is actually being used? That is where the Read-mode aMAUType-like attribute would come in handy. Otherwise, we get just what the interface is capable of but not what it is actually using at the given time.
Marek
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Wednesday, July 14, 2021 4:26 PM
To: mxhajduczenia@xxxxxxxxx; Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
That is not the distinction between a capability and a configuration.
Look at the two new attributes we added in D0.4 (both are RO):
aOnuSrvPortCapability – capability query that describes ONU HW design – always reports the same data.
aSrvPortType – configuration query that reports a list of currently provisioned service ports and their types. What is reported by this query changes after every call to action acConfigSrvPort (i.e., after every configuration change).
Anyway, I was talking about aMauType. The aPhyType does not provide any info on optical module power class or coexistence options. But it is an important observation that aMauType is defined in 802.3 as RW. I missed that. I now see that aMauType is intended to be used in combination with aMauTypeList. The latter shows all modes supported by the given optical module (this is a capability attribute), and the former configures/selects one specific mode.
In EPON, ONU mode is selected automatically at registration time based on discovery info (i.e, before any OAM attribute can be sent to the ONU). Does anyone see any value in adding aMauType to the spec? If yes, please describe how it would be used.
Thanks,
Glen
From: mxhajduczenia@xxxxxxxxx <mxhajduczenia@xxxxxxxxx>
Sent: Wednesday, July 14, 2021 2:57 PM
To: 'Glen Kramer' <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; 'Tucker, Ryan R' <Ryan.Tucker@xxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
Glen,
In 802.3, 30.3.2.1.2 aPhyType is defined as R/O only attribute so it is a capability, and not configuration parameter, if that helps at all.
Marek
From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> On Behalf Of Glen Kramer
Sent: Wednesday, July 14, 2021 3:45 PM
To: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>; Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
Generally, the OLT pulls the ‘capability’ information if and when it needs it. A particular ONU can register and operate without OLT querying any capabilities at all.
In this particular example, we need to discuss few issues separately.
Should aMauType be treated as ‘HW capability’ type of attribute or as ‘Dynamic Configuration query’ type? It is a base attribute defined in 802.3, and .3 does not make a clear distinction (In 802.3 ‘capabilities’ means a different thing – it is a group of packages, where each package represents a collection of related attributes and features)
We can decide to treat this attribute as a capability or as a configuration. If we treat it as capability, then for the pluggable optics case, this attribute would report “unknown”. And then the specific module plugged in would be queried separately. To query a plugged module, I suppose the ONU OAM would need to read a certain field in the module’s ROM. It is almost like the “UNI Label description” TLV we discussed yesterday, but this time, the text would describe the installed module.
If we decide to treat this module as configuration, we would just report the current state, i.e., the specific module that happens to be plugged in. We would use any one of the pre-defined enumerated values from 802.3, 30.5.1.1.2. This seems easier, but it does not convey to the NMS the information that a specific module is pluggable or fixed. Even so, I think this approach would be more consistent with how aMauType is used in general.
How OLT would know about changed configuration or conditions?
According to OAM protocol, the ONU is not allowed to generate a response (i.e., a variable container TLV) without receiving a request first. So, the ONU cannot just volunteer any query responses on its own. But ONU can generate alarms and piggy-back them in any OAMPDUs, including the keep-alive OAMPDUs. Usually, the approach is that any change/event worth knowing about has an associated alarm. There is a number of such event codes:
An alarm is generated when event occurs and again when even clears. So, in our specific example about pluggable optics, LoS state can persist for a long time (days), but NMS would query the optics type when it receives the alarm that the LoS event has cleared, i.e., when the signal is detected again. Or it can query it anytime when a technician tries to debug a customer complaint remotely.
Glen
From: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>
Sent: Wednesday, July 14, 2021 11:46 AM
To: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
I’m probably not doing a good job of explaining myself. I was looking at this attribute as a capability. Most capabilities seem to be permanently present within the ONU, however some capabilities may be semi-permanent, such as an SFP* module in an ONU pluggable port, specifically on the UNI side since this would not cause an ONU reset, causing rediscovery of capabilities. I guess the question is, how important is it for this information to be available to the OLT and would it be okay for us to just expect the OLT to query the information if it deems it necessary for a decision making process? I also don’t think we could expect that a LOS event would always directly precede a pluggable module removal. Technically a LOS event could precede it by days or longer before a module is removed, but this is probably an implementation detail.
If the answer/consensus is that this is a vendor specific implementation item I could see that making sense.
Ryan
From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> On Behalf Of Glen Kramer
Sent: Wednesday, July 14, 2021 11:53 AM
To: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
If we use aMauType, it should go into the MAU management section. This is a basic attribute and the sections in 1904.4 correspond to sections in 802.3 Clause 30 where these attributes are defined.
If TRX module is replaced on a live ONU, on PON side, this causes ONU re-registration. On UNI side, there are Loss of signal alarms already defined. This alarm can be a trigger for the NMS to re-query the UNI port type when the signal returns.
Glen
From: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>
Sent: Wednesday, July 14, 2021 9:47 AM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] [EXTERNAL] Action item #44
Marek
Just taking a brief look through the draft, why not Section 14.3.3 – MAU Management? There’s already one attribute in that section, aMediaAvailable (0x07/0x00-47), that seems somewhat aligned in function.
On a slightly different note, this is something that’s presumably discovered during initialization, however any thoughts on what should happen if this media interface is removed or added after initialization? Should the insertion or removal of this ”media” somehow trigger a notification of some sort to the OLT?
Ryan
From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> On Behalf Of Marek Hajduczenia
Sent: Wednesday, July 14, 2021 9:51 AM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] Action item #44
CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.
Dear colleagues,
I started looking at the Action Item #44 from the yesterday’s call
44 | Attribute to discover optical module version |
|
|
| Assigned | Marek Hajduczenia |
In IEEE Std 802.3ca, we extended the aMAUType attribute in 30.5.1.1.2, adding a lengthy list of MAU types, which correspond to the optical module type. A few examples follow (I truncated the list, it is very long):
(…snip…)
25/10GBASE-PQG-D3 One single mode fiber, 1 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, high power class, as specified in Clause 141
25/10GBASE-PQG-U2 One single mode fiber, 1 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, medium power class, as specified in Clause 141
25/10GBASE-PQG-U3 One single mode fiber, 1 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, high power class, as specified in Clause 141
25/10GBASE-PQX-D2 One single mode fiber, 1 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, medium power class, as specified in Clause 141
25/10GBASE-PQX-D3 One single mode fiber, 1 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, high power class, as specified in Clause 141
(…snip…)
50/10GBASE-PQG-U3 One single mode fiber, 2 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, high power class, as specified in Clause 141
50/10GBASE-PQX-D2 One single mode fiber, 2 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, medium power class, as specified in Clause 141
50/10GBASE-PQX-D3 One single mode fiber, 2 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, high power class, as specified in Clause 141
50/10GBASE-PQX-U2 One single mode fiber, 2 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, medium power class, as specified in Clause 141
50/10GBASE-PQX-U3 One single mode fiber, 2 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, high power class, as specified in Clause 141
50/25GBASE-PQG-D2 One single mode fiber, 2 × 25.78125 GBd continuous transmission / 1 × 25.78125 GBd burst mode reception, medium power class, as specified in Clause 141
50/25GBASE-PQG-D3 One single mode fiber, 2 × 25.78125 GBd continuous transmission / 1 × 25.78125 GBd burst mode reception, high power class, as specified in Clause 141
(…snip…)
… and that got me thinking about where to add the new management attribute that would map into aMAUType Clause 30 attribute. Subclause 14.3.2 already focuses on “PHY management”, and it has three attributes mapping into Clause 30 attributes already, i.e., aPhyType, aSymbolErrorDuringCarrier, and aPhyAdminState. I feel it would be most natural to add aMauType attribute into the “Object group: PHY management” and we just need to decide what the leaf would be. Seems like 0x00-26 is the next one available.
Are there any concerns with this approach?
Regards
Marek
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
The contents of this e-mail message and
any attachments are intended solely for the
addressee(s) and may contain confidential
and/or legally privileged information. If you
are not the intended recipient of this message
or if this message has been addressed to you
in error, please immediately alert the sender
by reply e-mail and then delete this message
and any attachments. If you are not the
intended recipient, you are notified that
any use, dissemination, distribution, copying,
or storage of this message or any attachment
is strictly prohibited.
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
The contents of this e-mail message and
any attachments are intended solely for the
addressee(s) and may contain confidential
and/or legally privileged information. If you
are not the intended recipient of this message
or if this message has been addressed to you
in error, please immediately alert the sender
by reply e-mail and then delete this message
and any attachments. If you are not the
intended recipient, you are notified that
any use, dissemination, distribution, copying,
or storage of this message or any attachment
is strictly prohibited.
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