On Fri, Apr 18, 2014 at 9:02 AM, Jamal Hadi Salim <[email protected]> wrote:
> I dont think a post like this is useful.
> State your reasons please - just cheering on is not helpful.
>
>
It is as useful as +1, which IMO is useful.
Availability of tools is important to developers who intend to implement
I2RS.
I think there are also some technical reasons to use YANG:
- YANG is protocol and encoding independent. It can be mapped to a
protocol
fairly easily. It supports XML now. A standards effort to support JSON
encoding
has been started in the NETMOD WG. A proposal to support EXI exists,
and
support for CBOR is possible.
- YANG supports definition of protocol operations, data nodes, and
notification events.
Data nodes are either configuration or non-configuration. XPath is used
to define
validation rules such as 'must' and 'when'. There rules apply
differently to
each context (operation, config data, non-config data, notification).
- The local config is related to operational state, especially since
operational values may
include configured values. YANG is already being used for configuration.
Using consistent data naming is important. A YANG instance-identifier is
an
absolute-path (restricted XPath) expression.
- YANG supports external and conditional augmentation of any data model.
Each YANG module defines its own namespace. A module namespace can
be sub-divided with sub-modules. All nodes are identified with QNames,
using the YANG module or namespace as the extended name. This supports
non-centralized naming authority (i.e., vendor A and vendor B can both
augment
the same standard data node without any possibility of naming
collisions.)
- YANG "features" allow optional functionality to be defined in a
data-model specific manner.
Conformance advertisement information is standardized so clients know
what options
are supported by each server implementation.
- YANG "extensions" allow new language statements to be added to the
language,
These external statements must be parsed by every YANG compiler, even if
the compiler does not understand the extension. This allows YANG to be
easily
adapted for new applications, without the need to revise the language.
jamal
>
Andy
>
> On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau <[email protected]>
> wrote:
> >
> > 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
> >>
> >
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
