Subject: Re: FE Capabilities and attributes section of the model draft

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 Jan 2004 18:56:16 -0500

Let me restate the questions, and try to provide the answers that motivated
me when I wrote the text:

I used Oxygen to validate the schema, and to validate the sample against
the schema.  Cut and paste errors may have crept in since.  (Oxygen is
commercial, with a 30 day free trial.  There are other good tools, such as
XMLspy.)

The schema should have more documentation.  Probably as annotations.  I did
not think that the full descriptive text went in the schema (at least every
other example I have seen has less information in the schema than in the
document.)  Since I was not sure where to draw the line, I figured that
schema internal documentation could wait.

I made everything optional for now for two reasons:
1) I had to make a call.  Since there was some resistance to a lot of these
things, I thought that optionality with defaults was sensible.  I have no
objection if folks think that all the information should be mandatory.
2) By making it optional I could write a short example which would match
the schema.  (Not a very good reason, but it helped me out.)

The reason for the "CanOccurs" approach is that we can not predefine the
traffic types, nor the implementation types.  Within the set of FEs with
adjustable topology, some will be able to support placing any LFB in any
place in the topology.  Others will have restrictions on which elements can
occur where.  While not all restrictions can be expressed this way (in
general, there are going to be non-expressable capability
restrictions.  The FE will give errors if the CE tries to order it to do
something it can not) nonetheless, I wanted a flexible approach.  And
knowing whether the traffic is v4 or v6t only helps choose a few of the
branches / placements.  Getting into specifying the services the FE
delivers, and the order of LFBs that the CE / FE use to deliver those
services is clearly not the job of the FE Model (nor even the ForCES
protocol specification, except as examples.)

Section 1.4.3.4 is about inter-FE topology.  NeighborID is some sort of ID
for the neighboring FE.  Whether that neighboring FE is in the same NE, in
a different NE, or actually some router probably depends upon how you
expect the FE to know about its neighbors.  I expect that the ID will be an
IP (v4 or v6) address.  But I felt that it was a little premature to
specify that.  [I tried to give this information fair treatment.  I
apologize if my biases caused it to be under-specified.]

Thanks very much for taking a look at this.
More comments please.
Joel

PS: I saw Alex's request for a diagram.  If the CanOccurs stuff is still
confusing, I will have to find some tools and write a much longer
explanation, with diagrams.  My concern is that the next step up in
explanation gets quite verbose.

At 02:16 PM 1/19/2004 -0800, Putzolu, David wrote:
>I just reviewed the document and had the following comments.
>
>Cheers,
>David
>
>General: Is there a good cross-platform tool for
>browsing and validating the schema that anyone
>can recommend?
>
>General: I noticed a few spots where comments where
>included, that is, <!-- stuff like this -->.  Is
>there some sort of annotation tag that can be used
>to include comments on each attribute?  It would
>be nice if the schema could be self-describing and
>browsable with some nice graphical tool.
>
>Line 5: The <xsd:annotation> tag here appears to not
>   be matched anywhere, causing the document to be
>   invalid.
>
>FEDocument attribute: Why is all capabilities and
>attributes optional? Seems like mandating that providing
>the information should be mandatory.
>
>1.4.1 FECapabilities should all be mandatory. E.g.
>every FE should be able to indicate whether it can
>support modifiable topology or not. Actually, all
>the attributes I looked at should be mandatory.
>Having defaults is good, but requiring that the FE
>explicitly say what capabilities it has reduces the
>chance of hard-to-diagnose bugs due to an FE implementor
>assuming the default was A when in fact it was NotA,
>where the implementor didn't express the attribute due
>to assuming the (unexpressed) default matches their
>implementation.
>
>1.4.2.2.4/5 The CanOccur approach says that LFBs
>have particular other LFBs they can follow/precede.
>Why not instead define LFB connectivity according to
>the type of traffic on a LFBLink?  I.e. perhaps an IPv6
>forwarder LFB would only be able to accept input
>from other LFBs that output IPv6 traffic.   Perhaps
>consider allowing both types of constraints to be
>expressed.
>
>1.4.3.4.1 What Neighbor does the NeighborID refer
>to? Neighboring CE (within a NE), Neighboring NE (within
>a network), neighboring LFB (within an FE), or
>neighboring FE (within an NE)?
>
>(end)

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 31 Jan 2004 17:20:32 -0500

