DT YANG updates
Download
Report
Transcript DT YANG updates
Routing Area Yang
Architecture Design
Team Update
Members:
Wiki:
Repo:
Acee Lindem, Anees Shaikh, Christian Hopps,
Dean Bogdanovic, Ebban Aries, Lou Berger,
Qin Wu, Rob Shakir, Xufeng Liu, Yingzhen Qu
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangArchDT
https://github.com/ietf-rtg-area-yang-arch-dt/
Agenda
Short recap of DT status
Draft specific discussions
IETF 97
2
DT current “work” topics
1. WG drafts
2. OpState:
YANG Relationship of Config and
Operational State (and intended)
3. Conventions
New
Coming Soon
4. Model Classifications
IETF 97
3
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
4
Key Schema Mount
Requirements for Routing
1. 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
2. That a server can control which models are mounted
3. That all capabilities that exist with the mounted
module are available e.g. RPC operations,
notifications, and augmentations
4. 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
5
Schema Mount Xpath Issue
All Xpaths in a mounted model are relative to the
mount point.
Also requirement for absolute Xpath
Exactly what you want in many cases.
Example is when ietf-routing (RFC 8022) is mounted
in a Network Instance (e.g., VRF) and uses interfaceref (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
6
Status: OpState
Tracking NetMod DT
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
7
Status: Conventions
-00 draft
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
(Kudos to new DT members!)
Initial set defined
Please provide feedback and desired additions
Repo:
https://github.com/ietf-rtg-area-yang-archdt/conventions-features
IETF 97
8
Status: Model Classifications
Grew out of the original organizational model
discussion/draft
Basic idea is to provide a tag list for
identifying module types
Over last two meeting
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
9
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
11
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
Clarified instance instantiation
Editorial: references, IANA section
Open items
Including requiring YANG 1.1
Gated by schema mount
Next steps
Track schema mount
Add examples
IETF 97
12
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
13
draft-ietf-rtgwg-ni-model-01
Open Items (cont.)
module: ietf-network-instance
Definition of
+--rw network-instances
+--rw network-instance* [name]
network-instance-policy
+--rw name
E.g., RT and RD
Options:
Preferably reuse existing
modules
+--rw type?
+--rw enabled?
+--rw description?
+--rw network-instance-policy
| ...
+--rw root?
yang-schema-mount
| ...
Which is TBD?
Opinions?
Next steps
Address open items
Track schema mount
IETF 97
14
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
Provides administrative boundaries between users
It enables multiple tenants on single device
Bare metal server and VM
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
16
LNE tree example
managed
by device 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
managed
by tenant admin
augment /rt:routing/rt:control-plane-protocols/rt:ribs/rt:rib:
+--rw rib* [name]
| +--rw name
string
| +--rw address-family? identityref
+--rw bind-lne-name? string
IETF 97
Tenant admin creates
static routes and RIB
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 /if:interfaces/if:interface:
+--rw bind-lne-name? string
Assigning physical
interface to tenant
augment /if:interfaces/if:interface:
+--rw vlan-tagging? Boolean
Tenant admin designates the
assigned
Interface as type VLAN
augment /if:interfaces/if:interface:
+--rw base-interface? if:interface-ref
+--rw vlan-id?
uint16
Tenant admin creates VLAN
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:routing-instance/rt:ribs/rt:rib:
+--rw rib* [name]
| +--rw name
string
| +--rw address-family? identityref
+--rw bind-lne-name? string
IETF 97
Tenant admin creates static
routes and RIB
18
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
19
LNE cont’d
Top LNE
Child LNE
Child LNE
Interfaces
IETF 97
20
LNE cont’d
Top LNE
LNE
Child LNE
Child LNE
Interfaces
IETF 97
21
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
22
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:
+--rw bind-networking-instance-name?
string
augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-networking-instance-name?
string
IETF 97
23