+1 We have been saying this for a quite sometime :-) pals
On 4/18/14 3:11 PM, "Geoffrey Mattson" <[email protected]> wrote: >+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
