Re: [1904.2 TF] Use case of "Remote Manager" for EPON ONUs
Wasn't that what the whole DPoE architecture assumption was to begin with?Sent from my T-Mobile 4G LTE device------ Original message------From: Glen Kramer<000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>Date: Thu, May 7, 2020 3:44 PMTo: Curtis Knittle;STDS-1904-2-TF@xxxxxxxxxxxxxxxxx;Cc: Subject:RE: [1904.2 TF] Use case of "Remote Manager" for EPON ONUsYes, I think this is a similar situation. The key point is that regardless of where ONU Manager and ONUs are located, they always believe they are connected by a single point-to-point link. All the complexity of going over multiple L2 hops is hidden by the UMT sublayer. -Glen From: Curtis Knittle [mailto:C.Knittle@xxxxxxxxxxxxx] Sent: Thursday, May 07, 2020 2:36 PMTo: STDS-1904-2-TF@xxxxxxxxxxxxx.ORGSubject: Re: [1904.2 TF] Use case of "Remote Manager" for EPON ONUs Correct me if I’m wrong, but this looks like a situation where vCMs are located in another location somewhere in the network, with an 2 network in between !
“OAM Manager”
and the ONUs, using DPoE of course. From: Kevin Noll <kevin.noll@xxxxxxxxxxxx> Sent: Thursday, May 7, 2020 3:19 PMTo: STDS-1904-2-TF@xxxxxxxxxxxxx.ORGSubject: Re: [1904.2 TF] Use case of "Remote Manager" for EPON ONUs Let’s make time to discuss this on the call tonight. I think there are some significant implications if there is no OAM sublayer in the OLT’s PON stack. --kan----Kevin A. NollSr. Director, Systems ArchitectureTibit Communicationskevin.noll@xxxxxxxxxxxx From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>Date: Thursday, May 7, 2020 at 4:46 PMTo: Kevin Noll <kevin.noll@xxxxxxxxxxxx>, "stds-1904-2-TF@xxxxxxxxxxxxxxxxx" <stds-1904-2-TF@xxxxxxxxxxxxxxxxx>Subject: RE: Use case of "Remote Manager" for EPON ONUs Kevin, See inline, please. -Glen From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx] Sent: Thursday, May 07, 2020 12:57 PMTo: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; stds-1904-2-TF@xxxxxxxxxxxxx.orgSubject: Re: Use case of "Remote Manager" for EPON ONUs�
�Hmm…. Now that I
re-read that statement, it is confusing. The intent of the statement is to convey that the OAM-based ONU management functionality that would traditionally be in the OLT is being moved to an external entity (a general purpose server, probably).[GK: ] It is fine if the OAM client and OAM sublayer is moved together from an ONU-facing OLT port to a remote server. But I don’t think OAM client and OAM sublayer can be separated and still be compliant with and retain all the functionality per C57 in 802.3. The specifics of where the client resides or how it is split is what I am trying to figure out in the context of D0.6. I think there must be some lightweight version of the OAM client in the OLT, but if it’s there, then how does the OAMPDU get to it from the UMT SL? I don’t think the OLT’s OAM sublayer (on the PON side) can be removed or else the OLT loses key functions (loopback) that should not be moved to an external location.[GK: ] I think we all agree that we cann!
ot change anything
about OAM operation. It is defined in 802.3, and we are not chartered to re-write it or to define any alternatives. (In a proprietary implementation, vendors can do whatever they want, but this is not something that needs or should be discussed here.)Per 802.3, there is no possibility to split an OAM client among two different devices or to separate a client from the underlying OAM sublayer. I also wonder if the OAM sublayer needs to exist in the “Manager” side. For the purposes of OAM over UMT to manage the ONUs, I don’t think it needs to be there.[GK: ] OAM sublayer needs to be adjacent to OAM client. They cannot be separated. Lastly, is my depiction of the tunnel correct (terminating at the UMT sublayer on the PON side of the OLT)?[GK: ] Yes, the tunnel entrance and exit points are correct. The OLT doesn’t need to have OAM sublayer and OAM client facing the ONU. These blocks won’t receive any responses from the ONU. All the OAMPDUs that ONU sends will ente!
r a tunnel before they
reach OAM sublayer, so OAM client in the OLT will never be able to complete the OAM discovery with the ONU. Instead, the OAM client in the ONU Manger will complete the OAM discovery with the ONU. --kan----Kevin A. NollSr. Director, Systems ArchitectureTibit Communicationskevin.noll@xxxxxxxxxxxx From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>Date: Thursday, May 7, 2020 at 3:44 PMTo: Kevin Noll <kevin.noll@xxxxxxxxxxxx>, "stds-1904-2-TF@xxxxxxxxxxxxxxxxx" <stds-1904-2-TF@xxxxxxxxxxxxxxxxx>Subject: RE: Use case of "Remote Manager" for EPON ONUs Kevin, I can try later today or tomorrow. Can you describe what this sentence means: “OLT’s OAM Client is disaggregated and moved to the ONU Manager”?Does it mean the client is split in several pieces, or that it is separated from OAM sublayer, or that the client and OAM sublayer are simply moved together to the ONU Manager? -Glen From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx] Sent: Thursday, May 07, 2020 7:19 AMTo: Glen K!
ramer
<glen.kramer@xxxxxxxxxxxx>; stds-1904-2-TF@xxxxxxxxxxxxx.orgSubject: Use case of "Remote Manager" for EPON ONUs Glen, Please refer to the attached PPT. Could you answer the questions contained in the slides and adjust the diagrams to help us understand how this should work? --kan----Kevin A. NollSr. Director, Systems ArchitectureTibit Communicationskevin.noll@tibitcom.comTo unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1 To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1
________________________________________________________________________
To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1