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

On Sat, 2004-03-06 at 17:37, Khosravi, Hormuzd M wrote:
> Jamal,
> 
> Before I give my comments, I would like to say that I appreciate the
> fact that you did not copy/paste the netlink header from your draft over
> here! That is a very positive sign to me, lets try to stick to the best
> technical solution rather than pushing our own protocol implementations.
> That's the best way to make progress on this merger!!

We actually have learnt a few things while implementing ;->
The thinking right now is to learn from mistakes (and from good things
of course).

> 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

> Sequence No: Agree needed and agree with size.
> 
> 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?
Maybe what you called "class" in the command is a flag then?
Also in regards to priority; do you see this being used all the time?
and would an underlying transport priority be insufficient
(example diffserv, 802.1p etc)?

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

> Missing field: Version (2-4 bits): This is present in all protocols, and
> is generally included in most IETF protocols. Its usually the 1st field.

Agreed. 4 bits is what i have seen normally.

> General comment: Lets try to be stingy on the size of the header and its
> fields since this will be included in all ForCES messages.

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

cheers,
jamal

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol