Liaison statement
For Action: YANG model for CFM OAM
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2018-01-22 |
From Group | BROADBAND-FORUM |
From Contact | Joey Boyd |
To Groups | netmod, OPS, RTG |
To Contacts | Warren Kumari <warren@kumari.net> Benoit Claise <bclaise@cisco.com> Alia Atlas <akatlas@gmail.com> Alvaro Retana <aretana.ietf@gmail.com> Deborah Brungard <db3546@att.com> Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> Tom Nadeau <tnadeau@lucidvision.com> |
Cc | Joel Jaeggli <joelja@bogus.com> Deborah Brungard <db3546@att.com> David Sinicrope <david.sinicrope@ericsson.com> Alia Atlas <akatlas@gmail.com> Warren Kumari <warren@kumari.net> Alvaro Retana <aretana.ietf@gmail.com> The IETF Chair <chair@ietf.org> Lou Berger <lberger@labn.net> Benoit Claise <bclaise@cisco.com> Network Modeling Discussion List <netmod@ietf.org> Kent Watsen <kwatsen@juniper.net> |
Response Contact | michael.fargano@centurylink.com |
Purpose | For information |
Attachments | Liaise-121 Liaison response to IEEE.pdf |
Body |
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 |