Thank you. I had misread your note as talking about the (reasonably wide) use of YANG for configuring routers. I will agree that the use of YANG by ODL is evidence of the versatility of the tool.
Yours, Joel On 4/18/14, 9:25 PM, Jan Medved (jmedved) wrote: > 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
