An enterprise automation team must choose YANG models to push BGP config across Cisco IOS XE plus third-party devices, collect interface counters vendor-neutrally, and access Cisco-specific hardware telemetry. Which IETF, OpenConfig, and Cisco native YANG model mix best addresses this multivendor automation need?
Select an answer to reveal the explanation.
Short Explanation
You are mixing standards, vendor-neutral models and Cisco-only detail. OpenConfig keeps your BGP configuration and counters portable across vendors, while Cisco native models cover the hardware-only telemetry.
Full Explanation
OpenConfig is the vendor-neutral family that both Cisco IOS XE and third-party devices implement for BGP and interface data, so it fits multivendor BGP configuration and vendor-neutral counters, while Cisco native models expose platform hardware telemetry that no standard model covers. Using IETF models for BGP fails by concept because the IETF has not published a standardized full BGP configuration model as an RFC, so there is no portable IETF path to push; extending IETF models for hardware telemetry also fails because proprietary ASIC and environmental details are not standardized. Using Cisco native models for BGP fails multivendor automation because native paths exist only on Cisco platforms and do not translate to other vendors. Using IETF for BGP and IETF operational models for counters fails for the same missing BGP model, even though ietf-interfaces (RFC 8343) is a sound standard for basic interface data. Exam caveat: separate configuration intent from operational state and standard scope from platform scope, and remember IETF covers areas such as interfaces and basic routing while OpenConfig is the common cross-vendor choice for BGP. Practical check: confirm with YANG Suite or NETCONF get-schema that the OpenConfig BGP and interface modules are supported on each platform and software release before building pipelines.