Subject: Re: Protocol Operations

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 8 Feb 2005 17:16:51 -0800

Alright, here you go... 
(BTW, I believe that getting the Operations right is a core issue being
discussed->based on the subject of this email.)

This is an example based on the text that you sent out..
(Note the difference...based on the size of Flags, you save X*Y bytes,
as well as parsing overhead, where X is no. of entries and Y is size of
Flag. Also note, I have used IDs=4 i.e. table 2 as an example here, you
could be replacing entries in 3 different tables as well)

Current Approach -->>
operation = SET
		Path-data TLV : 
			Flags = F_REPLACE, IDCount = 1, IDs=4
			DATARAW TLV: L=XXXX, V = {1, j1value, j2value}
		Path-data TLV : 
			Flags = F_REPLACE, IDCount = 1, IDs=4
			DATARAW TLV: L=XXXX, V = {3, j1value, j2value}
		Path-data TLV : 
			Flags = F_REPLACE, IDCount = 1, IDs=4
			DATARAW TLV: L=XXXX, V = {15, j1value, j2value}

New Proposal -->>
Operation = REPLACE
	Path-data TLV: 
		IDCount = 1, IDs=4
		DATARAW TLV: L = XXX, V=1, j1value, j2value
	Path-data TLV: 
		IDCount = 1, IDs=4
		DATARAW TLV: L = XXX, V=3, j1value, j2value
	Path-data TLV: 
		IDCount = 1, IDs=4
		DATARAW TLV: L = XXX, V=15, j1value, j2value

Hopefully this is a satisfactory explanation. Let me know if I
misunderstood something.
One argument for this is efficient and the other is interoperability
concerns that David posted.
(multiple ways of doing the same thing -> setting Operation in this
case)

regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Tuesday, February 08, 2005 4:23 PM
To: [email-masked]
Subject: Re: [FORCES] Protocol Operations

Hormuzd,

Earlier i asked if you had read the doc - you said you did.
Heres what you should do:

Create an example to match what you describe below and show
both schemes using sensible representation. From that 
derive that what you are proposing is better. It would be a good
exercise to go through all the examples if you have cycles.
I doubt you will find theres a sufficient difference to be worth the
time or bandwidth so far consumed by this discussion. 
Thats where the issue becomes a philosphical one.

I was asking for you to defer this to later because this is one of 
those things that could distract the core discussion. 

cheers,
jamal
 
On Tue, 2005-02-08 at 18:34, Khosravi, Hormuzd M wrote:
> Jamal,
> 
> I don't think this is philosophical at all, its very much technical...
> Let me repeat the reasons that I gave with some numbers, may be that
> will help.
> 
> If I have to update 10 entries in a LFB table, it would be a lot
> efficient in terms of parsing as well as message size to represent
that
> as an Operation TLV, with Operation=UPDATE, rather than an Operation
> TLV, with Operation=SET and 10 PATHs, each with FLAG=F_UPDATE. This is
> pretty straight forward, what am I missing here ??
> 
> I don't think I need to open another issue for this since it is in the
> context of Path-data which is being discussed here.
> 
> Regards
> Hormuzd
> 
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
> Sent: Tuesday, February 08, 2005 1:26 PM
> To: [email-masked]
> Subject: Re: [FORCES] Protocol Operations
> 
> Hormuzd,
> I understood you earlier and yes that would work, but like i said
> earlier (text still at the end of this email actually):
> Why would this have _more_ merit than whats there right 
> now. Essentially its a philosphical question: Is the glass half full
or
> half empty? 
> If you feel strongly about it, please open an issue report
> and we can revisit it later. 
> 
> cheers,
> jamal
> 
> On Tue, 2005-02-08 at 16:00, Khosravi, Hormuzd M wrote:
> > Here is what I am suggesting,
> > 
> > The Operation TLV =
> >  
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |  Operation (ADD)      | Flags |               Length
> > |
> >  
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |
> > |
> >         ~                         <Path-Data>+
> > ~
> >         |
> > |
> >  
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > 
> > Operations = ADD/CREATE, DEL, UPDATE/REPLACE.
> > I guess DEL ALL == DEL followed by a Table ID (for example) so that
is
> > not needed
> > Flags = SELECTOR Bits
> > -->00: indicates absence of the selector 
> > -->01(F_SELTAB): indicates what follows is a table. The
> > path should be sufficient to point to a table; so this flag
> > is redundant but here for completion sake
> > -->10(F_SELBLK): indicates that what follows is a BLKINFO
> > -->11(F_SELKEY): Indicates what follows is a KEYINFO
> > 
> > Let me know why this wont work, or what I am missing here ?
> > 
> > Thanks
> > Hormuzd
> > 
> > -----Original Message-----
> > From: Forwarding and Control Element Separation
> > [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
> > 
> > You cannot remove the flags. If you could it may make sense to move
> > those two to the operations level. As it stands right now, either
have
> > equal merit. If you look at the examples i posted, it is possible
> infact
> > to replace and create different items within one SET operation - but
i
> > dont think this in itself stands as a reason for their existence. 
> > 
> > cheers,
> > jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 8 Feb 2005 20:35:42 -0500

On Tue, 2005-02-08 at 20:16, Khosravi, Hormuzd M wrote:

> Hopefully this is a satisfactory explanation.

Not so fast.
Pick one with nested TLVs. Take Example 15. Maybe the meanings of the
flags will become obvious after that.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 9 Feb 2005 14:10:01 +0800

Hi Jamal, Hormuzd,et al,

I have to say I actually have quite the same thoughts on the flags with Hormuzd. I think we have already agreed on the following operation structure:

Message Level:  Configure    Query
                /   |   \
OpTLV Level:   Set Del Modify

My thoughts is using these two levels of coding for assignment of operations have already been enough and rich. To use further flags in every path-data for ops may make our product- the protocol rich more than necessary, and become quite complex.

Note that, we can take a 'Set' op as to set some data to FE, thus, we don't need to further recognize the op being a replace (update) or a new create. Take Jamal's example 15 as an instance, I think we don't need to assign that it is a replace kind of Set, it's just a Set.

Cheers,
Weiming