On Apr 18, 2014, at 11:43 AM, Thomas Nadeau <[email protected]> wrote:
> > On Apr 18, 2014:2:37 PM, at 2:37 PM, Andy Bierman <[email protected]> wrote: > >> >> >> >> On Fri, Apr 18, 2014 at 11:30 AM, Thomas Nadeau <[email protected]> >> wrote: >> >> On Apr 18, 2014:2:21 PM, at 2:21 PM, Jamal Hadi Salim <[email protected]> >> wrote: >> >> > On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau <[email protected]> >> > wrote: >> >> >> >> Why is that not useful? Because I didn't say I was in favor of >> >> forces? *) >> > >> > Not at all. Your statement was more like a high five. It is ok to >> > raise your hand at >> > the meeting - but i was hoping the list would have more useful >> > technical discussion. >> > >> >> It IS useful to say that my company's products implement Yang/Netconf and >> >> will support RestConf, >and therefore a derivative of those technologies >> >> used for i2rs is preferred. We have no plans to >support any of the other >> >> discussed options in i2rs such as Forces at this time. The reasons are >> >> >simple: our customers asked for Netconf/Yang models and as far as I can >> >> tell, have no interest in >Forces. >> >> >> > >> > So again it boils down to "bussiness" reasons - am i wrong? >> >> Yes, but not in the way you imply. My company has implemented >> Yang/Netconf because our customers have asked us to and because when we did, >> they bought our equipment - not as you imply, because we think its cool. >> There are a number of other major hardware vendors on this list that have >> done the same. I think if you poll most of those vendors, you will find that >> they generally don't engineering resources to things that people don't buy. >> Also, Open Daylight has gone with Netconf/Yang/RestConf as one of its >> primary interfaces - there are dozens of vendors working on that project >> too. As far as I can tell, no one has done any programmable interface based >> on Forces there. That seems to be an overwhelming number of implementations >> that have gone with yang/netconf/restconf. >> >> >> It would be just as valid for people to chime in "We already use ForCES" >> or "we use already OF-Config", as a reason to use it for I2RS. > > It would, and I think that is what the chairs are trying to assess so > chime on in! While we (the ONF contributors) have explicitly tried to keep the OF-CONFIG specification language and protocol agnostic, but the only currently available implementation-ready language and transport mapping available is YANG and NETCONF. So in reality, OF-CONFIG is currently NETCONF with a YANG module maintained by the ONF. > --Tom > >> >> >> Andy >> >> > "we have an implementation of Yang/netconf"; >> > "we are going to make it work for I2RS". >> > If thats the case - then lets just end the discussion. >> > I am hoping to get the answer to: >> > What are the technical requirements/arguements? >> > Why do i have to struggle so much in a technical environment like IETF for >> > someone to come out and say what the requirements are? >> > >> > I can assure you that i have no religious conviction that say it has >> > to be ForCES. >> > Lets actually start with you showing me how netconf/yang meets the >> > requirements. >> > Otherwise - please stop with the high fives. >> > >> >> From my perspective, continuing to debate which protocol is >> >> derived to become i2rs is a waste >of everyone's time. >> > >> > Whats the point to having a circus show in pretending we are trying to >> > get any consensus? >> >> I am not WG chair, so I will let Ed/Jeff comment on the circus. *) >> >> > Its clear what people want from the meeting, and if you poll interested >> > implementations you'll likely >get the same answer: yang/netconf/restconf. >> > Lets please stop delaying i2rs and get some work >done here. >> >> >> > >> > When you go and ask people to raise their hands they will. You need to >> > ask them why >> > they are raising their hands. I am hoping this is not a staked >> > popularity contest. >> >> Well, at some point it does come down to running code and real, >> deployed implementations, right? As I said above, there are many real and >> significant implementations of yang/netconf in the marketplace *today*. >> Asking those things to be modified slightly isn't that big of a deal in >> order to address the requirements. Implementing a completely new protocol >> is. I am not totally against new protocols - its just that if we can achieve >> the goals we have by hacking an existing implementation, that makes better >> engineering and business sense. >> >> --Tom >> >> >> >> > >> > >> > cheers, >> > jamal >> > >> > _______________________________________________ >> > 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 -- Carl Moberg VP Technology twitter: @cmoberg http://www.tail-f.com/ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
