On Fri, Apr 18, 2014 at 1:36 PM, Andy Bierman <[email protected]> wrote: > > > > On Fri, Apr 18, 2014 at 9:02 AM, Jamal Hadi Salim <[email protected]> wrote: >> >> I dont think a post like this is useful. >> State your reasons please - just cheering on is not helpful. >> > > It is as useful as +1, which IMO is useful. >
+1 is useful if it points to a technical point - not to "I like the guy with the blue shirt" without saying why. Andy, hate to go over your list and respond to it because that puts you on the defensive and the other thing is i am not sure what part of this is "requirements" for I2RS and what is "excellent things Yang has". Let me try but i worry i will be peppering over probably some of what you may feel are strong statements that need to be emphasized. > Availability of tools is important to developers who intend to implement > I2RS. > > I think there are also some technical reasons to use YANG: > > - YANG is protocol and encoding independent. It can be mapped to a > protocol > fairly easily. It supports XML now. A standards effort to support JSON > encoding > has been started in the NETMOD WG. A proposal to support EXI exists, > and support for CBOR is possible. > As a modelling language so is ForCES. The language is based on XML. The ForCES protocol is tied to the model but the model is not tied to the protocol. > - YANG supports definition of protocol operations, data nodes, and > notification events. > Data nodes are either configuration or non-configuration. XPath is used > to define > validation rules such as 'must' and 'when'. There rules apply differently > to > each context (operation, config data, non-config data, notification). > ForCES model does not support making protocol definitions. There are some basic protocol definitions assumed (GET/SET/DEL etc). Validation of constructs exists by virtue of the data model existing. > - The local config is related to operational state, especially since > operational values may > include configured values. YANG is already being used for configuration. > Using consistent data naming is important. A YANG instance-identifier is > an > absolute-path (restricted XPath) expression. > I think this is the point Tom Petch brought up as being problematic. When you have config and operational info - very likely end up with two subtrees. > - YANG supports external and conditional augmentation of any data model. > Each YANG module defines its own namespace. A module namespace can > be sub-divided with sub-modules. All nodes are identified with QNames, > using the YANG module or namespace as the extended name. This supports > non-centralized naming authority (i.e., vendor A and vendor B can both > augment > the same standard data node without any possibility of naming > collisions.) > ForCES is OO. The main building blocks are Classes known as LFBs. Each class has a name and an ID. While Classes define templates, Class instances are used when refering to components. Classes can be inherited to define new classes. > - YANG "features" allow optional functionality to be defined in a > data-model specific manner. > Conformance advertisement information is standardized so clients know > what options > are supported by each server implementation. > ForCES LFB class has a capability section which is used to advertise features. > - YANG "extensions" allow new language statements to be added to the > language, > These external statements must be parsed by every YANG compiler, even if > the compiler does not understand the extension. This allows YANG to be > easily > adapted for new applications, without the need to revise the language. > ForCES modeling does not have this feature. So while i attempted to address the different points - I am not sure which are requirements and which are not. cheers, jamal > >> jamal > > > Andy > >> >> >> On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau <[email protected]> >> wrote: >> > >> > Sorry for the top post, but I wanted to inject that for the >> > record, Brocade is in favor of using RestConf/Yang (or variations of those) >> > for I2RS. We have no interest in using FORCES as the basis for this. >> > >> > --Tom >> > >> > >> > On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim >> > <[email protected]> wrote: >> > >> >> On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic <[email protected]> >> >> wrote: >> >>> Jamal, >> >>> >> >>> Here are two criteria to be considered: >> >>> 1. technical >> >>> 2. commercial/business >> >>> >> >>> We can discuss pros and cons for both, but have to state that from >> >>> business perspective for >> >>> Juniper going with RESTCONF/YANG make more sense. We already built the >> >>> Junos model >> >>> in YANG and have or are in process of building needed tools. >> >>> Same goes for RESTCONF. We have NETCONF implemented in Junos and are >> >>> working >> >>> on RESTCONF implementation. >> >>> Many carriers adopted or are adopting NETCONF/YANG, are looking into >> >>> RESTCONF as well, so >this looks like a low hanging fruit from business >> >>> perspective. >> >>> >> >> >> >> Thanks for being sincere Dean. >> >> First, I will say I empathize with your view above (I understand such >> >> a view is motivation >> >> for many unfortunately often disguised as technical opinion). While i >> >> empathize, I would like >> >> to point that we need to have these discussions which are technical >> >> otherwise there is >> >> no point in having a standard. >> >> In any case I get where you are coming from. >> >> >> >>> Looking at technical aspect, unless there is a very compelling reason >> >>> (and there might be, but I'm >> >>> not aware of it), don't see reason to switch from RESTCONF and YANG. >> >> >> >> Maybe we'll bring up the topics sequentially as the thread proceeds - >> >> I'll start with >> >> 1 or 2 of what i think are requirements against protocol/model so we >> >> dont have to >> >> respond to long emails. If you have issues with ForCES please bring >> >> them up as well >> >> and we can discuss (I brought up a few in my presentation). >> >> >> >> One of the issues was throughput and latency. >> >> You stated in London that you want to be able to do a large amount of >> >> updates/sec. >> >> Other than you - I cant get anyone else to say this is a requirement. >> >> I do believe it is. >> >> It will be useful for example to come up with some hand waving numbers >> >> against >> >> some agreed-to info model (eg the rib) and see how this requirement is >> >> met by the >> >> different protocols. >> >> >> >> As for the model, I'd like to quote from the minutes what Tom Petch >> >> (who i consider to >> >> be a sage in this space): >> >> "If I was writing an info model I'd use YANG every time. But if I was >> >> writing a data >> >> model I'd go for ForCES." >> >> And this is rooted in the nature of Yang being intended for Config. >> >> >> >> There is also the issue of i2rs ability to describe instances which is >> >> lacking in Yang; >> >> but maybe leave that out to a different email.. >> >> >> >> cheers, >> >> jamal >> >> >> >>> We can find out down the line that RESTCONF/YANG was the wrong way to >> >>> go, but that >> >>> can be always changed. From my perspective it looks right today. >> >>> >> >>> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >> >>> >> >> >> >> _______________________________________________ >> >> i2rs mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> > >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
