Re: Model Draft Progress

Re: Model Draft Progress

Re: Model Draft Progress

Re: Model Draft Progress

I would like to keep both datatypes.
byte[N] is defined to be a byte string of exactly N bytes.  It is 
used for things like IPv4 address, IPv6 address, IEEE Mac address, or 
any other fixed size byte string.
octetstring is a variable length sequence of bytes, such as a packet 
buffer, a variable length identifier, etc.
The distinction is described in section 4.5.  If you think we need 
more words, please let me know where and what words, and I will be 
happy to put them in.

Yours,
Joel

At 09:03 AM 6/12/2006, JiaFenggen wrote:
>in section 4.5. <dataTypeDefs> Element for Data Type Definitions,we 
>have both definitions byte[N] and octetstring[N],I think 
>octetstring[N] will satify our needs,for packet buffers and for some 
>state infomation.

Re: Model Draft Progress

Thanks for reading the document.
With regard to the Editor's notes, I sent a series of emails to the 
list last March proposing resolutions for each and every one.  A few 
people commented on 1 such note.  Most of them seem to have been 
ignored.  If folks want, I can go through and resend all of them.

With regard to the library, I agree that we need a common set of 
library elements.  I don't think the protocol needs to mandate 
them.  If we produce an initial library draft which, at least for 
common functions, provides a way to represent the function, then 
folks will use that.  Of course, the fact that no one has sent ANY 
contributions to the library draft since the last meeting does not 
give me great hope in that regard.

I will comment on your other issues in a separate response.

Yours,
Joel

Re: Model Draft Progress

Thank you for going through the document carefully.
Responses in line.

At 02:53 AM 6/12/2006, Alex Audu wrote:
>=====================================================================
>
>    3.3.2. Configuring the LFB Topology
>   [
>       configuration capabilities.  Therefore, the FE model MUST provide a
>       mechanism for describing the LFB topology configuration capabilities
>
>    ...
>   ]
>  Comments:
>  We many need to include bandwidth or speed capability measure.
>(This also affects section:  5.2. FE Capabilities)

If we want more capabilities, I would be happy to add them.  Probably 
just in 5.2, since 3.3.2 does not claim to be comprehensive.  I 
presume that there are more capabilities, and more statistics, desired.
But I am not going to invent them myself.

Having said that, I don't think that there is a useful "bandwidth" or 
"speed" capability for the FE as a whole.  It has a set of ports, 
each of which may have performance capabilities.  I would not want to 
try to represent in forces the question of whether the FE can 
actually handle wire-rate minimal size packets on all interfaces, or 
just what combination it can handle.

Ports, and similar constructs will likely have both performance 
capabilities and performance statistics.

>
>
>    4.2. <LFBLibrary> Element
>    [
>       The <LFBLibrary> element serves as a root element of all library
>       documents. It contains one or more of the following main blocks:
>       ...
>       Each block is optional, that is, one library document may contain
>       only metadata definitions, another may contain only LFB class
>       definitions, yet another may contain all of the above.
>    ]
>
>    Comments:
>    Each library block being optional implies that you could have a situation
>    where no block is present at all.  What would that mean?

It would mean one had a syntactically valid but useless library 
document.  It doesn't hurt anything for that to be legal.  No one 
will use it, and if they do it will be ignored.

>
>
>   4.5.3. <array> Element to Define Arrays
>
>   In the following, the elementID 2 has both <name> and <typeRef> 
> of "opcode".
>   Is that intentional? It could be difficult for the parser to tell which is
>   which.
>       <dataTypeDef>
>   ...
>             <element elementID="2">
>               <name>opcode</name>                        <<<<---------
>               <synopsis>The result code</synopsis>
>               <typeRef>opcode</typeRef>                   <<<---------
>             </element>
>   ...

This looks like a case that is perfectly legal, and a bad idea.

The array (elided) contains a structure.  The structure contains two 
components (elements).  The second component is named (for human 
discussion / description purposes) "opcode".  That name is only 
meaningful in element references.
The type of the element is a declared type of opcode.  That is a 
meanign only in type contexts.
So the two can be disambiguated.

However, that is clearly a bad idea, and does NOT promote clear 
understanding.  I will change one or the other name when I revise the document.

>    4.5.6. Augmentations
>    Another 4.5.6 subection ??? (See above for the first one)
>    Is "augmentation" a mechanism for inheritance?

Yes, Augmentation is related to inheritance, and is another way to 
build up structures / types.  And yes, it shoudl be 4.5.7.  (MS Word 
is not my friend.)

>Also address the following EDITOR note:
>         . The optional <defaultValue> element can specify a default value
>            for the attribute, which is applied when the LFB is initialized
> >>>        or reset.  [EDITOR: A convention to define default values for
>            compound data types and byte[N] atomic types is yet to be
>            defined.]

Do you have a suggestion for a reasonable syntax for this?

>    5.2.2.6. LFBClassCapabilities
>
>    When do we fill in the "important omissions" in the folowing paragraph?
>
>    [
>       This element contains capability information about the subject LFB
>       class whose structure and semantics are defined by the LFB class
>       definition.
>
>   >>> [Note:  Important Omissions]
>
>       However, this element does not appear in the definition, because the
>       author can not figure out how to write it.
>   ]

