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

[Dean Bogdanovic <[e-mail]>]

Hi Qin,

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

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

Qin,

I highly agree that classification is needed.

[Qin]: Thanks.

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?

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


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

[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?

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.


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.

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

Yes, that is correct

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

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

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


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


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