Jamal and Tom: Dean Bogdanovic and Ron Bonica clearly indicated there were two reasons: business and technical. My understanding is that Ed Crabbe's context for this discussion was to judge technical merit. Did I misunderstand the context of this discussion to be engineering?
If this is an engineering discussion - Tom it would be helpful to discuss the engineering reasons for Brocade's choice for restconf/yang. Some good engineering reasons might be that the Vyatta acquisition provided them with a tool chain that was ready for the restconf/yang. You could further comment on if the Vyatta deployments with restconf/yang were able to pull massive amount of routes or status? Did early deployments of Vyatta's took chain in data centers or WAN networks encounter any problems? Did you easily integrate new features? The web buzz on this sounds like a bee-hive buzzing, so ... the engineering details would be great. And since Vyatta is open source ... Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Jamal Hadi Salim Sent: Friday, April 18, 2014 12:03 PM To: Thomas Nadeau Cc: [email protected]; Crabbe Edward; Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model I dont think a post like this is useful. State your reasons please - just cheering on is not helpful. cheers, jamal 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
