On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares <[email protected]> wrote:
> Behcet: > > > > Can you tell me how the ONF Management and configuration protocol will > interface with the routing system with all the requirements set forth by > the architecture document? Please refer to version 2.0 architecture > > > Don't get me wrong. I am not speaking in favor of OF-Config. But the point is that a more realistic choice should be between these two choices. If the study showed that OF-Config did not meet the requirements, that is fine but I heard no one said that. I wonder if the forces protocol meets these requirements? Behcet > Or review to the presentation at IETF. If you can present these features > in email or any substantial way, we will listen. In my observations, the > ONF management protocol was designed for the ONF flows and not the > information models required or the use case required. > > > > Sue Hares > > > > *From:* i2rs [mailto:[email protected]] *On Behalf Of *Behcet Sarikaya > *Sent:* Friday, April 18, 2014 11:32 AM > *To:* Dean Bogdanovic > *Cc:* [email protected]; Edward Crabbe; Jamal Hadi Salim > *Subject:* Re: [i2rs] consensus on I2RS protocol and model > > > > Hi Dean, > > I attended i2rs session in London on this issue. > > > My question is why ONF Management and Configuration protocol (OF-Config > 1.2) was not on the table. > > Regards, > > Behcet > > > > On Fri, Apr 18, 2014 at 8: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. > > 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. > 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. > > Dean > > > On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim <[email protected]> wrote: > > > Ok, since nobody is saying anything i'll bite. > > How would you like for this discussion to proceed? > > > > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe <[email protected]> wrote: > >> Dear I2RSers, > >> > >> At the last I2RS WG meeting there was a great deal of conversation > >> regarding selection of both modeling language and underlying transport > >> protocol. Consensus at the time was to make use of Yang and (NetConf or > >> RestConf) (unclear). > >> > > > > And i believe the view, as correctly presented by you, is for folks to > go back > > and make educated decisions by actually getting knowledgeable about > > the different views presented. "Consensus" that you described above > > to me looked like a pageant popularity contest not based on anything > > technical ("who likes contestant in the blue shirt? please cheer for > them"). > > > > In my opinion i dont think the requirements are clear. > > > > Will that get the crickets stop chirping? > > > > cheers, > > jamal > > > >> Before coming to a final consensus, we'd like to give people adequate > time > >> to review source material, marshall arguments and discuss on the mailing > >> list. To this end, we're asking that interested parties do just this > over > >> the course of the next ~two weeks. Following that period, on 4/28, > we'll be > >> initiating a consensus call that will last an additional two weeks, > with the > >> aim of converging modeling language / protocol by Friday, 5/9. > >> > >> The consensus call should also generate proposals for any material > changes > >> required to the underlying protocols. These proposals in turn will > form the > >> basis for a later draft including gap analysis and said changes. Those > >> strongly in favor of one protocol over another should be prepared to > >> contribute to this analysis. > >> > >> > >> best, > >> > >> -ed > >> > >> _______________________________________________ > >> 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 > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
