1. 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:
Repo:

2. Agenda
Short recap of DT status
Draft specific discussions
IETF 97

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

4. 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

5. 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

6. 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

7. 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

8. 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:
IETF 97

9. 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

10. 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:

11. 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

12. 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

13. 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

14. 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

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

16. 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

17. 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

18. 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

19. 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

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

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

22. 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

23. 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