+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
