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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 10 Mar 2004 00:20:52 -0800

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
> 
> [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.

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

[HK] Closed for now, but I have the same views as Weiming on this, we
need more commands.

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

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;

[HK] We can reserve 16 bits for now (including 3 bits for priority, see
below) and close this temporary. However we will have to revisit this to
see if we agree on the semantics and if they will be useful for all
messages. FACT and GRMP both don't have flags for transactional
semantics in the common header, so this is definitely something which
can go in the TLVs.

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

Ok - closed. So how many bits do you see?
[HK] 3 bits max. Let this be part of flags for now.

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

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.

[HK] I see limited value of this. How would it work if a single message
were being addressed to multiple LFBs (command bundling)? I believe that
we should separate LFB ID from FE ID and it should be part of TLVs
rather than common header. See my email on issue 0. Does having LFB IDs
as part of TLVs rather than common header break something ?

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Mar 2004 07:11:43 -0500

> as part of TLVs rather than common header break something ?

I believe this issue will be resolved once we resolve issue 0.
Note also Weiming and I had a discussion on the batching issue which
we can go into later.
LFB identification belongs to the message body, not the header. The idea
of the type is to ID the message which i believe is important not
just for debuggability.
I described a rx packet walk to David repeated here for clarity.

------
1) FEd receives message. Based on dst PID sends it to the right location
(an app like FEC for example) or consumes it.
2) FEC validates that it can process that message and understands the
LFB class (based on type) and what LFB/LFBs to muck with. 
3) The decoded TLVs further reference entities
within an LFB class i.e an LFB class essentially owns multiple instances
of that LFB type. FEC now configures LFB.

Now of course you could take the LFB instances such as an
index of a nh table and give that a NE-universal id; but that would
require a huge address space (maybe 128 bits may be insufficient).

Collision resolution can be discussed later; i can explain how we did it
but it is not going to add much value.
--------

Lets put issue 1 to rest.

cheers,
jamal