Well, the MU and MI items seem really bad.
Everything else in this list represents an immutable hardware configuration. If a service port is linked to eDVA, it is always linked to eDVA. This is how ONU can report its capability – port type values are hardcoded based on ONU design.
But MI and MU according to DPoE MEF spec are just different configurations
I suppose by changing classification rules to apply different VLAN/tunneling modes, we can change service port type from MI to MU and vice versa. How can ONU report its port type capability if it can change at runtime?
The Service Port Type Capability attribute should describe how a port is wired (design-time choice), not how it has been configured at run time. This attribute is commonly invoked before any of the ports are even provisioned.
I think CMCI, MI, and MU should all fall under the UNI-port type category. Querying the run time configuration of a UNI port simply means (a) to query the rules provisioned for this UNI port and (b) to analyze these rules with respect to what VLAN/tunneling mode they represent.
I hope I am wrong on this. In this case, I would appreciate any insight into how ONU knows whether a port type is MU or MI.
Thanks,
Glen
From: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>
Sent: Thursday, July 1, 2021 6:36 AM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] [EXTERNAL] RE: Service port types
Glen
Q1: Here is a list from the latest copy of DPoE-OAMv2.0.
It appears that 0x9-0xD are not included in the current version of SIEPON, unless I’ve missed a reference somewhere.
Q2: Currently I have not seen the use case to have multiple eSAFE elements embedded in an ONU device. I am not saying there couldn’t be, just hasn’t been discussed with me.
Marek, when you mention embedded switch, are you referring to some sort of eSAFE construct, or any simple switch which may exist in the ONU device? If it’s the later, I think, at least in DPoE, a Cable Modem Interface Mask (CMIM) can be utilized to address up to 16 UNI ports on an ONU device.
Ryan
From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> On Behalf Of Marek Hajduczenia
Sent: Thursday, July 1, 2021 7:17 AM
To: 'Glen Kramer' <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; stds-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] RE: Service port types
CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.
The only thing that comes to mind (and I hate to throw it in) is the case of a service port connecting to an embedded Ethernet switch. In this case, a single service port would be “split” into multiple UNI ports. The question on how to address individual UNIs is a separate challenge, since from the ONU perspective, they all look like a single service port. However, this is precisely what drove the addition of aPhyType attribute to address the case of a single service port terminating on a 1:2 Ethernet switch, where one UNI port is implemented as a pluggable cage and another UNI port as a standard RJ45 jack.
If we want to support such a scenario, we also need to consider if we want to be able to address individual UNI ports behind such an embedded Ethernet switch or not. It seems like a bit of a stretch for our scope of work, but on the other hand it is still part of an ONU 😊
Marek
From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> On Behalf Of Glen Kramer
Sent: Wednesday, June 30, 2021 5:51 PM
To: stds-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Service port types
Picking up the discussion from the last meeting on service port types.
These are the types currently defined in DPoE and SIEPON:
Q1: We decided to add another type for UNI_port. Also Ryan mentioned we need to add another type. What was this type?
Q2: Besides UNI ports, are there any service port types (i.e., eSAFE entities) that may exist as multiple instances in an ONU?
For example, can there be more than one eMTA or eDVA per ONU/CM?
Thanks,
Glen
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