Andy:
Catching up. A few questions:
1) Why do you think that only the RIB matters in the long run (Short
run = RIB + BGP)
2) Your modeling questions are important .. so let me ask a
meta-question and then go a level deeper.
Why does netmod never really publish an informational model?
Here's a bunch of answers/question to you great modeling questino
- What are the data types needed? Is this a static set of will it ever
change?
a) Yes. Right now no Data types in
This static set is likely to continually expand if it is used for I2RS, and
have vendor specific
- What are the high level data modeling constructs needed?
[Sue] Yes. But we will talk a lot about what is high-level data model
constructs?
Do you consider next-hop as defined in the RIB a high-level?
- Are user defined types needed?
[Sue" If you mean, will vendors or specific end users need it? I do not see
how we can go without it.
- 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 definition?
- How are new definitions added in a way that does not break existing
clients?
[Sue]: Answer yes to all. Re-usable, modular, growing, vendor
extensible, user-defined.
Do not plan to break if add new,
- How is mandatory to implement vs. optional to implement functionality
handled?
- How is mandatory to use vs. optional to use functionality handled?
[Sue]: Need the profiling variables that Yang is using
[Note: Forces has an equivalent to all of this]
Sue
From: i2rs [mailto:[email protected]] On Behalf Of Andy Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: Russ White
Cc: [email protected]; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Jan
Medved (jmedved); Joel M. Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and model
Hi,
On Sat, Apr 19, 2014 at 8:22 AM, Russ White <[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
