+1 for Netconf for the I2RS protocol and YANG for the modeling language. Thanks, Ramki (Brocade Communications Systems, Inc.)
-----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Geoffrey Mattson Sent: Friday, April 18, 2014 3:11 PM To: Jeff Tantsura; Jan Medved (jmedved); Dean Bogdanovic; Jamal Hadi Salim Cc: [email protected]; Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model +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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