> commercial, with a 30 day free trial.  There are other good tools, such as

Just downloaded Oxygen and it doesnt validate for me either.
I think it would be nice to have a validated XML in the text.

Also nice to see the breakdowns of sections approach instead of one big
doc.

Comments:
- Something bothering me is the FEattribute piece however many times i
stared at it. So i figured i would start from the ground up.
Is it fair to say that "capabilities constitute attributes".
That once you give these attributes values or parametrize them as the
FEAttributes branch does, then now you are talking about state - which
may be more closer to implementation details than to a model.
I am not saying i have an answer on what would be a good way to resolve
this. I think the FECapabilities piece is  well done. I just dont know
what to make of the FEattributes - they dont taste too good. For example
the FEAttributesType seems to be a scatter of a few things. Vendor,
Model (maybe serial number and you could go further to say slotid etc)
are more like Product Data (as in PCI VPD) whereas FEstatus seems to
be an instanteous state of the FE and LFB* seem to be related
instantiated LFB policies (or topologies). Its almost like FEAttributes
is meant to be FERunningState.

- The FE should probably have a name and provisioned numeric ID.

- FEConfiguredNeighborType is also one of those things that doesnt
seem to really fit in that picture. Some of the pieces seem to fit into
three different possible LFBs: Port, Neighbor and i dont know if you
want to call IP address provisioning as an LFB. Which seems to me like
we need at least some base LFBs to always be in the FE (i.e MUST) to
satisfy the basic model. So maybe we should head that way with the
model.

Other comments:

1. FE Attributes and Capabilities
"A ForCES forwarding element handles traffic on behalf of
a ForCES control element.  While the standards will
describe the protocol and mechanisms for this control,
different implementations and different instances will
have different capabilities"

What is the last "instances" refering to?

1.4.2

"LFBsSupported, WriteableAttributes and ReadableAttributes."
 dont exist in the schema. I think you meant SupportedLFBs
and SupportedAttributes.

1.4.2.1
- "LFBs supported clause" probably intended to say SupportedLFBs
- Also would it not be OK to use CanOccurBefore and CanOccurAfter
even for static topolgies as a way to capture the static topology?

1.4.2.2. SupportedLFBs and SupportedLFB

I think each LFB with a name will end up getting some numeric ID
probably issued by IANA. so a LFBId would be a good fit here.

1.4.2.5
- CanOccurBefore and CanOccurAfter: I think it would be good to state
the "any" or wildcard behavior as well - maybe when these attributes
are left out.

1.4.2.2.6. LFBClassCapabilities
- What is this for? Wouldnt each LFB have its own config which is
outside the scope of the model?

1.5 Sample FE Attribute Document

- s/LFBInstance/LFBInstance

(see, i read the whole thing if i can catch the above typo ;->)

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 31 Jan 2004 18:11:25 -0500

Thanks for taking the time to read this throughly and provide some useful
comments.

On the validation issue, we will need to work out procedures so that we
verify that the pieces in the document pass validation.

I will try to respond to your comments in line.

Joel

>is meant to be FERunningState.

The FE Attributes are certainly related to the FE state.  They are intended
to model the state aspects of the FE as a whole that the CE will need
cognizance of.  The examples I included are pretty weak, but we assume that
there will be some useful attributes.

>- The FE should probably have a name and provisioned numeric ID.

The FE presumably has / needs an identity.  However, whether it needs a
name, a numeric ID within the protocol, or merely an IP address is yet to
be determined.  If it is internal to the protocol, then it should be
reflected in the model.

>satisfy the basic model. So maybe we should head that way with the

I would be happy to leave out FE Configured Neighbors entirely.  However,
the working group consensus is that it is FE level information that the
protocol needs to carry.  If the protocol will carry it, the model should
describe it.

