Subject: RE: [Forces-protocol] topic 4c: Common Header

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 4 May 2004 13:31:47 -0700

Robert,
 
Thanks for the clarification. I like your reasoning. Pls see my comments
below.

-----Original Message-----
From: Robert Haas [mailto:[email-masked]]   
 
 LFB TypeID: TBD, no consensus on whether it is needed or not in the
header

I think you somehow need to be able to inspect the message and say

clearly who (FE/CE) and what (LFBID) that the message is directed at.

If not for any other reason, this is useful for debugging in the
field.   
I would like to be able to run a tcpdump session in a box where all

forces messages are mirrored to and debug a race condition for example.

My view would be to have this field to have may be one bit to
represent  
direction and the rest of the bits to represent they type of LFB being

targetted (set to zero or all 1s if message is not LFB specific)

[HK] Robert had pointed out that he would like to use this field to

address a message to a group of LFBs in different FEs (multicast based

on LFB Type ID). Do you agree with this ? That might be a more

compelling reason to me for having this field. I don't say that

debugging is not important, but we do have sophisticated tools these

days, which can easily look beyond headers into protocol messages these
days.  
(I believe even tcpdump can do this quite easily.)    

I cant remember what Roberts suggestion was; i know its in the archives,

my brain is still slow. I 'll let him explain.

[HK] Robert, any comments ??

The idea behind the LFB TypeID is to be able to easily broadcast a
message to all instances of a particular LFB class in an NE, without
having to address these LFBs individually. 

For instance, this can be useful if we want to get all interfaces
active, or if we want to update a route in all FEs.

It greatly simplifies the use of the PL as one can start downloading
routes to the FEs without even knowing the ID of the FEs or of the LFBs.
Can call this a "plug-and-play" feature, which is invaluable from a
user's perspective.

More precisely, I see the following three cases of interest (with
increasing scope):

dest ID: FE x,               LFBType: y     addresses all LFBs of type y
in FE x
dest ID: group FE z,     LFBType: y     addresses all LFBS of type y in
the group z of FEs.
dest ID: FE broadcast, LFBType: y     addresses all LFBS of type y in
all FEs in the NE.

 [HK] I like this use of the LFB Type ID, this is a good reason for
having it in the common header. We had proposed a different approach for
addressing LFBs of same type, but this is also fine.
 
regards
Hormuzd

---

From: Jamal Hadi Salim <[email-masked]>
Date: 05 May 2004 22:25:48 -0400

There is actually one challenge with keeping the LFBid in the header:
You cant mix different LFBs in one batch. In order to send a batch with 
different LFB commands you have to send a batch of separate PL messages.

We could introduce an "opaque" LFBid which translates to "look inside
the message body for LFB type" and then that could be used for mixed LFB
messages.

cheers,
jamal

On Tue, 2004-05-04 at 16:31, Khosravi, Hormuzd M wrote:
> Robert,
>  
> Thanks for the clarification. I like your reasoning. Pls see my
> comments below.
[..]

>         The idea behind the LFB TypeID is to be able to easily
>         broadcast a message to all instances of a particular LFB class
>         in an NE, without having to address these LFBs individually. 
>         
>         For instance, this can be useful if we want to get all
>         interfaces active, or if we want to update a route in all FEs.
>         
>         It greatly simplifies the use of the PL as one can start
>         downloading routes to the FEs without even knowing the ID of
>         the FEs or of the LFBs. Can call this a "plug-and-play"
>         feature, which is invaluable from a user's perspective.
>         
>         More precisely, I see the following three cases of interest
>         (with increasing scope):
>         
>         dest ID: FE x,               LFBType: y     addresses all LFBs
>         of type y in FE x
>         dest ID: group FE z,     LFBType: y     addresses all LFBS of
>         type y in the group z of FEs.
>         dest ID: FE broadcast, LFBType: y     addresses all LFBS of
>         type y in all FEs in the NE.
>         
>          [HK] I like this use of the LFB Type ID, this is a good
>         reason for having it in the common header. We had proposed a
>         different approach for addressing LFBs of same type, but this
>         is also fine.
>          
>         regards
>         Hormuzd 

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