Sorry Andy - trying to catchup with the threads (and busy elsewhere at
the moment)
so fast forwarding to this email. I will try to come back later and answer each
of your questions probably in a separate email
To provide an example to what Joel said:
You can augment/extend in two ways.
a) Take an existing LFB - keep the name change the class version.
Take an existing data structure within that class and extend it.
Example (straight out of our regression tests, simplified for clarity):
struct foobartype {
id 1, foo, uint32;
id 2, bar, uint32;
}
class MyUpgrade id 667
{
version 1.0
components {
id 1, cbogtabl, array of foobartype;
}
events {
id 1, CBogChanged ... reports cbogtable changes with row
}
}
And later you decide you want to add some new field to foobartype.
struct foobartype {
id 1, foo, uint32;
id 2, bar, uint32;
id 3, goo, uint32;
}
class MyUpgrade id 667
{
version 1.1
components {
id 1, cbogtable, array of foobartype;
}
events {
id 1, CBogChanged ... reports table changes with new foobartype
}
}
In field upgrades, typically i see that the control piece is first upgraded.
The data path follows next incrementally on different nodes.
The datapath ignores and logs what it doesnt understand. i.e in such a case,
an app sends cbogtable row with goo to version 1 datapath.
On inheritance, here's an example of what a linux port would look like:
struct portinfo {
id 1, name, string[16]
id 2, ifindex, uint32
..
..
id 23, ethinfo, struct ethparams
}
class Port, id 6113
{
version 1.0
components {
id 1, ports, array of portinfo;
}
events {
... link, port creation etc ..
}
capabilities {
.........
}
}
So if i wanted to define a tunnel device, then i take that
portinfo struct and derive from it then i create a new class.
As an example for tuntap port on Linux:
struct tunport {
<derivedFrom>PortInfo</derivedFrom>
id 24,tunflags, uint32, optional
id 25, userid, uint32, optional
id 26, groupid, uint32, optiona
}
class tuntap, id 6119
{
version 1.0
<derivedFrom>Port</derivedFrom>
components {
id 1, ports, array of tunport;
}
events {
... link, port creation etc ..
}
capabilities {
.........
}
}
The XML is reduced greatly.
Not sure if i answered the specific question
I will respond to your other questions later..
cheers,
jamal
On Mon, Apr 21, 2014 at 11:48 PM, Joel M. Halpern <[email protected]> wrote:
> As a minor point, I consider the embedding of file management and business
> logic into the core of NetConf was probably a mistake.
> ForCES does have version numbers on classes, so if you change an LFB class
> definition, you increase the revision.
> It also has inheritance, which provides an effective way to define a
> coherent extension of a class.
> And it explicitly includes indications of which items are required. As well
> as providing mechanisms for a controller to determine on a fine grained
> basis what an FE actually supports. So we do not have to guess what the
> right groupings are for unknown users down the road.
>
> Yours,
> Joel
>
> On 4/21/14, 6:21 PM, Andy Bierman wrote:
>>
>> Hi,
>>
>> Forgot life-cycle issues....
>> There does not appear to be any notion of a module revision in ForCES.
>> There does not seem to be any way to identify a particular definition
>> as either current, deprecated, or obsolete.
>>
>> Is a library used with the <load> element ever allowed to change?
>> If so, how are new revisions identified?
>>
>> Is there any text explaining how these modules are allowed to change
>> over time?
>> Was this considered by the WG?
>>
>> Andy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi,
>>
>>
>> On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman
>> <[email protected] <mailto:[email protected]>> wrote:
>> >
>> > I think Jan and others have explained why they think they can
>> leverage
>> > the NC/RC/YANG technology to implement I2RS. There are tool
>> > and data model management requirements in addition to the
>> protocol
>> > in order to have a workable solution.
>> >
>> > Unless the RIB data is one monolithic blob implemented without
>> > variation on every router, then issues such as modularity,
>> conformance
>> > model, data lifecycle, distributed naming authority, data
>> augmentation,
>> > and language extensibility are going to matter.
>> >
>>
>> So lets put all that in a requirement list somewhere and work
>> around a gap
>> analysis.
>>
>>
>> So how does ForCES support these things?
>> Where is the language specification in RFC 5812?
>> Section 4 describes LFB classes, which appear to represent the only
>> supported data
>> for the protocol. Is the entire normative language specification
>> contained in the XSD in sec. 4.9?
>>
>> What happens if multiple <load> elements pull in definitions with the
>> same local name? The examples do not show any use of prefixes
>> and the <load> element has no prefix mapping.
>>
>> <load library="a_library"/>
>> <load library="another_library" location="another_lib.xml"/>
>> <load library="yetanother_library"
>> location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/>
>>
>>
>> There does not appear to be any conformance information like what is
>> mandatory or conditional on a user-defined feature. How are logical
>> groups
>> of conditional objects defined and advertised in the protocol?
>> (e.g., YANG features)
>>
>> Are there examples of the augmentation described in sec. 4.5.7?
>> There does not appear to be any way for 1 module to add elements to
>> another
>> <dataTypeDef> without controlling the naming for all modules.
>>
>> How does a vendor implement the unique naming requirements in ForCES
>> without controlling the names of all possible ForCES files? Are
>> they supposed to
>> rewrite modules when a naming collision occurs because modules X and
>> Y are being loaded
>> into module Z, which causes a new naming collision that did not
>> occur before?
>>
>> YANG supports groupings that can be refined in each use/expansion.
>> How are complex <dataTypeDef> statements reused and refined?
>> Where are examples of that in the RFC?
>>
>>
>>
>> How would I2RS use <frameDefs>?
>>
>> <frameDefs>
>> <frameDef>
>> <name>ipv4</name>
>> <synopsis>IPv4 packet</synopsis>
>> <description>
>> This frame type refers to an IPv4 packet.
>> </description>
>> </frameDef>
>> <frameDef>
>> <name>ipv6</name>
>> <synopsis>IPv6 packet</synopsis>
>> <description>
>> This frame type refers to an IPv6 packet.
>> </description>
>> </frameDef>
>> ...
>> </frameDefs>
>>
>>
>> Is this like a YANG identity statement, except this causes naming
>> collisions,
>> so it is more like a specialized distributed enumeration type?
>>
>>
>> To compare readability, here are the same type definitions in ForCES
>> and YANG:
>>
>> ForCES: (RFC 5812, pg. 80)
>>
>> <dataTypeDef>
>> <name>accessPermissionValues</name>
>> <synopsis>
>> The possible values of component access
>> permission
>> </synopsis>
>> <atomic>
>> <baseType>uchar</baseType>
>> <specialValues>
>> <specialValue value="0">
>> <name>None</name>
>> <synopsis>Access is prohibited</synopsis>
>> </specialValue>
>> <specialValue value="1">
>> <name> Read-Only </name>
>> <synopsis>
>> Access to the component is read only
>> </synopsis>
>> </specialValue>
>> <specialValue value="2">
>> <name>Write-Only</name>
>> <synopsis>
>> The component MAY be written, but not read
>> </synopsis>
>> </specialValue>
>> <specialValue value="3">
>> <name>Read-Write</name>
>> <synopsis>
>> The component MAY be read or written
>> </synopsis>
>> </specialValue>
>> </specialValues>
>> </atomic>
>> </dataTypeDef>
>>
>>
>> YANG:
>>
>>
>> typedef accessPermissionValues {
>>
>> description
>>
>> "The possible values of component access permission";
>>
>> type enumeration {
>>
>> enum None {
>>
>> value 0;
>>
>> description "Access is prohibited";
>>
>> }
>>
>> enum Read-Only {
>>
>> value 1;
>>
>>
>> description "Access to the component is read only";
>>
>>
>> }
>>
>> enum Write-Only {
>>
>>
>> value 2;
>>
>> description "The component MAY be written, but not
>> read";
>>
>>
>> }
>>
>> enum Read-Write {
>>
>> value 3;
>>
>>
>> description "The component MAY be read or written";
>>
>>
>> }
>>
>> }
>>
>>
>>
>> }
>>
>>
>>
>>
>>
>>
>> How are new protocol operations defined? Are they part of the
>> language.
>>
>>
>> How are language extensions done? This does not appear to be
>> supported.
>>
>> How are existence constraints between objects expressed? (e.g.,
>> must/when/unique)
>>
>> How does a vendor add arbitrary data to notification events?
>> Can event definitions be augmented?
>> If so, how is this done so nodes can be conditional? (e.g.,
>> if-feature, when)
>>
>> The <eventCondition> element is one of many that seems very ForCES
>> specific.
>> How are new events added?
>>
>> I don't see an event definition for the "Goof1changed" example:
>>
>>
>> </xsd:complexType>
>> <!-- the substitution group for the event conditions -->
>> <xsd:element name="eventCondition" abstract="true"/>
>> <xsd:element name="eventCreated"
>> substitutionGroup="eventCondition"/>
>> <xsd:element name="eventDeleted"
>> substitutionGroup="eventCondition"/>
>> <xsd:element name="eventChanged"
>> substitutionGroup="eventCondition"/>
>> <xsd:element name="eventGreaterThan"
>> substitutionGroup="eventCondition"/>
>> <xsd:element name="eventLessThan"
>> substitutionGroup="eventCondition"/>
>> <xsd:complexType name="eventPathType">
>> <xsd:sequence>
>> <xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
>> </xsd:sequence>
>> </xsd:complexType>
>> <!-- the substitution group for the event path parts -->
>> <xsd:element name="eventPathPart" type="xsd:string"
>> abstract="true"/>
>> <xsd:element name="eventField" type="xsd:string"
>> substitutionGroup="eventPathPart"/>
>> <xsd:element name="eventSubscript" type="xsd:string"
>> substitutionGroup="eventPathPart"/>
>> <xsd:complexType name="eventReportsType">
>> <xsd:sequence>
>> <xsd:element name="eventReport" type="eventPathType"
>> maxOccurs="unbounded"/>
>> </xsd:sequence>
>> </xsd:complexType>
>>
>>
>> <event eventID="8">
>> <name>Goof1changed</name>
>> <synopsis>
>> An example event for a complex structure
>> </synopsis>
>> <eventTarget>
>> <!-- target is goo.f1 -->
>> <eventField>goo</eventField>
>> <eventField>f1</eventField>
>> </eventTarget>
>> <eventChanged/>
>> <eventReports>
>> <!-- report the new state of goo.f1 -->
>> <eventReport>
>> <eventField>goo</eventField>
>> <eventField>f1</eventField>
>> </eventReport>
>> </eventReports>
>> </event>
>>
>>
>> I am still confused about the <metadataDefs> general applicability.
>> E.g., how are <inputPorts>, <outputPorts> used in I2RS?
>>
>> cheers,
>> jamal
>>
>>
>>
>> Andy
>>
>>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
