Sorry for the top post, but I wanted to inject that for the record,
Brocade is in favor of using RestConf/Yang (or variations of those) for I2RS.
We have no interest in using FORCES as the basis for this.
--Tom
On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim <[email protected]>
wrote:
> On Fri, Apr 18, 2014 at 9: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.
>>
>
> Thanks for being sincere Dean.
> First, I will say I empathize with your view above (I understand such
> a view is motivation
> for many unfortunately often disguised as technical opinion). While i
> empathize, I would like
> to point that we need to have these discussions which are technical
> otherwise there is
> no point in having a standard.
> In any case I get where you are coming from.
>
>> 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.
>
> Maybe we'll bring up the topics sequentially as the thread proceeds -
> I'll start with
> 1 or 2 of what i think are requirements against protocol/model so we
> dont have to
> respond to long emails. If you have issues with ForCES please bring
> them up as well
> and we can discuss (I brought up a few in my presentation).
>
> One of the issues was throughput and latency.
> You stated in London that you want to be able to do a large amount of
> updates/sec.
> Other than you - I cant get anyone else to say this is a requirement.
> I do believe it is.
> It will be useful for example to come up with some hand waving numbers against
> some agreed-to info model (eg the rib) and see how this requirement is
> met by the
> different protocols.
>
> As for the model, I'd like to quote from the minutes what Tom Petch
> (who i consider to
> be a sage in this space):
> "If I was writing an info model I'd use YANG every time. But if I was
> writing a data
> model I'd go for ForCES."
> And this is rooted in the nature of Yang being intended for Config.
>
> There is also the issue of i2rs ability to describe instances which is
> lacking in Yang;
> but maybe leave that out to a different email..
>
> cheers,
> jamal
>
>> 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.
>>
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
