> On Apr 18, 2014, at 6:59 PM, "Jan Medved (jmedved)" <[email protected]> wrote: > > > >> 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.
Spot on. Tom > >> >>> 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
