+1 for Netconf for the I2RS protocol and YANG for the modeling language. On 4/18/14 3:04 PM, "Jeff Tantsura" <[email protected]> wrote:
>+1 for Netconf/YANG for the i2rs protocol and for YANG as >the modeling language. > > >Cheers, >Jeff > > >-----Original Message----- >From: "Jan Medved (jmedved)" <[email protected]> >Date: Friday, April 18, 2014 1:59 PM >To: Dean Bogdanovic <[email protected]>, Jamal Hadi Salim ><[email protected]> >Cc: "[email protected]" <[email protected]>, Edward Crabbe <[email protected]> >Subject: Re: [i2rs] consensus on I2RS protocol and model > >>Cisco is also implementing Netconf - it¹s available on XR today, and it >>will be available on other platforms as well. >> >>For OpenDaylight, we chose Yang as the IDL to describe internal and >>external APIs in the controller and so far it has served its purpose >>really well. >> >>Also, as Tom pointed out, Netconf and Restconf have also been implemented >>in ODL. I¹d like to stress that we not only have multiple >>Netconf/Restconf >>implementations from multiple vendors (Brocade, Juniper, Cisco, just to >>mention those on this thread), but have multiple open source >>implementations as well. In addition to ODL, there is libnetconfd and a >>few others. ODL / libnetconfd interop testing is done in the ODL >>regression test suite. Now, since there are multiple independent open >>source implementations, we¹ve got a good ecosystem for implementation of >>new Netconf/Restconf/Yang features that may be required to meet i2rs¹s >>needs (if the need to evolve the protocols/language arises). >> >>In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang as >>the modeling language. >> >> >> >>Thanks, >>Jan >> >> >>On 4/18/14, 6: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 > >_______________________________________________ >i2rs mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
