Markdown Version | Session Recording

Session Date/Time: 26 Feb 2025 09:00

NMOP

Summary

This interim meeting focused on an initial information exchange and exploration of cooperation between the IETF NMOP Working Group and the Broadband Forum (BBF) regarding network data collection architectures. The discussion included overviews of the BBF WT-508 (Broadband Network Data Collection) project and the IETF NMOP work on Yang Push to Message Broker integration. Key commonalities and differences in scope and approach were identified, leading to agreement on high-level next steps for continued collaboration.

Key Discussion Points

• Meeting Logistics: The session experienced initial delays as some BBF attendees encountered difficulties joining due to IETF Data Tracker account requirements. The Note Well was reviewed, emphasizing IETF policies for participation.
• BBF Liaison Statement and WT-508 Overview (Shu Yang, unnamed presenter)
  • The Broadband Forum (BBF) acknowledged and thanked IETF NMOP for its liaison statement concerning Automated Intelligent Management (AIM) and Broadband Network Data Collection (BNDC).
  • BBF’s WT-508 project, "Broadband Network Data Collection," is at an early stage. Its purpose is to define comprehensive data collection standards across broadband networks, including architecture, interfaces, protocols, and use cases.
  • The scope of WT-508 covers architectural definition, interface specification between components, standard data objects (models), use cases (real-time, on-demand, streaming telemetry), transport protocols, data encapsulation mechanisms, and recommendations for open-source tools.
  • The target publication date for WT-508 is estimated to be around mid-2026.
  • IETF experts were invited to the BBF Spring Meeting in Hong Kong, with a reminder that BBF membership or guest status (with participation limitations) is required.
• NMOP Message Broker Integration Overview (Thomas Scheibe)
  • The motivation for NMOP's work on Yang Push to Message Broker integration is to automate data processing pipelines, correlate network metrics while preserving semantics, and manage schema evolution over time.
  • IETF's Yang Push (RFC 8639/8641) aims to provide a scalable way to export Yang data, extending previous mechanisms like Netconf/Restconf.
  • The current NMOP architecture for message broker integration involves:
    • Managed Yang Push Subscriptions: Discovering network element capabilities and managing subscriptions.
    • Yang Push Receiver: Discovering schema dependencies via a Yang Library, registering Yang schemas in a natively supporting Yang Schema Registry, and translating subscription IDs to schema IDs for message brokers.
    • Data Consumers: Validating messages against schemas and assisting in schema creation for data storage.
  • Key enhancements introduced in Yang Push include:
    • Notification Envelope: Extending the notification header with hostname, sequence number, and observation timestamp for better indexing and source identification.
    • Versioning: Incorporating Yang module name, revision, and Yang Library content ID into Subscription State Change Notification messages to handle schema evolution.
    • Capabilities Exchange: Enabling discovery of transport protocols, encoding, and security for configured subscriptions.
    • Yang Library Extensions: Adding "augmented by" information to fully discover schema dependencies.
    • Anydata Validation: Describing the procedure for validating Yang "anydata" against a Yang schema.
    • Yang Push Light: An early-stage initiative to simplify Yang Push, streamline notification schemas, and narrow down XPath complexity.
  • The speaker noted that IETF Yang Push aims to address perceived gaps in gNMI implementations, such as interoperability issues, lack of comprehensive capabilities exchange, and missing subscription state change notifications for schema understanding.
  • Operator and vendor interest in this work has been observed from various entities including B. Canada, Deutsche Telekom, NTT, Swisscom, Huawei, Cisco, Siemens, Ciena, Juniper, and Nokia.
  • Implementation efforts (MVP1) are ongoing, with testing at IETF hackathons, focusing on the notification envelope and capabilities exchange. An OLT implementation is anticipated.
  • The architecture is designed to be open and potentially extensible to other protocols like IPFIX (which has similar data templates).
• Discussion on Cooperation and Architectural Comparison
  • Commonalities: Both NMOP and BBF WT-508 share an interest in standard interfaces for subscription management, data collection, data modeling, and data delivery. Both leverage and augment IETF Yang models. Both architectures enable use cases like Knowledge Graphs and Network Observability.
  • BBF Perspective (Bruno, Marco): WT-508 is a "top-down," service-based architecture that first defines functional building blocks (DCMF, DCF) before selecting specific protocols for interfaces. The ME-DCF interface is intended to be open to various methods (push, pull, bulk retrieval). Data Delivery Targets (DDT) are generic and can encompass storage or applications. The BBF work considers existing deployments and potential legacies, and aims to be domain-agnostic for the core data collection solution, with domain-specific specialization at lower layers. It was clarified that BBF's consideration of protocols is open and includes industry-recognized methods like IPFIX and gNMI, not exclusively Yang Push.
  • IETF NMOP Perspective (Thomas): NMOP's work is an evolution and improvement of the Yang Push protocol, driven by operator requirements for scalability and subscription flexibility. The focus is on automating schema evolution and data processing. NMOP's architecture explicitly includes data storage and the ability to manage schema changes throughout the data pipeline.
  • Points of divergence/further alignment:
    • BBF WT-508 does not currently have explicit requirements for schema change information, which IETF NMOP emphasizes.
    • The mapping of IETF NMOP components (e.g., Yang Push Receiver, Schema Registry, Data Consumers) to BBF WT-508's generic framework (e.g., DCMF, DCF, DDT) requires further refinement.

Decisions and Action Items

• Decision: The meeting was extended by 15 minutes to allow for foundational discussion due to initial delays.
• Action for IETF NMOP: The IETF NMOP chairs and document authors will work on articulating a clear argument explaining why IETF Yang Push is needed, outlining its specific advantages and problem-solving capabilities compared to existing solutions like gNMI/gRPC.
• Joint Action (IETF NMOP & BBF): Both groups will continue discussions to align on the scope and expectations of their respective architectures and the desired level of protocol work. This will involve continued engagement on mailing lists and potential attendance at each other's meetings.

Next Steps

• Continue the architectural and protocol discussions on the NMOP mailing list.
• IETF NMOP members may attend future BBF meetings to foster collaboration.
• The meeting minutes will be circulated to BBF colleagues for review and amendment before final publication.