Subject: RE: [Forces-protocol] issue 1: packet encoding

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 7 Mar 2004 23:13:16 -0800

-----Original Message-----
On Behalf Of Jamal Hadi Salim

> Here are my views on this issue, particularly the common header:
> 
> Command: Agree this is needed. We think 8-12 bits will be more than
> sufficient for this depending on whether it is subdivided. We have
> sub-divided this field into Class/type...this is an OO approach,
seemed
> pretty neat. However, I am personally fine with having a single field
> for this, no problem with that.

I think we could resolve this later; i am not seeing a lot of commands.
On the outset i can only see ADD/DEL/GET

[HK] Ok, we can resolve this later. So I guess you are fine with 8 bits
for the command? especially, if you only see a few of them.

> Flags/Priority: We need 2-3 bits for priority in every message. I
don't
> think we need any other flags in all messages.

How do you propose we do things like 2 phase commits; atomic
transactions etc?

[HK] You need flags for this, however this is only for configuration
messages, they don't have to be in the common header. They will be part
of the config message TLV. As you said below...
"Agreed - the main thing is that if something needs to be used in all
messages then it should go on this header (since its cheaper than a
TLV)."

Also in regards to priority; do you see this being used all the time?

[HK] Sure, this is definitely needed in all messages. I believe even
GRMP has this, infact I had a feeling till today that even netlink had
it.

and would an underlying transport priority be insufficient
(example diffserv, 802.1p etc)?

[HK] This is priority at the ForCES level which will eventually be
mapped to the underlying transport/interconnect. We definitely need it
at the ForCES level as well.

> Typeid: This is one field I don't think is needed in all messages. I
am
> not sure why this is needed at all cause, we will be using the Model
and
> LFB IDs to address processing functional blocks on the FEs.

I am not sure i see this. If you could explain more mayeb it would help.
Like i said the only value is in being able to look at the outer header
and recognizing for example the target where the message is being sent
to (example LFB class). If not for anything else, debugging (via
sniffing) is a good reason - this way i could dump the rest of the
message by recognizing what the TLVs mean.

[HK] Debugging doesn't seem to be a good reason to me to add a field to
the common header. It has to be something very useful for the protocol
and all messages. What do others think about this one?

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Mar 2004 08:30:42 -0500

> for the command? especially, if you only see a few of them.

I am indifferent 8 bits may be sufficient; lets consider this one closed
and revisit it later.

> messages then it should go on this header (since its cheaper than a

I think we shouldnt hurry into getting rid of flags. They are used in
all transaction type protocols i have come across. We used them
extensively in _every_ message. 
16 bit flags should suffice. If we are not in agreement i could go into
semantics;

> at the ForCES level as well.

Ok - closed. So how many bits do you see?

> and all messages. What do others think about this one?

I gave debugging as an example - and btw, it is a _very_ good reason
to be able to debug protocols.
The general idea is by inspecting the header i want to be able to tell
what class of LFB it is going or coming from.
If you can look at my earlier diagrams and tell me how you could see me
decoding that message and identifying that LFB10 is a IPV4 forwarder
then we could move on.

cheers,
jamal

---

From: "Sandy Pavel" <[email-masked]>
Date: Mon, 8 Mar 2004 10:43:21 -0500

On the justification for a Priority field:

As far as I can tell this protocol is not "routable" based
On addressing scheme specified in its header.

I therefore believe that priority processing is a function of the lower
Level transport protocol. This is true even if the transport protocol
used
Is a L2 protocol.

There should be a single point where the ForCES protocol messages are
mapped
To lower level transport protocol. And this is the point where the
priority
Should be specified.

Regards,
Sandy 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Khosravi, Hormuzd M
Sent: March 8, 2004 2:13 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Forces-protocol] issue 1: packet encoding

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

seemed

don't

am
and