As with most modeling work, there are several ways to extend the base
models. Figuring out which one is right, and designing for
extensibility is important no matter what the language is.
So, for the RIB, clearly it starts with a base RIB entry definition with
the common stuff.
The challenge with extensions is whether there are a number of
orthogonal things we want, or a set of components that we want to be
able to use.
To pick the hardest case, lets suppose that we use a RIB table LFB which
uses a RIB datatype. If we can coordinate, the easiest thing is to
assign an ID in the RIB structure for each substructure as you add it.
One way or another, in order to have binary names for these, we have to
achieve that. The subclassing mechanism supports this easily.
For alternatives, we do have unions. But I think that is a more narrow
case and not as useful.
One can also define various components as freestanding LFB classes, and
include aliases to reference them. That is even more flexible, and
requires less coordination. But it is more opaque as a model.
To do this, would would define in the base RIB entry a table of
"extension points" which are aliases to an LFB class which inherits from
a base LFB extension LFB. You can then reference any instances of any
subclass of that. Arbitrarily flexible, but quite confusing.
Yours,
Joel
On 4/22/14, 11:19 AM, Jeffrey Haas wrote:
Joel,
On Tue, Apr 22, 2014 at 10:28:13AM -0400, Joel Halpern Direct wrote:
Since ForCES name space is per-lfb-class. So that the collision
problem is mostly in the naming of the lfb classes. (Some care is
needed in the naming of data types and such, but it is pretty easy
to do that in a colission avoiding fashion. The harder problem,
which applies equally to NetConf and ForCES, is to know when you can
reuse an existing definition and when you need your own.)
I'm still working my way through my FORCES reading. It would be very
helpful to see an example of this.
To offer an example from netconf that I commented upon at various WG
sessions, a RIB entry will tend to consist of things that are common across
implementations (prefix, nexthop[s], source protocol) and may be augmented
by either protocol-specific components (AS_PATH, communities for BGP; metric
for IGP) or vendor-specific ones (weight, administrative distance, etc.)
In YANG, this is mostly a matter of just decorating with additional XML
elements around the core objects. (I'm over-generalizing.)
How does one do this in FORCES?
Note that the protocol on the wire does not use the names at all,
but only the assigned identifiers. Which are registered precisely
to avoid collision.
One of my lesser concerns here is that code point registries provide another
pivot for coordinating development work, in or out of IETF. Arguably, XML
token names have the same sort of issue to some extent, but tend not to be
"last code point +1".
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
