On 4/18/14, 2:12 PM, "Jamal Hadi Salim" <[email protected]> wrote:
>On Fri, Apr 18, 2014 at 4:59 PM, Jan Medved (jmedved) <[email protected]> >wrote: >> 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. >> > >This has nothing to do with meeting requirements for I2RS. Sure it does. I2RS is ultimately about a set of programmatic APIs to the routing system. The controller programmatic API is a superset of a device programmatic API, since the controller must be able to proxy the device and provide programmatic APIs to its own services. Now, if an IDL has proven to be useful and/or meet the requirements in a environment which is a superset of the target environment, then by definition it will be useful and/or meet the requirements in the target environment. > >> 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. > >Again - I am not hearing requirements against I2RS. >Have you implemented I2RS with netconf/restconf/yang? Nobody has implemented I2RS, because the protocol has not been defined yet. But I was deeply involved with Netconf/Restconf/Yang implementations on both IOS-XR and on OpenDaylight. In any case, Netconf/Restconf/Yang gives us today maybe 80-90% of what we need from I2RS for our use cases. > >> 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). >> > >I dont think this sounds rational at all. HTTP has a bigger ecosystem >than you. >Why not build around that and then refactor as needed? Bingo! How about Restconf with JSON encoding? ;-) >Why is it so hard to get requirements around here? What is the point >to a standard again? The I2RS requirements have been gathered, and Netconf and Yang have been analyzed against the requirements by Andy and Dean at the last IETF. I find no fault in their analysis, so IMHO Netconf / Yang (with possibly small modifications) will meet the technical requirements of I2RS. What I and others have been trying to say is that the rest of the world is moving towards Netconf/Restconf/Yang. Therefore, (besides it being a good-enough technical choice), it is the pragmatic choice. If I2RS wants to be relevant to operators, vendors, and the open source community, it needs to go where all these entities want to be. > >cheers, >Jamal Thanks, Jan > >> 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
