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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 3 May 2004 14:04:35 -0700

Jamal,

-----Original Message-----

> > 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 problem with standadrd sniffers is they need something to latch on
to decide what the packet is. Clearly it is easy to tell the packets is
a forces PL message. Next is you need to tell if it is from a CE or FE
and whether it is going to a CE or FE.
Ok, actually, this may lead back to what Weiming was saying maybe we
should allocate the addressing such that we can tell that the packet is 
for one of those two. Example (I think this has been suggested before),
we could have the most significant bit of the ID being set implying the
address belongs to the CE.
[HK - Sure we can do this]

Speaking of which we need to discuss the addressing schemes now (eg
broadcast to all FEs, all CEs, subset etc).
[HK] We can directly come up with some standard nos for this, when we
are writing the text for Common Header section in the draft.

On the content of the message: tcpdump should be able to decode based
on the header if i am not mistaken. But we havent discussed the layout
of the message content closely since last time. 
[HK] The basic idea is the same, Common header followed by TLVs. I'll
start defining the ones needed for the different protocol messages.

> [HK] We had similar flags/approach for batching/atomicity. The one
> question that I have is if this is something which will be needed for
> all messages or only for Config message ? 

Config messages is all i see rigth now. [Agree, I see the same]

> If you think we need
> Batching/Atomicity for all messages then we need these Flags in the
> common header, otherwise we can just have it in the Config message.
What
> do you think ?

The problem is i am not sure if it would be worth to say flags x only
apply to messages of type y. I am indifferent.

[HK] So is it fine with you if we define these Flags only as part of the
Config message rather than the Common header ? It seems like you're
saying yes, but I would like to confirm.

Thanks
Hormuzd

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 03 May 2004 21:32:33 -0400

> start defining the ones needed for the different protocol messages.

If you put this together please reference the discussion we already had
back when. This should would save time.

> saying yes, but I would like to confirm.

If you are asking this so you can get rid of the flags from the common
header, then i would say i dont wanna take that risk. I have a feeling i
misunderstood your intention.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Tue, 04 May 2004 16:54:53 +0200

Hormuzd, Jamal,
See my clarifications below.

>[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.

Regards,

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha