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

Re: [1904-ANWG] [1904.2 TF] January 2019 Consensus Building call - Call for Contributions


I think, generally, we are on the same page. 

A difference for me, though, is that I don’t understand why it is necessary to force the stack to have only ONE instance of OAM. As I hope to point out in the slides, if we are not adding additional requirements or clarifications about other protocols in the MAC layer (below UMT), then we don’t need them in the diagrams… it just adds confusion and unnecessary complexity. There is ample precedent for this approach and I give examples in the slides (OAM and MAC Control are two).

Also, don’t we need an instance of the OAM Sublayer above UMT, also? This is a topic I was going to bring up later or during the discussion tomorrow… if OAM is expected to work across a UMT, then it will need (at a minimum) the Control function in the OAM sublayer in addition to the OAM client.

Your diagram also precludes MAC Control from being a user of UMT. While I can’t see a practical use-case for MAC Control over UMT, I think that explicitly excluding it is unnecessary. 


On Jan 9, 2019, at 8:19 PM, Glen Kramer <glen.kramer@xxxxxxxxxxxx> wrote:



The 1b version of the layering shown on slide #22 (please, add slide numbers) is very close to what I envisioned for the layering.


One suggestion I have is to not show MA_CONTROL going through the OAM sublayer. The OAM sublayer has no notion of MA_CONTROL interface or the primitives.


Another suggestion is to show that a client, such as OAM client can sit on top of OAM sublayer, or on top of UMT sublayer  (with appropriate protocol adapter), or it can span both OAM and UMT. In other words, OAM client is not aware how the OAM data was encapsulated for transmission, as OAMPDU or as UMTPDU. All OAM client knows is that it gets a properly-formed OAMPDU or OAM_CTRL indication PDU and it must generate a properly formed OAMPDU or OAM_CTRL request.


So, here is a picture that addresses both points, I think.  Red text indicates the standard covering the respective blocks.







-----Original Message-----
From: Kevin A Noll [mailto:ieee.lists@xxxxxxxxxxxxxxx] 
Sent: Wednesday, January 09, 2019 1:20 PM
To: STDS-1904-2-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.2 TF] January 2019 Consensus Building call - Call for Contributions


I have received no other requests for time on the call tomorrow.


Attached to this email are updates to the presentations that I sent out on 6-Jan-2019.


These are the only two presentations on the agenda for tomorrow.




To unsubscribe from the STDS-1904-2-TF list, click the following link:

To unsubscribe from the STDS-1904-WG list, click the following link: