Routing Area Yang Architecture Design Team Update Members: Acee Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Ebban Aries, Lou Berger, Qin Wu, Rob Shakir, Xufeng Liu, Yingzhen Qu Wiki: http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangArchDT Repo: https://github.com/ietf-rtg-area-yang-arch-dt/

Agenda Short recap of DT status Draft specific discussions IETF 97

DT current “work” topics WG drafts OpState: YANG Relationship of Config and Operational State (and intended) Conventions Model Classifications New Coming Soon IETF 97

Status: RTGWG drafts Started with so called Meta-Model Now: 2 Standards Track Models Logical Network Element (draft-ietf-rtgwg-lne-model) Network Instance (draft-ietf-rtgwg-ni-model) Both use schema mount 1 Informational Meta Model Network Device YANG Organizational Model (draft-rtgyangdt-rtgwg-device-model) Expect related draft on model classification soon IETF 97

Key Schema Mount Requirements for Routing That any data model can be instantiated within another module Instantiated means that information is maintained only within the ‘mounted’ context This use case only requires mounting of top-level models That a server can control which models are mounted That all capabilities that exist with the mounted module are available e.g. RPC operations, notifications, and augmentations That no additional model is needed to support 1 The schema defines what other modules can be mounted (Note used by LNE or NI modules) IETF 97

Schema Mount Xpath Issue All Xpaths in a mounted model are relative to the mount point. Exactly what you want in many cases. Also requirement for absolute Xpath Example is when ietf-routing (RFC 8022) is mounted in a Network Instance (e.g., VRF) and uses interface-ref (RFC 7223) Absolute path to interface-list is needed (at least this is the intension of NI and LNE) Have some thoughts on how to solve Plan to work with DT and schema mount authors IETF 97

Status: OpState Tracking NetMod DT Note: See A Revised Conceptual Model for YANG Datastores draft-nmdsdt-netmod-revised-datastores-00 Note: draft-ietf-netmod-routing-cfg about to be published Follows RFC7223 –config/-state convention RFC6087bis about to be published Section 5.23 provides related guidance, but not a simple directive IETF 97

Status: Conventions -00 draft (Kudos to new DT members!) Routing Area Common YANG Data Types draft-rtgyangdt-rtgwg-routing-types-00 Covers types expected to be generally useful to YANG modules developed in the routing area Initial set defined Please provide feedback and desired additions Repo: https://github.com/ietf-rtg-area-yang-arch-dt/conventions-features IETF 97

Status: Model Classifications Grew out of the original organizational model discussion/draft Over last two meeting Basic idea is to provide a tag list for identifying module types Covering both well known and unstructured types Assigned during module definition, by vendor or by user Draft should be available soon 2 modules expected: Reusable grouping and an augmentation to library IETF 97

Update on draft-ietf-rtgwg-device-model-01 draft-ietf-rtgwg-ni-model-01 draft-ietf-rtgwg-lne-model-01 Authors: Acee Lindem, Christian Hopps, Dean Bogdanovic, Lou Berger Repo: https://github.com/ietf-rtg-area-yang-arch-dt/meta-model.git

draft-ietf-rtgwg-device-model-01 Draft provides a conceptual model of how modules fit together on a generic network device Recent changes: Really just references Planned changes Editorial: Clarify that this is a logical structure Align text with module classification draft (once published) Change module to be an example This change is already in the repo IETF 97

Recent changes: draft-ietf-rtgwg-lne-model-01 Provides a model of logical device control Recent changes Aligned with latest rev of Schema Mount draft-ietf-netmod-schema-mount Including requiring YANG 1.1 Clarified instance instantiation Editorial: references, IANA section Open items Gated by schema mount Next steps Track schema mount Add examples IETF 97

draft-ietf-rtgwg-ni-model-01 Provides a model of VRFs/VSIs control Recent changes: Aligned with latest rev of Schema Mount draft-ietf-netmod-schema-mount Including requiring YANG 1.1 Clarified instance instantiation Editorial: references, IANA section Open items: Gated by schema mount Security section Examples IETF 97

draft-ietf-rtgwg-ni-model-01 Open Items (cont.) module: ietf-network-instance +--rw network-instances +--rw network-instance* [name] +--rw name +--rw type? +--rw enabled? +--rw description? +--rw network-instance-policy | ... +--rw root? yang-schema-mount Definition of network-instance-policy E.g., RT and RD Options: Preferably reuse existing modules Which is TBD? Opinions? Next steps Address open items Track schema mount IETF 97

To be presented in RTG WG Friday Morning Session I Details and Examples To be presented in RTG WG Friday Morning Session I

Logical Network Element Logical Network Element represents a separate administrative domain on the device It enables multiple tenants on single device Bare metal server and VM Provides administrative boundaries between users Users decide which services they want to run (authorization pending) Recursive (in theory) LNE in a LNE Top LNE has hardware controls, like CPU, fan, power, chassis etc Child LNE has all system management functions other then the hardware platform specifics IETF 97

LNE tree example managed by device admin managed by tenant admin created by device admin +--rw logical-network-elements +--rw logical-network-element* [name] +--rw name string +--rw managed? boolean +--rw description? string +--rw root? augment /rt:routing/rt:control-plane-protocols/ rt:routing-protocol/rt:static-routes: +--rw static-routes +--rw bind-lne-name? string augment /rt:routing/rt:control-plane-protocols/rt:ribs/rt:rib: +--rw rib* [name] | +--rw name string | +--rw address-family? identityref managed by device admin Tenant admin creates static routes and RIB managed by tenant admin IETF 97

LNE tree example managed by device admin managed by tenant admin created by device admin +--rw logical-network-elements +--rw logical-network-element* [name] +--rw name string +--rw managed? boolean +--rw description? string +--rw root? augment /if:interfaces/if:interface: +--rw bind-lne-name? string +--rw vlan-tagging? Boolean +--rw base-interface? if:interface-ref +--rw vlan-id? uint16 augment /rt:routing/rt:control-plane-protocols/ rt:routing-protocol/rt:static-routes: +--rw static-routes augment /rt:routing/rt:routing-instance/rt:ribs/rt:rib: +--rw rib* [name] | +--rw name string | +--rw address-family? identityref managed by device admin Assigning physical interface to tenant Tenant admin designates the assigned Interface as type VLAN Tenant admin creates VLAN managed by tenant admin Tenant admin creates static routes and RIB IETF 97

Notable topics Assinging resources to child LNEs Interface QoS Providing correct access to the tree Managed and unmanaged cases Unmanaged – all data inside child LNEs is opaque to the parent LNE Managed – all (some?) data inside child LNEs is visible to the parent LNE IETF 97

LNE cont’d Top LNE Child LNE Child LNE Interfaces IETF 97

LNE cont’d Top LNE LNE Child LNE Child LNE Interfaces IETF 97

Network Instance Network instance provides routing and switching separation It is part of single LNE Tenant admin has full administrative rights to create and destroy NIs within its LNE IETF 97

Example: NI Model module: networking-instance +--rw networking-instances +--rw networking-instance* [name] +--rw name string +--rw type? identityref +--rw enabled? boolean +--rw description? string +--rw networking-instance-policy | ... +--rw root? augment /if:interfaces/if:interface: +--rw bind-networking-instance-name? string augment /if:interfaces/if:interface/ip:ipv4: augment /if:interfaces/if:interface/ip:ipv6: IETF 97