Re: updated message layout doc

Hi Jamal,

To respond to your ask for more detailed description of my thoughts, I compose a
text in the attachement. Because it is just for discussion, I think you may not
care too much about the roughness of the text.  Thank you.

Hi Ellen,

I'm ok with the time you scheduled. Thank you.

Cheers,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <hadi <at> ZNYX.COM>
>
> Attached a little document to reinject stalled discussion.
>
> Purpose is to help reach a quicker convergence
> on the message layout as well as influence how the
> model and protocol teams on moving forward. This should reduce
> current confusion on both sides on how message content is
> delivered and how such content is to be modeled so it can
> be appropriately delivered.
> It captures my thoughts that are influenced by many discussions
> on the list. It also captures a divergence from that thinking
> with Joel. Theres a slight different view by Weiming but because
> i was lacking details i didnt capture it.
> Weiming please send me an update.
>

Re: updated message layout doc

Seems an attachment can not be posted, trying again.

----- Original Message -----
From: "Wang,Weiming" <wmwang <at> mail.hzic.edu.cn>
> Hi Jamal,
>
> To respond to your ask for more detailed description of my thoughts, I compose
a
> text in the attachement. Because it is just for discussion, I think you may
not
> care too much about the roughness of the text.  Thank you.
>
> Hi Ellen,
>
> I'm ok with the time you scheduled. Thank you.
>
> Cheers,
> Weiming
>
> ----- Original Message -----
> From: "Jamal Hadi Salim" <hadi <at> ZNYX.COM>
> >
> > Attached a little document to reinject stalled discussion.
> >
> > Purpose is to help reach a quicker convergence
> > on the message layout as well as influence how the
> > model and protocol teams on moving forward. This should reduce
> > current confusion on both sides on how message content is
> > delivered and how such content is to be modeled so it can
> > be appropriately delivered.

Re: updated message layout doc

Seems still not work for the attachment. I just directly put the contents below.

Sorry for it.
Weiming

****************************************************************

Followed are some of my thoughts on the message TLV format for discussion:

1. Message Format

1) Config Message

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   Msg Header(MessageType='Config')            ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          LfbTLV                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          OpTLV                                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          DataTLV                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          ...                                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          OpTLV                                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          DataTLV                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Re: updated message layout doc

Weiming,
I was away the last week. I just went over your text briefly.

While you are trying to reduce the amount of parsing involved
(a noble effort), the result is you have lost clean structuring.
As i am digging deeper i am more inclined to think that maybe Joels
approach or a refined variant of it is the way to go. It is a little
more processor intensive but will make management interface a lot more
sane. Unfortunately mngmt interface is a very important tradeoff in the
overall design (at some point manageability of Forces will kick in -
currently people write MIBS - we should be able to use XML instead).
My suggestion is to try and look at Joels delta and see if that can be
cleaned up.

Lets talk in tommorows design meeting (or if you can respond before the
meeting then we can have a starting point).

cheers,
jamal

On Mon, 2004-09-06 at 00:43, Wang,Weiming wrote:
> Seems still not work for the attachment. I just directly put the contents below.
>
> Sorry for it.
> Weiming
>
> ****************************************************************
>
> Followed are some of my thoughts on the message TLV format for discussion:
>

Re: updated message layout doc

Hi Jamal,

Thank you for the response. Some replies inline.

----- Original Message -----
From: "Jamal Hadi Salim" <hadi <at> ZNYX.COM>

> Weiming,
> I was away the last week. I just went over your text briefly.
>
> While you are trying to reduce the amount of parsing involved
> (a noble effort), the result is you have lost clean structuring.
[Weiming]As I mentioned before, the effort is not just for easy parsing, but
also for more clean structure and more flexibility (by use of universal LfbTLV,
OpTLV and even DataTLV). I'm not very sure of clean structuring you mean here.
Do you mean the individual TLVs are too complicated, or the message format is
too complex? I'm trying to understand it. would be helpful if you could give a
litlle more detailed thoughts here, thank you.

> As i am digging deeper i am more inclined to think that maybe Joels
> approach or a refined variant of it is the way to go. It is a little
> more processor intensive but will make management interface a lot more
> sane. Unfortunately mngmt interface is a very important tradeoff in the
> overall design (at some point manageability of Forces will kick in -
> currently people write MIBS - we should be able to use XML instead).
> My suggestion is to try and look at Joels delta and see if that can be
> cleaned up.
[Weiming]I checked your summary on Joel's idea. I suppose what you summarized
there is mainly about the way for table indexing. We the teams truly have quite
different thoughts on if the index should be put in protocol layer or not,

Re: updated message layout doc

I agree with Joel's approach regarding generic operations such as ADD,
DEL which apply to all LFBs...its a clean approach, I have seen it used
in a lot of other protocols and we already had this in our protocol
draft as well.

My 2 cents,
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
Sent: Saturday, August 28, 2004 11:15 AM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: [FORCES] updated message layout doc

Attached a little document to reinject stalled discussion.

Purpose is to help reach a quicker convergence
on the message layout as well as influence how the
model and protocol teams on moving forward. This should reduce
current confusion on both sides on how message content is
delivered and how such content is to be modeled so it can
be appropriately delivered.
It captures my thoughts that are influenced by many discussions
on the list. It also captures a divergence from that thinking
with Joel. Theres a slight different view by Weiming but because
i was lacking details i didnt capture it.
Weiming please send me an update.

Both Joel and myself are looking forward to being beaten up (as opposed

Table model and config operators in ForCES rev. 2

After some discussions between the model and protocol design teams,
Zsolt Haraszti and I took the to-do to put together a proposal on how
LFB tables could be modeled and managed in the protocol.  The attached
file is what we came up with.

Please review and send comments to the list.

Regards,

// Steve

Tables in the ForCES Model                                20-September-2004
==========================

1  Table Definition and Indexing
--------------------------------

An LFB table is a conceptual model of an ordered list of data elements
(entries) of identical type, where the type can be any of the  ForCES-
supported data types, including atomic and compound types.  Note  that
since compound types include arrays and  structs,  the  entries  in  a
table can be or can include other tables, respectively. The conceptual
model of the table need not correspond closely with any implementation
construct: any implementation may choose to  use  an  array,  a  radix
tree, a hash table, a doubly linked list, etc.

Each element in the table may be uniquely identified by its associated
table index, where the index is an unsigned integer that  is  assigned
-- either by the FE or the CE, depending  on  operation  --  when  the

I-D ACTION:draft-ietf-forces-protocol-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF.

	Title		: ForCES Protocol Specification
	Author(s)	: A. Doria
	Filename	: draft-ietf-forces-protocol-00.txt
	Pages		: 60
	Date		: 2004-9-30
	
This specification documents the Forwarding and Control Element
Seperation protocol.  This protocol is desgined to be used between a
Control Element and a Forwarding Element in a Routing Network
Element.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-forces-protocol-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-forces-protocol-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt