I actually expect that YANG can be extended to do what is needed. I
also expect that ForCES protocol can be extended to do what is needed on
the protocol side.
But that is not the same as saying that either item "as is" meets the
needs as stated.
It would seem appropriate to at least describe what extensions will be
needed to YANG before we decide to say "yes, we will use YANG and we
will extend it to address the needs."
On the ForCES side, I believe Jamal did include that information in his
presentation. Is there a similar list for YANG that I have misplaced?
Yours,
Joel
On 4/19/14, 3:02 PM, Andy Bierman wrote:
On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern <[email protected]
<mailto:[email protected]>> wrote:
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.
I assume you mean sec. 6.4.5?
I did not find anything in there that YANG does not already support or
could not
support with a YANG extension statement. Since I2RS can define its own
YANG extensions, YANG is ready today to meet all the requirements.
Can you be more specific about the stretch items?
Yours,
Joel
Andy
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]>
<mailto:[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
