Subject: New model DRAFT

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 5 Jul 2005 19:55:49 -0400

I have completed an editing pass on the model document.
I have added aliases, properties, and events.
I have added an example to try to explain how some of this works.

Jamal has very helpfully posted the draft at:
     ftp://ftp.znyx.com/users/hadi/private/forces/

Note, this is the word document.  It has change tracking turned on, so you 
should easily be able to tell what I did.
Ellen will be working this document over when she gets back from vacation, 
and we will submit that to the I-D respository.

The XML Schema passes XMLSpy's validity test.  The two LFBs validate 
against that schema.
I believe the example is indented badly.  Sorry.  I can not get word to 
cooperate on it.

One note on the Schema.  I do not have the tools to usefully validate the 
Key / KeyRef declarations.  And while my tool uses them, I think it uses 
them wrong because I get mysterious errors.  If someone who understands Key 
/ KeyRef could look at them, I am happy to fix them up.

I am sure there are many other errors.
And probably places that need clarification even if they are not wrong.

Please, Please, Please read the draft.  Send comments.

Yours,
Joel M. Halpern

---

From: Robert Haas <[email-masked]>
Date: Fri, 15 Jul 2005 14:33:33 +0200

Joel,
Great work ! I tried to read the whole draft in one shot to detect 
discrepancies and so on. Here is a first list of specific comments.
Regards,
-Robert

[Editorial] Sec 3.1 FE Capability Model and State Model:
The FE capability and the FE state are both represented by two levels. 
The text says this only for the FE State model ?

[Technical] Sec 3.3.2 Configuring the LFB Topology
Note that LFB topology constraints are also expressed by the Packet 
Types on ports (output-input matching) and required metadata (an LFB may 
require certain metadata, hence an upstream LFB must produce it).

[Technical] Sec 4.7.4 Element to Define LFB Operational Attributes
“While the capabilities will frequently indicate this non-existence, CEs 
may attempt to reference non-existent or non-permitted attributes 
anyway. The FORCES protocol mechanisms should include appropriate error 
indicators for this case”.
This is still missing in the protocol. We need special Result-TLV codes 
for this.

[Technical] Sec 4.7.5 <capabilities> Element to Define LFB Capability 
Attributes

In the example (copied below), nothing except the synopsis relates 
limitBar to the bar attribute. I'd like to have sth so that the machine 
can figure out from the LFB what is the maximum size of some the LFB 
arrays (forwarding table, etc). So we would need sth comparable to the 
events semantics (i.e., greater, lower, etc), and a field that maps the 
capability to its element (if applicable).

<capability elementID="4">
<name>limitBar</name>
<synopsis>
Maximum value of the "bar" attribute.
</synopsis>
<typeRef>uint16</typeRef>
</capability>

[Editorial] Sec 4.7.6:
incomplete sentence end of 2nd paragraph “In a derived LFB (i.e. one 
with a <derivedFrom> element) the baseID must not.”

[Technical] 4.8 LFB Properties
This is still missing in the protocol. We need special Result-TLV codes 
to signal that the writing of a property element failed.

[Editorial] (check in the entire document)
typo OctetSting, or octetstring.

[Technical] Sec 5.5. FE Attributes and Capabilities
In the <attributes> of the FEObject (copied below), LFBTopology is the 
current topology of LFBs in the FE, but the synopsis says :the table of 
known Topologies" ?
If the FE has a list of allowed "fixed" working topologies, shouldn't 
this be a field in the <capabilities>, i.e., an array of arrays ?

<synopsis>Core LFB: FE Object</synopsis>
<version>1.0<version/>
<attributes>
<attribute access="read-write" elementID="1">
<name>LFBTopology</name>
<synopsis>the table of known Topologies</synopsis>
<array type="variable-size">
<typeRef>LFBLinkType</typeRef>
</array>
</attribute>

[Technical] Sec 7.7. Using the FE model in the ForCES Protocol
"Among the seven types of payload information the ForCES protocol 
carries between CEs and FEs, the FE model covers all of them except item 
1), which concerns the inter-FE topology. The FE model focuses on the 
LFB and LFB topology within a single FE. Since the information related 
to item 1) requires global knowledge about all of the FEs and their 
inter-connection with each other, this exchange is part of the ForCES 
base protocol instead of the FE model."

I think that as the FEObject has an array of FEConfiguredNeighborType, 
exchange (1) to dicsover the inter-FE topology consists simply of 
reading this LFB attribute. So I would not say that (1) is "part of the 
ForCES base protocol instead of the FE model." . Also check in Fig. 9.

[Technical] Sec 7.2.7.2 FE Capability Declarations
" FEs will have many types of limitations. Some of the limitations must 
be expressed to the CEs as part of the capability model. The CEs must be 
able to query these capabilities on a per-FE basis. Examples: Metadata 
passing capabilities of the FE. Understanding these capabilities will 
help the CE to evaluate the feasibility of LFB topologies, and hence to 
determine the availability of certain services."

I think that metadata is sth LFB-specific and does not belong to the FE 
capabilities. The FEObject does not have any attribute about this.

[Technical] 7.4 LFB Capability Declarations

"Also, the LFB class definitions will probably contain very few 
quantitative limits (e.g., size of tables), since these limits are 
typically imposed by the implementation. Therefore, quantitative 
limitations should always be expressed by capability arguments."

Although both capabilities now defined for the FEObject are optional, I 
expect that we will have LFB classes with capabilities that are 
mandatory to define: for instance, the maximum routing table size should 
be a capability that every vendor must specify.

[Technical] Sec 7.6.7.6 LFB Attribute Manipulation
"(Editor's note: It remains an open issue as to whether or not other 
methods are needed in addition to "get attribute" and "set attribute" 
(such as multi-attribute transactions). If the answer to that question 
is yes, it is not clear whether such methods should be supported by the 
FE model itself or the ForCES protocol.)"

Multi-attribute setting or getting is in fact allowed by the protocol. 
If the FE has a problem with it, it will return an error (for instance, 
two attributes that are set to mutually incompatible values)

[Technical] Sec 8.3 Capabilities
"The capability information for this LFB includes whether the underlying 
interface is operational". The example XML is:
<capabilities>
<capability elementID="31">
<name>OperationalState</name>
<synopsis>whther the port over all is operational</synopsis>
<typeRef>PortStatusValues</typeRef>
</capability>

I doubt that interface state should belong to the capabilities. It is an 
attribute, no ?

Joel M. Halpern wrote:

> Note, this is the word document. It has change tracking turned on, so 
> you should easily be able to tell what I did.
> Ellen will be working this document over when she gets back from 
> vacation, and we will submit that to the I-D respository.
>
> One note on the Schema. I do not have the tools to usefully validate 
> the Key / KeyRef declarations. And while my tool uses them, I think it 
> uses them wrong because I get mysterious errors. If someone who 
> understands Key / KeyRef could look at them, I am happy to fix them up.
>

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-44-724-8698  fax +41-44-724-8578  http://www.zurich.ibm.com/~rha