It would be good to have an empirical performance analysis of Netconf vs FORCES; this would substantiate performance advantages, if any, of either protocol. The following reference provides a reasonable empirical performance analysis of Netconf vs SNMP - http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf.
Thanks, Ramki -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern Sent: Monday, April 21, 2014 8:48 PM To: Andy Bierman; Jamal Hadi Salim Cc: Russ White; [email protected]; Jan Medved (jmedved); Dean Bogdanovic; Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
