Re: [Forces-protocol] RE: GET/SET in one msg ?

[Robert Haas <[e-mail]>]

I think Zsolt has specified the multicast at LFB Instance-level very 
well. We had some discussions with Joel a while back and such a table 
with pointers from a -virtualID- to a list of LFB Instances was 
considered the way to go.

But the subtle difference betwen Zsolt's proposal and the current 
approach taken in the protocol draft is that the PL-message destination 
ID is the -virtualID-, instead of introducing a new MIID. See Section 5 
point g in the protocol draft.

I would favor the current approach for the following reasons (but I am 
not religious and want to hear other opinions):

1)  -virtualID- must be unique NE-wide. The PL-level addressing IDs are 
by definition unique NE-wide.

2)  Messages addressed to a group of LFBs that spans FE A and B should 
not be delivered to FE C. So a PL-level multicasting is anyway needed . 
Adding an additional MIID would then be redundant.

To cover the case of a list of LFB Instances (reminds me of xcast ;-) we 
can modify the LFBSelect TLV as follows:

main hdr (eg type = config)
|
+--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- one more LFBInstance(s) = target LFB instance(s). 
                  [the size of this TLV tells how long the list is]

But in the case of a multicast, I would simply drop the LFBSelect TLV altogether as it is redundant (the LFB Instances are already selected by the -virtualID-). What do you think ?


Regards,
-Robert

Wang,Weiming wrote:

>Hormuzd,
>
>Thanks for reply.
>
>----- Original Message -----
>From: "Khosravi, Hormuzd M" <[e-mail]>
>Weiming,
>
>In majority of cases, most of us have only seen single LFB instances on
>FEs.
>[Weiming] I'm afraid this is not true. From my experience, it's very often we
>have more than  one instances.
>
>In any case, your requirement can easily be solved by defining a special
>Instance ID for LFBs that addresses all instances of that LFB on the FE.
>I thought we already had some text along these lines in the protocol
>draft (probably the header section)
>[Weiming] Yes, we have proposed using an insatnce broadcast address to address
>all instances. It's useful, but still from my experience, it's not enough. I'v
>very often seen the case where there is only one insatnce that has different
>config requriement than all other instances.
>
>regards
>Hormuzd
>p.s. I haven't read Zsolt's email on this yet...
>
>-----Original Message-----
>From: Wang,Weiming [mailto:[e-mail]]
>Sent: Monday, October 18, 2004 9:00 PM
>To: [e-mail]
>Cc: Khosravi, Hormuzd M; [e-mail]; Steven Blake (petri-meat);
>Joel M. Halpern; Alan DeKok; [e-mail]; [e-mail];
>Deleganes, Ellen M; Yang, Lily L
>Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?
>
>Jamal,Hormuzd, and Joel,
>
>I think we have already have the issue as an editorial note as below:
>
>       Editorial Note:
>                        1.  Under discussion is, when an 'FE Protocol
>...
>
>                        2.  Under discussion is, do we need to support
>                            multiple objects addressing at the LFB Type
>                            and LFB Instance layer? One simple way to
>                            support multiple LFB types or instances is
>                            to use TLVs to identify the group of Type
>                            IDs and Instance IDs, rather than only one
>                            Type and Instance ID.  A range of Instance
>                            IDs may also be supported in this way.
>
>Hormuzd and Joel, do you really think it is not the case? I remember
>Joel
>supposed there might be thousands of instances with same LFB calss.  In
>this
>case, if we do not support a range of intance addressing, it actually
>makes our
>protocol unpractical.
>
>regards,
>Weiming
>
>----- Original Message -----
>From: "Jamal Hadi Salim" <[e-mail]>
>  
>
>>So far you are the second person who has shown desire for this. I was
>>the other person; both of us are driven by implementation experience.
>>How about we just keep it as a note in the draft for now (for progress
>>reasons)?
>>Hopefully implementation experience will show the error of whats being
>>proposed right now, then we can come back and fix it?
>>
>>cheers,
>>jamal
>>
>>
>>On Mon, 2004-10-18 at 10:20, Weiming Wang wrote:
>>    
>>
>>>Hi Jamal,
>>>
>>>main hdr (eg type = config)
>>>     |
>>>     |
>>>     +--- T = LFBselect
>>>     |        |
>>>     |        +-- LFBCLASSID = target LFB class
>>>     |        |
>>>     |        |
>>>     |        +-- LFBInstance = target LFB instance
>>>
>>>[Weiming] The more I'm thinking, the more I see the value to address
>>>      
>>>
>multipul
>  
>
>>>LFB instances here (I can now live with single LFB class). To speak
>>>      
>>>
>of this,
>I
>  
>
>>>have an aspire  to show my yesterday experience with my GRMP test
>>>      
>>>
>platform
>  
>
>>>(sorry I have to mention it). As you know, GRMP  does not support
>>>      
>>>
>multipul
>LFB
>  
>
>>>instance addressing.  Yesterday, we had to prepare a show of the
>>>      
>>>
>platform to
>  
>
>>>guests from our sponsors. Before the show, we spent near one hour to
>>>      
>>>
>operate
>on
>  
>
>>>the menu to construct a scenario, in which there were 5 output port,
>>>      
>>>
>5
>  
>
>>>associated schedulers (LFBs), and several other LFBs that have many
>>>      
>>>
>instances.
>  
>
>>>unfortunately, we faced a problem with one of the machine. Then we
>>>      
>>>
>had to do
>it
>  
>
>>>again.  At that time, I had a VERY VERY strong desire that batch
>>>      
>>>
>configuration
>  
>
>>>based on multipul LFB isntance addressing can be used.
>>>
>>>I can see very simple scheme to include multipul instances here (by
>>>      
>>>
>ranging,
>or
>  
>
>>>by enum, or by both). Definitely, I believe this will greatly
>>>      
>>>
>improve our
>  
>
>>>protocol.
>>>
>>>I sincerely hope this be considered seriously by gentlemen.
>>>
>>>Best regards,
>>>Weiming
>>>
>>>     |        |
>>>     |        |
>>>     |        +-- T = operation { ADD, DEL, GET, etc}
>>>     |        |   |
>>>     |        |   +--  // one or more path targets
>>>     |        |        // under discussion
>>>     |        |
>>>     |        +-- T = operation { ADD, DEL, GET, etc}
>>>     |        |   |
>>>     |        |   +--  // one or more path targets
>>>     |        |        // under discussion
>>>     |        |
>>>     |        +-- T = operation { ADD, DEL, GET, etc}
>>>     |        |   |
>>>     |        |   +--  // one or more path targets
>>>     |        |        // under discussion
>>>     |        |
>>>
>>>In other words: Very similar to the way we have it already except
>>>the naming has changed and we can target multiple
>>>operations and multiple paths in an LFB instance
>>>----- Original Message -----
>>>From: "Jamal Hadi Salim" <[e-mail]>
>>>      
>>>
>>>>Welcome back Weiming. I have updated the text with the
>>>>        
>>>>
>query/response.
>  
>
>>>>The only outstanding issue is 6.7. Please weigh in.
>>>>I think we are ready top start making updates.
>>>>
>>>>cheers,
>>>>jamal
>>>>
>>>>        
>>>>
>>>      
>>>
>
>
>
>_______________________________________________
>Forces-protocol mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/forces-protocol
>
>
>
>_______________________________________________
>Forces-protocol mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/forces-protocol
>
>
>  
>

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone [phone]  fax [phone]  http://www.zurich.ibm.com/~rha

_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol