1 of 11

May 2022 IESG Retreat

Rob Wilton, Éric Vyncke, Qin Wu

Managing the evolution of IETF YANG Modules

2 of 11

Today

IETF is slowly publishing lots of YANG Modules in RFCs

  • Protocol specific device modules
  • Some work on service and network-wide YANG modules (LxSM, LxNM, topology, UNI)

3 of 11

Goal

Also the goal for OpenConfig YANG

Produce a standard common API for configuring and managing devices

4 of 11

Problems

  • IETF is not focused on a cohesive complete mgmt. API (i.e., DMs)
  • RFC 7950 rules prevent fixing mistakes
  • IETF is way too slow
  • OpenConfig is getting much more market traction
  • Fracture in the market slows adoption

5 of 11

OpenConfig

… has its own issues too

  • Too frequent churn
  • Unclear governance path
  • Focus is on a few operator’s requirements
  • Technically less flexible

6 of 11

In the IETF pipeline

  • Semantic Versioning
  • Allow non-backwards-compatible changes
  • YANG packages

7 of 11

Remaining Problems

  • IETF is not focused on a cohesive complete mgmt. API
  • RFC 7950 rules prevent fixing mistakes
  • IETF is slow to standardize

8 of 11

Idea

Fundamentally change how the IETF manages code assets like YANG

​

I.e., stop treating them as documents.

  • Store canonical YANG files somewhere else (not in RFCs), e.g., IANA, RFC Editor, Github, YANG Catalog?
  • Develop YANG in Github, version using Semver
  • Informational YANG RFCs describe module + short stable URL reference to canonical YANG
  • Allow the YANG to evolve with bugfixes, errata, features
  • Allow YANG RFC to evolve (e.g., living documents)

9 of 11

Idea 2

Manage the YANG as if it is a programmatic API

​

Develop in Github

Update RFCs as living docs

Stable Branch:

  • New changes (pull requests)
  • Must compile & be compatible
  • Must achieve WG level consensus before merge

​

PS Branch:

  • Periodically publish experimental branch
  • Also store archival copies (IANA/RFC Editor)?
  • IETF LC/IESG review?

10 of 11

Questions/�Comments

  • How would the IETF consensus process work?
  • Where do we store canonical PS copy (RFC editor, IANA, Yang Catalog)?
  • Will IETF have an existential crisis that these are not RFCs?

​

  • Next steps: Experimental RFC to propose process?

​

11 of 11

Top 4 issues in IETF YANG modules lifecycle management

11

IETF Device Level lifecycle Module Mgmt

Openconfig counterpart model progress is stagnant

High bar for IETF mount structure implementation

(i.e., Schema Mount)

c.f., Openconfig

Tooling eco-system lagged behind

YANG Module Revision NBC change handling

e.g., BESS EVPN/L3VPN/L2VPN model, BGP model, QoS model has slow progress, lack multi-vendors interoperability test

IETF modules published in IETF YANG github is highly

dependent on Schema Mount for integration

Integration cost is more expensive than Openconfig static device structure solution

YANG != API

Lack good tool chain and documentation

Allow NBC will lead to multiple releases of the same set of YANG modules, Model versioning can be used to identify each release automatically

Solutions:

  1. Identify leadership in BESS YANG and replace original authors
  2. OPS AD get involved to facilitate standardization
  3. Engage with EANTC

For multi-vendor interoperability test

​

Solution:

  1. Propose Hackathon Project to implement Schema Mount

​

Solutions:

  1. NBC Checking Tool Open source.
  2. If there are NBC changes in existing published RFCs, using IETF YANG github to update YANG

​