There are a number of modeling and protocol expectations (I think they
can be reasonable called requirements, and I think they have been agreed
by the working group) in the architecture draft. Some of them are a
stretch for YANG. Some of them are a stretch for ForCES.
Yours,
Joel
On 4/19/14, 1:46 PM, Andy Bierman wrote:
Hi,
On Sat, Apr 19, 2014 at 8:22 AM, Russ White <[email protected]
<mailto:[email protected]>> wrote:
> 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.
Precisely. Otherwise, we could have just looked at the problem, and
said,
"let's use YANG." But I think we're starting to confuse the problem set
because we started by trying to boil the ocean. Once you actually get to
town, it's hard to keep in focus that you're just there for a new
pitchfork
handle -- that game of checkers over there on the porch of the hotel
looks
so interesting, and the hardware store has so much other stuff than just
pitchfork handles, after all.
So, given we are _supposed_ to be focused on the RIB interface, and not
protocol, configuration, device, etc., etc., what specific points
have the
use cases brought out that either NETCONF/YANG or FORCES not
fulfill? One of
the primary points was timing -- are these other systems fast enough?
>From my perspective, these two systems don't fulfill the I2RS
mandate on the
RIB side for various reasons:
- I'm not convinced on the speed side. YANG feels a bit heavy weigh
for what
we want here. The flexibility is there, but so is the cost of that
flexibility.
Can you explain how an off-line representation of the data model can be
fast or slow?
You mean the YANG compiler takes too long to process a YANG file?
You mean the unspecified I2RS protocol will be too slow on the wire if
it uses XML or JSON encoding of YANG data structures?
- I'm not convinced YANG has handled the atomicity issues in a way that
makes sense for the application environment we have in mind.
RESTCONF seems
to go that direction, but I'm not certain it's a complete solution (?).
YANG is a data modeling language.
RESTCONF is a protocol.
Atomicity is a property of the protocol.
Which YANG statements prevent this from being accomplished in the TBD
I2RS protocol?
So, IMHO, I think we need to either consider FORCES, or "something
new." But
we're going to have a hard time determining if this is true if we
can't make
a solid requirements list. For me, these are:
- Atomic operations at the RIB level
- Speed that's comparable to a local routing process installing
routes in
the RIB
- An immediate feedback system within the RESTful mold that tells the
installing process what happened, and why, with the route it just
tried to
install in the RIB
So, it seems to me that we need to return to the use cases -- there
are two
in the charter. If we want to discuss adding others, that's fine, but we
need to gain some focus, and stop trying to boil the ocean, if we
want to
make any progress.
It seems to me this WG needs to start asking the right questions about the
data modeling language requirements. E.g.:
- What are the data types needed? Is this a static set of will it
ever change?
- What are the high level data modeling constructs needed?
- Are user defined types needed?
- Are re-usable data definitions needed?
- Does the data model need to be modular? How does it grow over time?
- Can vendors add data definitions that extend the standard definitions?
- How are new definitions added in a way that does not break existing
clients?
- How is mandatory to implement vs. optional to implement
functionality handled?
- How is mandatory to use vs. optional to use functionality handled?
You are asking about protocol requirements, not data modeling.
IMO it would be near-sighted and extremely impractical to choose
a language that only supported description on RIB info. I fail to see what
is so special about RIB info that would warrant its own DML.
:-)
Russ
Andy
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
