Liaison statement
For Action: YANG model for CFM OAM

Thank you for your liaison dated December 7th; 2017 on YANG for CFM.
We take note of your intention to follow the updated datastore guidelines
produced by the IETF Network Management Datastore Architecture Working Group.
Our currently published YANG model and the one we are sending you implements
the legacy best practice of separate configuration and state trees.
Nevertheless, the Broadband Forum recognizes the direction IETF has taken and
will be reviewing once the RFC is published. In the next few pages, we hope to
address the questions that were raised in your liaison, specifically: - BBF’s
requirements, usage scenarios, and priorities for CFM and its YANG support in
P802.1Qcx - BBF TR-383a1 models referenced in your latest liaison - 
BBF-identified modifications that would need to be made to MEF 38 and 39 -
BBF’s timeline for completion of the “draft CFM OAM YANG model”

We confirm that BBF requirements cover OAM functionality at large, including
requirements from IEEE, ITU-T and MEF. The BBF does require the management of
MIPs including MIP creation.

For the sake of alignment with IEEE 802.1Qcx, the BBF will take into account
the CFM OAM work of IEEE and others as long as it meets the BBF’s time frames.
We have a model that will serve our purposes (see CFM OAM YANG model contained
in BBF liaison LIAISE-84 transmitted 2017 September 14); we would like to align
our work with that being done by the other organizations. If a coordinated
model can be completed by the end of 2018, the BBF would be happy to reference
it.

BBF Requirements
General requirements
Many BBF applications require support for some or all of Ethernet OAM
functionality as defined by IEEE 802.1ag and ITU-T Y.1731. For example, TR-101
section 7 defines Ethernet OAM requirements and scenarios based on IEEE
802.1ag, TR-301i2 section 13 defines Ethernet OAM requirements based on
IEEE802.1ag (CFM) and ITU-T Y.1731, the latter scoped to Fault Management (FM)
and Performance Monitoring (PM). The BBF takes the following points of
reference for defining the scope of a YANG model: - IEEE 802.1ag Connectivity
Fault Management - ITU-T Y.1731 OAM functions and mechanisms for Ethernet-based
networks - MEF 7.2 Carrier Ethernet Management Information Model - MEF 17
Service OAM Requirements & Framework – Phase 1 - MEF 30.1 Service OAM Fault
Management Implementation Agreement - MEF 35.1 Service OAM Performance
Monitoring Implementation Agreement.

BBF YANG model-specific requirements

Leverage power of the YANG language to its full advantage.

Use YANG features to mark portions of the schema tree as conditional to enable
devices to advertise support for functional subsets of IEEE 802.1ag, ITU-T
Y.1731, MEF 30.1 and MEF 35.1

To achieve a standardized solution supporting many different applications, the
core YANG model to manage CFM must be generic and independent of any specific
technology or implementations, such as the L2 forwarding model, notifications
and alarm management models used. Management of technology-specific or
application-specific aspects needs to be augmented into the core YANG model as
separate standardized YANG modules as required, such as to support the BBF L2
Forwarding model or IEEE 802.1Q Bridge model, add application-specific
notifications and alarms to support the implementation in the given application.

The core CFM YANG model supporting IEEE 802.1ag must be structured in such a
way as to support augmentation of additional functionality defined in ITU-T
Y.1781, MEF 30.1, MEF 35.1 and future standards in a consistent way.

The YANG model must be easy to update as new requirements emerge.

Overview of BBF Concerns with MEF SOAM YANG Model
- The MEF YANG modules are based on and tightly coupled to the IEEE 802.1Q
Bridge model, whereas BBF YANG-managed applications use the BBF’s Layer 2
forwarding YANG model. Thus, a YANG model to manage Ethernet Service Layer OAM
would need to be independent of any specific forwarding model. The BBF would
expect a core OAM management model that is independent of and agnostic to any
specific forwarding model and which is augmented by separate YANG modules as
required, adding the necessary support to manage the Ethernet Service Layer OAM
aspects specific to specific forwarding models. - The model does not allow for
selective support of specific features using YANG feature statements. - There
is no explicit support for the direct creation of Maintenance Intermediate
Points (MIP).

Deficits of the MEF SOAM YANG Model
- Does not support if-feature portions of the schema tree, such as IEEE 802.1ag
fault notification, linktrace, specific RPCs, indirect MIP creation. - Does not
support explicit configuration of custom lower-bound values for measurement
bins. - Does not differentiate between stateless and stateful TCA reporting as
defined in MEF 35.1.
     - No ‘clear threshold’ can be defined, implying only stateless TCA
     reporting supported.
