Subject: Re: [issue40] BLKINFO

From: "Putzolu, David" <[email-masked]>
Date: Thu, 9 Jun 2005 21:07:08 -0700

(hat off) 
I am in agreement with Joel, I'd prefer to only add optimizations after we get some operational experience that shows where the bottlenecks really are.

-David

-----Original Message-----
From: Forwarding and Control Element Separation [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, June 09, 2005 6:04 AM
To: [email-masked]
Subject: Re: [FORCES] [issue40] BLKINFO

I am still not convinced of the value, and would prefer to defer BLOCK 
constructs until we have some experience to know what enhancements we 
really need.

Yours,
Joel

At 08:57 AM 6/9/2005, Robert Haas wrote:
>I just re-read the relevant thread Ã  propos BLOCK selector. It seems that 
>besides Jamal and myself, nobody else declared whether the proposal 
>(repeated below) would be satisfactory and should be included in the 
>draft. Please let us know.
>Regards,
>-Robert
>
> From the thread titled "2005 Teleconf minutes (BLOCK semantics, etc)":
>
>As an alternative, couldn't we just add a flag to the BLOCK selector to 
>distinguish the two cases ?
>
>- BLOCK REPLICATE, with only the all-to-all semantic
>- BLOCK LIST, with only the one-to-one semantic.
>
>So while processing a ForCES message, one does not have to infer the 
>meaning of BLOCK based on the content (is it all-to-all or one-to-one). 
>Instead the flag will tell immediately.
>
>
>Avri Doria wrote:
>
>>New submission from Avri Doria <[email-masked]>:
>>
>>*  NOTE! NOTE! There is a selector known as BLKINFO that is left
>>         out of this doc for now that will be revisted later.  BLKINFO
>>         is defined as:
>>      *  SELECTOR := KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV :=
>>         [BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX]  A
>>         PathData can only have one selector either a KEYINFO TLV or a
>>         BLKINFO TLV (i.e not both).
>>
>>Revisit before PS or after?
>>
>>----------
>>category: Editorial
>>draft: draft-ietf-forces-protocol
>>messages: 58
>>nosy: avri
>>priority: May fix
>>status: No discussion
>>title: BLKINFO
>>
>>___________________________________________________
>>Forces issue tracker <[email-masked]>
>><http://www.mip4.org/issues/tracker/forces/issue40>
>>___________________________________________________
>>
>>
>>
>
>--
>Dr. Robert R. Haas
>IBM Zurich Research Laboratory
>SÃ¤umerstrasse 4
>CH-8803 RÃ¼schlikon/Switzerland
>phone +41-44-724-8698  fax +41-44-724-8578  http://www.zurich.ibm.com/~rha

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 10 Jun 2005 06:27:58 -0400

On Thu, 2005-09-06 at 21:07 -0700, Putzolu, David wrote:
> (hat off) 
> I am in agreement with Joel, I'd prefer to only add optimizations after 
> we get some operational experience that shows where the bottlenecks really are.
> 

We still have BLOCK operations in our implementation and it is useful -
so you could say we have operational experience. However, for the sake
of progress(so we can last call) and hopefully without need to repeat
the discussion we already had on the list:
Can we find a way to allow for proprietary implementations to do BLK
without much difficulty while at the same time not affecting the
protocol itself for anyone else?
Would a capability announcement by the FE do it? 

cheers,
jamal