Subject: [Rtg-yang-coord] Taxonomy of YANG models

From: Qin Wu <[email-masked]>
Date: Wed, 14 Jan 2015 10:41:17 +0000

Hi,
David and I talked about taxonomy of YANG model recently. I have applied such kind of taxonomy to the YANG models Summary table available at:
https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoordSummary#
e.g., we classify models in the summary table into several topic groups:
*  Topic Groups:
o a. IP ROUTING (Core routing, ISIS, OSPF,etc)
o b. MPLS (MPLS-TE, MPLS-TP, GMPLS,LDP,etc)
o c. Traffic Engineering (RSVP-TE, ISIS-TE, OSPF-TE,PCEP, etc)
o d. Data Plane Encapsulation (NVO3, SFC,Softwire,L2TPEXT)
o e. Service (IP VPN, ETH VPN, PW Service,etc)
o f. I2RS (RIB, Topo,etc)
o g. OAM (LIME, BFD, TRILL OAM, MPLS OAM,etc)
o h. Miscellaneous (QoS, ACL, SYSLOG, SNMP,etc)
We believe the taxonomy of YANG models is important and but needs more discussion on the list. Let us know if this Topic Group classification makes sense to you or you have any other input or correction.
Regards!
-Qin&David

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 15 Jan 2015 21:14:50 +0000

Qin,

I highly agree that classification is needed. Have few questions for you:

What you have listed is more a nomenclature then taxonomy/classification

Is your goal to achieve classification within routing area or across IETF?

For the classification, I would suggest to classify models broadly into
config
and
service models

Config models can be classified into standard and vendor proprietary models and service models can be classified into service components and service model.

Example
BGP config model

There is a common standard BGP config model and proprietary vendor model.

Service component is functional BGP config needed for a service, like Pseudowire MPLS L2VPN, which would be service model.

Once we can agree on such classification, we can discuss as next step hierarchical tree for models based on the above classification.

Dean
P.S. I'm in process of writing draft that explains to more details data model classification as above

On Jan 14, 2015, at 5:41 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

_______________________________________________
Rtg-yang-coord mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Qin Wu <[email-masked]>
Date: Fri, 16 Jan 2015 04:50:33 +0000

Hi, Dean:
发件人: Dean Bogdanovic [mailto:[email-masked]]
发送时间: 2015年1月16日 5:15
收件人: Qin Wu
抄送: [email-masked]; David Sinicrope
主题: Re: [Rtg-yang-coord] Taxonomy of YANG models

Qin,

I highly agree that classification is needed.

[Qin]: Thanks.

Have few questions for you:

[Qin]: The goal is more focusing on the former. That’s why we classify non-routing related models into Miscellaneous topic group.
In addition, not all yang related drafts are about YANG data model, so we can categorize yang related drafts into several parts:
o a. YANG Model
o b. YANG Language
o c. NETCONF Protocol extension
o d. YANG Guideline
o e. NETCONF Usage
o f. NETCONF Architecture

[Qin]: Interesting proposal, I think I classify these models more from routing area perspective while you classify models more from configuration management perspective.
I am wondering how config model and service model are related to device model, it looks we have service configuration, network configuration and device configuration, so
Is service model about service configuration model? If not, how service model is different from config model?

Example
BGP config model

[Qin]: my understanding is service model should use config model or core confgi model as basis.

Dean

[Qin]: Great, I am happy to review and contribute.

Hi,
https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoordSummary#<https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoordSummary>

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 16 Jan 2015 06:47:11 +0000

Hi Qin,

On Jan 15, 2015, at 11:50 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Dean:
7"<~HK: Dean Bogdanovic [mailto:[email-masked]<http://juniper.net>]
7"KMJ1: 2015Dj1TB16HU 5:15
JU<~HK: Qin Wu
3-KM: [email-masked]<mailto:[email-masked]>; David Sinicrope
VwLb: Re: [Rtg-yang-coord] Taxonomy of YANG models

Qin,

[Qin]: Thanks.

[Qin]: The goal is more focusing on the former. That!/s why we classify non-routing related models into Miscellaneous topic group.
In addition, not all yang related drafts are about YANG data model, so we can categorize yang related drafts into several parts:
o a. YANG Model
o b. YANG Language
o c. NETCONF Protocol extension
o d. YANG Guideline
o e. NETCONF Usage
o f. NETCONF Architecture

Sorry for not being clear. I was referring only to YANG models, not to other topics you listed.

the device model is the superset and then each next model is subset of the previous layer. The device or proprietary vendor config model contains all the supported features. The standard config model contains a common subset between proprietary config models. Service components are using parts on the standard and/or proprietary config models and service components are used to build the network service model.

Example
BGP config model

Yes, that is correct

Dean

Hi,
********  Topic Groups: