Joel, Please see inline.
On 4/18/14, 5:19 PM, "Joel M. Halpern" <[email protected]> wrote: >Actually Jan, you made a leap there I did not follow. >You assert that "the controller programmatic API iis a superset of a >device programmatic API.” >This does not seem to follow. On the one hand, I would hope that a >controller is exposing abstractions, which are unrelated to the device >API. Yes. I may have stated slightly differently - I called these abstractions “controller’s own services”. >And on the other hand, there may well be many things the device API can >do that the controller does not >need. Again, we are in agreement, with one possible twist: an application may want to talk to the device not directly, but through the controller (I think a while back we all agreed that this was a valid use case). I called it “controller proxying the device”. The point I was trying to make that Yang, as the IDL in the controller, is suitable both for defining controller’s own service APIs and for proxying of device APIs. I spoke from experience: we defined a bunch of controller services and proxied a bunch of device APIs (netconf itself, PCEP, OpenFlow) with yang models. It worked really well for all APIs that we managed to throw at it :-). To conclude: if yang works well in the controller environment, which is a more complex API environment than a device, it will surely work well at the device level. That’s all that I wanted to say. >The I2RS charter makes it clear that I2RS is not intended to replace >other configuration mechanisms. > >And the basic premise of I2RS is that there are requirements for the >work that were not addressed properly by the existing configuration >protocols. Otherwise the WG would not even need to discuss protocol >modifications. So the fact that NetConf / YANG works for device >configuration does not seem to be evidence that it works for what I2RS >wants to do. > >I would actually guess that it is reasonably close, Again, we seem to be in agreement - I also said that the majority of use cases that I can think of can be covered with Netconf/Restconf/Yang today. I did not say we can cover everything. But, through the OpenDaylight experience I found that Netconf/Yang could cover a lot more than what I originally anticipated (which was actually quite surprising to me). >and I will live with whatever conclusion the WG reaches about protocol >and modeling. But I would not claim that the existing deployment is >relevant evidence for this problem space. I actually think it is - what’s wrong with working code? ;-) > >Yours, >Joel Thanks, Jan > >On 4/18/14, 7:59 PM, Jan Medved (jmedved) 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. >> >>> >>>> 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
