Subject: Re: Protocol Operations

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 8 Feb 2005 15:34:50 -0800

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 19:23:08 -0500

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