Hi, Mahesh: 发件人: Mahesh Jethanandani [mailto:mjethanand...@gmail.com] 发送时间: 2015年9月1日 3:10 收件人: Qin Wu 抄送: Acee Lindem (acee); netmod@ietf.org 主题: Re: [netmod] Motivations for Structuring Models
Qin, My question was more rhetorical. What I was trying to highlight was that the process of trying to define a strict overall tree like structure is fraught with issues. [Qin]: What LIME is doing is define the structure in the same way as routing-cfg did and provide common structure for various OAM technologies. Your interpretation of where oam-protocols reside on a device could be different from say Acee’s interpretation or mine. And who is to say, that interpretation is wrong. The other point, that Martin also brought up, is that today a BFD configuration typically looks like this in CLI (under an interface). Device(config-if)# bfd interval 50 min_rx 50 multiplier 5 You are asking that that should now look more like: Device# devices device lime bfd interval 50 min_rx 50 multiplier 5 or even: Device(config-if)# lime bfd interval 50 min_rx 50 multiplier 5 [Qin]: Why BFD extending from LIME model change this CLI configuration, why BFD extending from routing-cfg not change this CLI configuration? Based on your reason or concept, It looks you are proposing “ Device# devices device rt bfd interval 50 min_rx 50 multiplier 5 or even: Device(config-if)# rt bfd interval 50 min_rx 50 multiplier 5 “ by augmenting routing-cfg with BFD specific. In my understanding, whether you are using common structure of routing-cfg or using common structure of LIME model or “using its own structure without considering to interact with other OAM models”, it doesn’t change CLI used for BFD configuration. Let me give you another example, “ Device# devices device ospf interval 50 “ Do you think CLI will be changed as follows: “ Device# devices device rt ospf interval 50 “ When OSPF configuration model is extending from routing-cfg? My understanding is No. How does that make any more sense? On Aug 28, 2015, at 6:40 PM, Qin Wu <bill...@huawei.com<mailto:bill...@huawei.com>> wrote: Hi, Mahesh: Just want to clarify. I think what Routing DT team is doing is complementary to what LIME WG is doing. what routing DT team is doing is to identify all the existing models and the models that are under development for OAM, routing, interface, etc, to see how these models for different technology, protocol, feature(e.g., ACL, QoS) can fit together to form comprehensive structure and deliver the service. LIME work wants to provide common structure for various OAM technologies by defining generic YANG model for OAM. But the focus is to define generic YANG model for OAM. Based on LIME WG charter All the technology specific models are extension to this generic model. The relationship between these OAM related models can depicted as following: +-+-+-+-+-+ | LIME gen| |OAM YANG | +-+-+-+-+-+ | | +---------------------------------------------------------+ | | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | CFM | | MPLS-TP | | MPLS | | IP | . . .| foo | |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ | +-+-+-+-+-+ | | MPLS-TP | | MPLS | | . . .| foo | | |sub tech | |sub tech | | |sub tech | The example given by Acee is to provide a list of OAM protocols which need to be ready to configure a network instance. There is no overlapping. -Qin 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Mahesh Jethanandani 发送时间: 2015年8月29日 7:44 收件人: Acee Lindem (acee) 抄送: netmod@ietf.org<mailto:netmod@ietf.org> 主题: Re: [netmod] Motivations for Structuring Models Acee, This is going to become very interesting very quickly. Routing DT has decided to define a container for oam-protocols. LIME has decided it wants to define a generic YANG module for all OAM in draft-tissa-lime-yang-oam-model. Which model does BFD augment? Or did you just kill the whole charter for LIME?? On Aug 28, 2015, at 6:20 AM, Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>> wrote: Why doesn’t it help? In the next revision of the Routing YANG DT model, we’ve switched from including specific models to defining classes of models with identities. For example, grouping oam-protocols { container oam-protocols { list oam-protocol { key "type"; leaf type { type identityref { base oam-protocol-type; } mandatory true; description "The Operations, Administration, and Maintenance (OAM) protocol type, e.g., BFD, TWAMP, CFM, etc."; } description "List of OAM protocols configured for a networking instance."; } description "Container for list of OAM protocols configured for a networking instance."; } description "Grouping for OAM protocols configured for a networking instance."; } Then the grouping is include the networking-instances. By doing this, the intent is that it would be evident as to where a particular model would be found. Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
