RE: [1904.4 TF] [EXTERNAL] RE: Service port types

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

That’s a great question Glen. I’ll defer to Steve B, Curtis or Marek to see if they have some historical context as I do not.

Ryan

From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Thursday, July 1, 2021 1:20 PM
To: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] RE: Service port types

Thank you, Ryan,

I think with the possible exception of MI/MU (see my previous email) we should add missing code points to the 1904.4.

In the DPoE Arch figures, it also shows “eWiFi” embedded entity. But there is no codepoint for it. Do we need it?

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

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