- Proactive loss and delay measurement sessions are created by RPC and as such
are non-persistent. - The YANG module ‘mef-soam-pm’ allows configuration of the
number of bins per bin type for Delay Measurements, but there appears no means
to configure the lower bounds of each bin.

Errors and Gaps in the MEF YANG Model
In their liaisons L00259 and L00260 to the ITU-T dated February 2017, the MEF
lists reported errata and gaps in the published MEF38 and MEF39 specifications.

The BBF draft Ethernet Service Layer OAM Management YANG Model
The current version of the BBF draft YANG model supporting the management of
Ethernet Service Layer OAM is the initial baseline draft and is as such not
intended to be complete and is consequently subject to further modification and
refinement.

Different approaches taken by the BBF draft model to those of MEF 38 and 39
The following are the modifications (non-exhaustive) that the BBF has
identified that would need to be made to MEF 38 and MEF 39. -  MIPs
      - The BBF model adds support for direct creation (configuration) of MIPs.
      - The direct creation of MIPs allows an operator complete control as to
      where in the network MIPs are to be located.
       - Support for indirect MIP creation is for further study.
-MIP identifiers
      - MIPs created within a Maintenance Association are managed by means of a
      list ‘mip’ and to provide a key for each entry in the list, a leaf
      ‘mip-id’ has been defined. The name ‘mip-id’ was selected to align with
      ‘mep-id’. The ‘mip-id’ is a YANG requirement only and has no relevance to
      the operation of CFM or its protocol functions.
-Measurement bins and measurement bin profiles
       - The BBF model introduces the concept of a bins profile for Delay
       Measurements. - Bins profiles are pre-configured and referenced on DM
       session creation. - Since a bins profile completely specifies the
       required bins, the bins themselves do not subsequently need to be
       modified as in the MIB implementation.
- Threshold Crossing Alerts (TCA) reporting
      -  The BBF model introduces a ‘tca-profile’ that supports configuration
      of both stateless and stateful TCA functions.
-Support for proactive and on-demand PM sessions.
      -  Proactive PM sessions are required to be persistent and are thus
      managed through configuration only.
- A configured session is implicitly a ‘proactive’ session.
-  Proactive sessions are enabled/disabled through configuration
    - On-demand sessions are managed by RPC calls only and thus are not
    persistent. - Both proactive and on-demand sessions are listed in the
    ‘session’ list in state data.
           - The state-data-only leaf ‘session-type’ differentiates a proactive
           session from on-demand session created by RPC.
- YANG schema tree
     -  Leverage the use of containers to encapsulate related data nodes and
     provide more structure to the schema tree. - Gives the added advantage of
     being able to if-feature the container. - Some nodes have been renamed for
     greater consistency across the complete model. - Use of YANG features to
     allow for explicit non-support of optional functions. -  Use of when
     statements where there is an explicit dependency on another part of the
     schema tree. - Some minor reorganization of the schema tree to better
     model the functional relationships and dependencies, such as the
     remote-mep-database is seen as a function of the continuity check and
     therefore located within the continuity-check container and not at the
     same level.

Omissions in the BBF draft model
In the MEF model, but omitted in the BBF draft model due to dependency on the
L2 forwarding layer
      - default MD levels (top-level)
      - configuration error list (top-level)
      - component-list (configured within a maintenance association)
      -and as a consequence, the following are currently not supported and are
      for further study
          -mep-port-status-tlv-included, mep-interface-status-tlv-included,
          peer-mep-info-aging-time.

In the MEF model, but omitted in the BBF draft model due to dependency to alarm
management
      - last-defect-sent

For Further Study
     - ETH-AIS
     - Implicit MIP creation
     - Support of Test ID for certain PM measurements
     - Set of performance metrics are to be supported for TCA in the BBF model
     - Operational status for TCA reporting

Timeline for Completion of the BBF Ethernet Service Layer OAM Model

Ideally the BBF would like to have a stable CFM OAM YANG model available for
publication by end of 2018. For the sake of alignment with IEEE 802.1Qcx, the
BBF agrees to put on hold its BBF YANG model work on CFM OAM in anticipation of
IEEE and other affected SDOs to complete their work.

We look forward to your response.

Sincerely,

Michael Fargano,
Broadband Forum Technical Committee Chair