>What is the last "instances" refering to?

What I was trying to say is that not only will differing designs of ForCES
boxes have different capabilities, but sometimes within a design different
specific boxes may have different capabilities (different customers might
plug in more or less memory, allowing more or fewer LFBs in some designs.)

There are a couple of cases where the text did not catch up with some last
minute name changes.  Thanks for noticing them, and we will fix them.

>even for static topolgies as a way to capture the static topology?

You could use CanOccurBefore and CanOccurAfter to represent the topology
for static cases.  But since that does not represent the precise topology,
it seems better to set the "static topology" flag, and then use the
attributes which describe the current topology to accurately describe the
actual topology.  (After all, one could have a situation where there well
flexible instance connections but fixed type sequences.  That would still
be a dynamic topology, even if limited in the changes that the CE can make
to it.)

>probably issued by IANA. so a LFBId would be a good fit here.

You are probably right.  But I wanted to wait until we had made protocol
progress.  After all, if we were to switch to XML on the wire we would
probably use names instead of numbers.

>the "any" or wildcard behavior as well - maybe when these attributes

I thought I had specified the wildcard behavior.  I will make sure it is
in, as it is an important case.

>outside the scope of the model?

There are capabilities limitations that apply to an LFB Class even before
there are any instances of the class.  For example, the LFB Class may
define a port group.  The maximum number of ports allowed in that port
group is an implementation specific LFB Class level capability.  To phrase
this differently, there are capability questions about an LFB Class that
the CE may want / need to ask before it chooses to instantiate / examine
any instances of that class in the FE.  So there needs to be a table with
an entry per LFB Class holding those pieces of capability information.
This is something that caused us some confusion, and probably needs better
explanatory text.  I hope it will be easier to see once we have some LFB
Library elements to look at.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 31 Jan 2004 21:02:16 -0500

On Sat, 2004-01-31 at 18:11, Joel M. Halpern wrote:

> cognizance of.

Fine - its one of those greyish things.
FEAttributesType could be abstracted further into three categories:
- FEProductData = { vendor, model}
- LFBpolicyData = { LFBInstances, LFBTopology}
- FERunningState = { FEStatus, FEConfiguredNeighbor }

I dont think youll have to change SupportedAttributes if you rearranged
things.

> The examples I included are pretty weak, but we assume that

The example is OK i found. There could be more.

> be determined.  If it is internal to the protocol, then it should be

The name or ID i am refering to are for more for management purposes;
Maybe its an implementation specific, so i will wait.
I am not sure the model should really reflect (or dictate)
the protocol.

> protocol needs to carry.  If the protocol will carry it, the model should

I see the value in having the detail but not sure thats where it fits
from an abstraction level.
Perhaps the Port and Neighbor information should be assumed to be very
basic that they need to be in the model. The problem is that detail is
redundant or seems to assume existence of knowledge elsewhere
(example NeighborInterface which assumes a Port LFB).
Do you foresee an FE with no port and Neighbordiscovery LFB?

> actual topology.

By "current topology" above, do you mean whats described in LFBInstances
and LFBTopology i.e "currently configured" topology policy?

> (After all, one could have a situation where there well

Heres an example of hardware i am aware of:
LFBA->LFBB->LFBC->LFBD being valid as well as ability to remove
one or both of LFBB and LFBC from a topolgy instance with no other
sequences being valid. This is semi static. Is this what you are
refering to above?

> probably use names instead of numbers.

That sounds reasonable, but again note that danger of tying the model to
the protocol - dont make any assumptions about what representation is
useful. Binary encoding is useful to avoid latencies.
I think it is OK to have both binary and XML but the model shouldnt
assume one or the other - and if you end up predicting wrong, it wouldnt
harm to waste another 32 bit (since you are gracious to waste more with
XML;->). Whether its a name or ID or both someone is going to have to
maintain them for sanity purposes.

> Library elements to look at.

I think i am still confused. Will wait for those library elements.

cheers,
jamal