On Tue, Apr 22, 2014 at 6:59 AM, Jamal Hadi Salim <[email protected]> wrote:
> 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):
>
>
I will try to relate this back to the RFC.
The real syntax is XML and does not look anything like your examples.
(If XML was that readable, perhaps you would use the real syntax).
I do not understand the conformance model. Does the server claim
conformance to a set of { class, version } tuples? How does the
client know what versions to expect?
ForCES is not really extensible if multiple vendors are defining data
because
there is 1 giant flat namespace so all data naming has to globally
coordinated, or naming collisions can occur:
mod1:
container foo { }
mod2:
augment /mod1:foo {
leaf X { type string }
}
mod3:
augment /mod1:foo {
leaf X { type string }
}
This is not an error in YANG.
It can't be because mod2 and mod3 are from 2 different vendors
and they both want to augment the standard module (mod1).
Clients that use /mod1:foo/mod2:X do not collide with clients
that are using /mod1:foo/mod3:X.
Without namespaces, even vendor modules would need to go
through a central naming authority like IANA.
Andy
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
