Russ, On 4/19/14, 11:06 AM, "Russ White" <[email protected]> wrote:
>>IMO it would be near-sighted and extremely impractical to choose a >>language that only supported description on RIB info. I fail to see >>what is so special about RIB info that would warrant its own DML. > >So you'd argue that all the requirements in all the different use cases >can >be fulfilled with YANG? There is _nothing_ unique in _any_ of those use >cases the YANG model doesn't support? Do the analysis and prove it. > What you are asking for would be a lot of work for no practical purpose. Yang has been proven to work in practice for everything that we managed to throw at it. I have two data points: - In XR, we generated yang models from internal CLI schemas - we generated models for the entire CLI, for all features supported by XR, some 200 models overall. The entire system can be managed by NC/Y. - In OpenDaylight, we define APIs as yang models. We created yang models for OpenFlow, ACLs, BGP protocol and BGP RIB, PCEP Protocol and tunnel programming service, network wide services such as topology and inventory, etc. Overall, about 110 models in production code (overall, over 300 models have been defined, but a lot of them are for testing) In addition, we have started to create models for new service definitions both on device and off-device, such as policies, analytics, subscribers, security, new protocol definitions, Š We have not really run into any limitations. Also, as Andy pointed out, if yang does not cover something you need, you can define your own extension. So far, we only had to define a couple. Thanks, Jan _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
