Subject: Re: On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 16 Feb 2005 15:04:38 -0800

I don't think Weiming had any comments on this one.

So just to clarify, what you're saying is that "The KEY and BLK
selectors cannot be combined in the same Op TLV". I think we are all on
the same page, if this is the case.

Thanks for the clarification,
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Wednesday, February 16, 2005 12:34 PM
To: [email-masked]
Subject: Re: [FORCES] On efficiency, ambiguity, and simplicty of BLK
Selector WAS(Re: Ambiguity in BLOCK semantics-some qs?

I dont think theres any contention on this issue.
Maybe Weiming didnt like it? I dont remember. The short answer is 
yes, this is the way it is and the update to the draft will only
mention BLK once and say this as well.

cheers,
jamal

On Wed, 2005-02-16 at 15:22, Khosravi, Hormuzd M wrote:
> Jamal,
> 
> Another contentious issue that you pointed me to was using KEY and BLK
> selector in the same Op TLV. Is this still contentious ? I agree with
> Joel's view that these cannot be combined.
> 
> Do we have agreement on this ?
> 
> Thanks
> Hormuzd 
> 
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
> Sent: Wednesday, February 16, 2005 8:31 AM
> To: [email-masked]
> Subject: [FORCES] On efficiency, ambiguity, and simplicty of BLK
> Selector WAS(Re: Ambiguity in BLOCK semantics-some qs?
> 
> Folks,
> 
> First off let me say that the next release of the draft(which i am
> editing as we speak) will leave out using BLK selector. That does not
> mean it is dead; it just means its defered so we can make progress. 
> 
> Despite leaving out BLK, I have to say Iam pleased at the progress we
> made - thanks to everyone who chipped in. We do have finally something
i
> would almost call usable and semi-agreeable to all. 
> I am hoping any changes going forward (including BLK if we find it
> usable) will not deviate us from the main BNF and layout and will be
> mostly cosmetic in nature.
>  
> Its always great to make progress in the presence of many good ideas. 
> So thanks again.
> 
> So this email is not about what goes into upcoming draft.
> However, since the discussion continues on the BLK avenue, I am going
to
> contribute since i am a fan of BLK.
> 
> 1) Efficiency factor.
> Is there anyone _doubting_  that BLK is more efficient for row table
> operations than without it? If there is i will provide the proof
> numbers.
> An average BLK operation will be cheaper on the wire
> than non-BLK and will have at least one less nest level.
> So BLK wins down both in b/width and parsing/compute.
> 
> Again, if anyone wishes to contend this let me know so i can provide
the
> numbers. If noone contends this, lkets cut the discussions and never
> bring it up but assume it for any future discussion.
> 
> 2) Ambiguity:
> Theres none really as far as i am concerned. Its a difference of
opinion
> 
> more than anything else between Joel and myself.
> Joel has a certain view of what it means to follow a selector.
> which is different from mine. 
> Maybe this is the most important thing that we need to be discussing.
> 
> 3) simplicty.
> I fail to see this being used as an arguement for non-BLK. 
> Lets take an average example (any other examples of the same nature
> would look
> similar - some would make BLK look better but they are corner cases as
> far as i am concerned):
> 
> "create entry 0-5 of table2"
> I) Using BLK selector
> 
>         Path-data TLV: 
>                 flags = F_CREATE | F_SELBLK , IDCount = 1, IDs=4
>                 BLK_RANGE_INDEX TLV
>                         start = 0
>                         end = 5
>                 DATARAW TLV: L = XXX, V=
>                        j1value,j2value  entries (6 in total)
> 
> II) not using BLK selector
> 
>         Path-data-TLV: 
>                 flags = 0 , IDCount = 1, IDs=4
>                 PATH-DATA-TLV
>                     flags = 0, IDCount = 1, IDs = 0
>                     DATARAW-TLV containing j1, j2 value for 0
>                 PATH-DATA-TLV
>                     flags = 0, IDCount = 1, IDs = 1
>                     DATARAW-TLV containing j1, j2 value for 1   
>                 PATH-DATA-TLV
>                     flags = 0, IDCount = 1, IDs = 2
>                     DATARAW-TLV containing j1, j2 value for 2
>                 PATH-DATA-TLV
>                     flags = 0, IDCount = 1, IDs = 3
>                     DATARAW-TLV containing j1, j2 value for 3
>                 PATH-DATA-TLV
>                     flags = 0, IDCount = 1, IDs = 4
>                     DATARAW-TLV containing j1, j2 value for 4 
>                 PATH-DATA-TLV
>                     flags = 0, IDCount = 1, IDs = 5
>                     DATARAW-TLV containing j1, j2 value for  5
> 
> 
> So which one is simpler?
> To be honest i dont see them being that different to the machine
parsing
> them - to the human eye the BLK one is good candy, but i wouldnt use
> this
> as a strength for BLK; 
> so we probably shouldnt be discussing this "simplicty" angle either.
> 
> This leaves us with #2 and #1 being a trump in favor of BLK.
> 
> 
> cheers,
> jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 16 Feb 2005 18:17:47 -0500

Sorry, no. My mistake.
They cannot be in the same PATH-DATA under the same SELCTOR. But they
can be in the same OPER TLV. When we started we allowed for them to
appear in the same SELECTOR. Thats what Joel was asking for.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Feb 2005 20:29:41 -0500

As you say, when a selector is allowed to have BLK again, the rule will be 
that you can not have both KEY and BLK as immediate descendents in the same 
PATH-DATA.

There can certainly be two path-datas in the same OP, one with KEY, one 
with BLK, (and more).
And one can even have a PATH-DATA with a BLK, and nested PATH-DATAs, one or 
more of which have KEYs.  (or the reverse, etc.)

Yours,
Joel

PS: All that is required to capture this is that the Selector BNF line will 
be an or:
SELECTOR :=  KEYINFO-TLV / BLOCK-SELECTION-TLV