I believe that this was not addressed by any of my earlier notes.
Currently, the way out is to not have "class level" 
capabilities.  Rather, any such capabilities get defined on instances.
This means that
a) The FE pretends there is duplicate information in each instance 
(not a big deal)
b) The CE must create an instance to get any class level 
capabilities. (Unfortunate.)

If folks care about the issue, then we have to figure out what we 
want to put in the FE Attribute information.  We have the per-class 
table already.  One approach would be:
1) Define an element for LFBClassCapabilites.
2) Define the Content to be ANY and the attributes to be ANY
3) State the the LFB definition must also include a schema fragment 
for its class capabilities, if any.
While this works, it is really hard for any standard XML processor to 
make use of.

Anyone have a better suggestion?

Yours,
Joel M. Halpern

Agenda IETF Montreal

ForCES will meet at the next IETF in Montreal. At the moment
we are on Monday afternoon on the agenda. Please let me and
David know if you need some time on the agenda.

Thanks,
Patrick

http://www.ietf.org/internet-drafts/draft-ietf-forces-tmlsp-00.txt

http://www.ietf.org/internet-drafts/draft-ietf-forces-tmlsp-00.txt

Olla!

On Fri, 2006-16-06 at 14:52 -0400, Alex Audu wrote:
> Hi All,
>  
> I took a quick read of the TMLSP draft. These are my comments:
>  
> ==============================================
>  3.2. TML Requirements 
>    ...
>    3. Congestion Control 
>    The congestion control scheme used needs to be defined. The 
>    congestion control mechanism defined by the TML should prevent the
> FE 
>    from being overloaded by the CE or the CE from being overwhelmed
> by 
>    traffic from the FE.  Additionally, the circumstances under which 
>    notification is sent to the PL to notify it of congestion must be 
>    defined. 

> Comments: Control message link should never be congested.  Allowing
> this will
>    geopardize the surviveability of the system especially when under
> traffic
>    pressure.  I believe that is why we recommended independent links
> for CE-FE
>    data and control traffic. The data channel can may congest, but not
> the 
>    control.
> 

It is a hard problem to ensure zero congestion unless you do admission
or rate control - which is not something we have defined as part of
forces (but could be done as a side feature within an implementation).
So we need the above signaling.

> 5.5.TML Configuration 
>   Comments: The PL can use this primitive to set up 
>    - number of channels for control flow,
>    - number of channels for data flow,
>    - flow mode ( connection-oriented,..etc)
>    - loop-back connection for testing purposes,
>    - unicast/multicast channels
>    - ....

Did you mean F/CEM instead of PL? It would make sense if it is.

> 5.6. TML Query 
>    
>   Comments: PL or management entity can use this primitive to query 
>   TML states,..for example:
>    - error counts / error status
>    - packet flow counts
>    - band width utilization,
>    - configuration status
>    - ...
> 
Maintaining these stats is valuable, but:
What would be the purpose of such knowledge for the PL? I can see the
desire for such an interface to be used for the xEM for example. 

cheers,
jamal

http://www.ietf.org/internet-drafts/draft-ietf-forces-tmlsp-00.txt

Hi Alex,

thanks so much for the review. pls see inline replies.

Yours,
Weiming

----- Original Message ----- 
From: Alex Audu

 3.2. TML Requirements
   ...
   3. Congestion Control
   The congestion control scheme used needs to be defined. The
   congestion control mechanism defined by the TML should prevent the FE
   from being overloaded by the CE or the CE from being overwhelmed by
   traffic from the FE.  Additionally, the circumstances under which
   notification is sent to the PL to notify it of congestion must be
   defined.
Comments: Control message link should never be congested.  Allowing this will
   geopardize the surviveability of the system especially when under traffic
   pressure.  I believe that is why we recommended independent links for CE-FE
   data and control traffic. The data channel can may congest, but not the
   control.
[Weiming] I actually agree control message link should never be congested.  But
note that keeping the mechanism for TML to notify PL of any congestion state
event does not mean we overthrow the principle. In most cases, it may just acts
as a signal to ask PL to stop draining ctr msgs to the TML. This actually has
nothing to do with the real congestion on the link.  We required that a TML must
provide a scheme to avoid congestion just on the wire.

5.5.TML Configuration
  Comments: The PL can use this primitive to set up
   - number of channels for control flow,
   - number of channels for data flow,
   - flow mode ( connection-oriented,..etc)
   - loop-back connection for testing purposes,
   - unicast/multicast channels
   - ....
[Weiming] I think Jamal's reply is relavant to the question. These functions
should  belong to CEM/FEMs.  After PL reuiremesnts to TML are met, It should be
TML's own business how to arrange things like  channels and flow modes to
realistically meet the requirements.  Unicast/Multicast is also the same.  The
only thing that TML SP should address is some parameters needed for multicast,
that must be generated by PL.

5.6. TML Query

  Comments: PL or management entity can use this primitive to query
  TML states,..for example:
   - error counts / error status
   - packet flow counts
   - band width utilization,
   - configuration status
   - ...
[Weiming] I may first note that current XML based TML model is quite open to TML
attributes definitions.  Without any change to TML SP,  new necessary TML
attributes can be added.  For the TML states you mentioned above,  I think
configuration status is the only state PL is interested. For others, xEMs may be
more interested, as Jamal noted.

Thanks again.

=================================================

Regards,
Alex
www.garlandsoftworx.com