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

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

Avri,

Glad to have you back! As I said in my previous reply to Jamal, I am
fine with this (below) as well. I think any special nos. etc which are
needed for addressing can directly be defined by the person writing the
section on Common header and we can all review that, once its done.

Couple of questions...
In your previous email, you had sent a .txt file for the draft. Is there
also some XML file which we need to use first to write the draft, which
later gets converted to a .txt file ?

Did you want to post any other thoughts that you have on peer-to-peer
model (topic 6), or do you think we already covered this topic in our
protocol messages discussion ?

Thanks
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]

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

I definitely agree with this proposal.  When Weiming first sent it out 
I was trying to form an argument in its favor, then I went invisible 
for a variety of personal reasons (surgery of a family member), plus 
travel.

I think it also adds extensibility to the protocol over time.

a.

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

---

From: [email-masked]
Date: Tue, 4 May 2004 08:56:17 +0200

HI,

> section on Common header and we can all review that, once its done.

Seems a reasonable approach.

> later gets converted to a .txt file ?

Yes, there is a set of XML files, one for each section, and I can break 
it down smaller if folks want.  I can send those out, but I was waiting 
for the CVS setup so that they could be started there.

And yes, we then put all the xml sections through the xml2rfc tcl 
script to get the txt output.

As I said, I am willing to play the role of assembling the doc from the 
various xml sections people write, icnluding debugging the xml 
formatting as needed.

Unless someone wants to assign me a section to author, I would prefer 
to keep myself in a neutral copy-editor role so that I can't be seen as 
preferring my words over anyone else's. But if there is something that 
someone wants written I can.  I can certainly take care of sections 
like abstract, maybe an introduction, references, etc.

> protocol messages discussion ?

I think we are actually subsuming it into the other discussions.  In 
brief, in pure master-slave model, the FE would only respond when 
requested to do so, with the exception of alarms etc..  As we progress 
toward a peer-peer model, each of the peers has its role and can 
initiate a transaction depending on its own needs.

As time goes on, and FE hierarchy and FE-FE communications become a 
reality, then I can envision occasions where the FE would notify the CE 
of changes in the FE set that are initiated by the FE based on some 
policy or other.  I am also envisioning that there will be cases, 
though not 'permitted' where an FE will be directly manipulated by some 
process or operator other then the CE, where the FE will notify the CE 
of changed state or function.  And while this is not currently an item 
for discussion, I can see the FE as being instrumental in the neighbor 
discovery process (I tend to divide routing into 3 not 2 sub-processes)

a.

ps. in terms of timing, I will be spending May in Sweden, so my 
response times will be skewed by that.

---

From: "Weiming Wang" <[email-masked]>
Date: Tue, 4 May 2004 19:15:01 +0800

Hi All,

Sorry be off  for a few days owing to a holiday in China.

Firstly,  on the msg direction indicator in the header, I actually originally
have two thoughts for it.  One is to define CE id and FE id in a different
space, that is, e.g., using a bit in the space head (mst significent bit) to
mark the different space, another is to  put the 1 bit flag along with the
transaction ID, that is, by viewing the ID we then know where the msg is
generated. One more advantage for latter approach is it may supply some extra
information for FE or CE to trace the transactions,  and may be of some help to
sth like transaction atomicity?

Seems we begin to discuss how the writing task is to be assigned.  Hornestly, my
team ( I and Ligang) more prefer to take the task of protocol msg and common
header writhing, because we think we may be more fit for sth more technique
instead of beautiful literature oriented, .  Actually protocol msg is a big
task, I just suggest we assign the 6 msgs to two individuals (1st 3, and last 3)
for draft starter writing.  For common header, if Jamal is interested, I would
like to have a close co-work with you for this part.  I may also write the
definition part, for it seems mostly copy work. I hightly suggest  Avri write
the introduction as well as acknowledge and ref, and I also highly suggest Jamal
you write the TML requirement part, because I think you may have a more
understanding of this than us (at least me) anyway.

I also agree to continue our discussion on the remained issue even when we have
parallelly begun the writing.

Sincerely,
Weiming

----- Original Message -----
From: <[email-masked]>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 04 May 2004 08:51:42 -0400

> for the CVS setup so that they could be started there.

Is there any point in CVS anymore if you are going to be the central
authority puttin these together. If the answer is we still need CVS i
will put effort in getting us a server somewhere.
In regards to you writting a section, i think thats your prerogative.
You already play a valuable role putting things together.

The rest of your emails a separate subject - will split into another
mail.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 04 May 2004 09:05:14 -0400

On Tue, 2004-05-04 at 02:56, [email-masked] wrote:

> of changed state or function.  

Very good point which i was unable to adequately express in my email on
the desire to have a config message from FE->*
I dont think we can avoid the fact that events will be at times (not
always) mapped to config messages. 

On Tue, 2004-05-04 at 05:49, [email-masked] wrote:
> Even in the peering, or semi-peer, model there may be messages that 
> only make sense when coming from one type of peer or the other.  So 
> certainly a cfg message of the type - set this as your config only 
> makes sense coming from the CE.  But a config message that says my 
> config has been changed by a third party could come from the FE and 
> will probably look a lot like a 'set this config' message.

To reuse what i stated earlier:
---
Config CE->FE message of "update table X (for LFB Y) with config Z" 
could be reused from FE->CE to say
"table X (on LFB Y) was updated with config X".  
---

I think we should consider this semantic

> And while this is not currently an item 

Can you explain a little more on this?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 04 May 2004 09:17:08 -0400

> Sorry be off  for a few days owing to a holiday in China.

How come we dont get as many holidays here? ;->
I just heard of the concept of golden week in Japan and i know
Scandanavians (where Avri is to be found lately) has i think a whole
month off for holidays/vacation;->

> sth like transaction atomicity?

I am worried of making this too complex. Is this how GRMP did it?
I explained how we did atomicity and batching and atomic transactions in
netlink2; why dont we hear from you and Hormuzd on how you did it and
see if we can pick something agreeable to all.

I am gonna split your email here since the other is a unrelated topic.

Something else we havent talked about in the header.
The response part. I see two types of responses (gaian based on netlink2
experience):

1) Positive reply.
This would probably be the same message as the config with ACK flag
turned on.

2) Negative reply
In our case we had a speacial command for this. It contained the result
code and the old header cutnpasted back so you can identify which
message has an error.

I think we need to have both types of responses allowed. I noticed a few
other protocols are defining this sort of responses lately.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 04 May 2004 09:26:24 -0400

Hi Weiming,

On Tue, 2004-05-04 at 07:15, Weiming Wang wrote:

> definition part, for it seems mostly copy work.

Weiming, come on now, i discovered (like columbus did) the common header
section ;->
Ok, you can take that - i will take section 3 and 4.

>  I hightly suggest  Avri write

Sounds like Avri has been volunteered ;->

cheers,
jamal

---

From: [email-masked]
Date: Tue, 4 May 2004 16:15:20 +0200

On 4 maj 2004, at 14.51, Jamal Hadi Salim wrote:

> authority puttin these together.

perhaps not.  though i will probably use it on my system in any case 
just to make sure i can keep history.

a.

---

From: "Weiming Wang" <[email-masked]>
Date: Tue, 4 May 2004 23:52:18 +0800

Jamal,

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
> month off for holidays/vacation;->
[Weiming]That's easy. Just put two weekends together so that we can go far away
and spend more money, then the economy goes up. :)

> I am worried of making this too complex. Is this how GRMP did it?
[Weiming]Maybe it has very little to do with atomicity (after I read Netlink2
again). Actually it was very important in GRMP because GRMP used it as a signal
to indicate if it is a ACK or Response message. GRMP defined the ACK and
Response msgs that they had the same transaction ID as the msg they responsed.
Speaking of this, I agree with you that we need to see the transaction
definition more carefully. For instance, we need to decide what does one
trasaction (with same tran. ID) mean? Can we treat a config msg and its response
msg as in the same transaction?  How about ACK msg then? (may have two ACKs
here, ACK to config msg and ACK to config response msg) My idea more tends to
treat all them as in one transaction therefore they all have the same tran.ID.

> see if we can pick something agreeable to all.
[Weiming]As well as above, we took an 'I'flag and a 'submsg number' field (as
GSMP) in the message header for msg fragments. This 'I' flag is quite the same
as the '_MULTI' flag in Netlink2. The 'submsg number' may be useful for some
transport layer that does not provide reordering back.

> other protocols are defining this sort of responses lately.
[Weiming]I agree. Actually we need to discuss the ACK msg now. Hornestly, I'm
now with a little confusion between the 'ACK' and the 'response', their
definitions, scope,and differences.

---

From: "Weiming Wang" <[email-masked]>
Date: Wed, 5 May 2004 01:01:24 +0800

Hi Jamal,

----- Original Message -----
> Ok, you can take that - i will take section 3 and 4.
[Weiming]Thank you very much. I'l do my best. :)
> Sounds like Avri has been volunteered ;->
Cheers,
Weiming

---

From: Robert Haas <[email-masked]>
Date: Tue, 04 May 2004 19:48:44 +0200

Weiming, and all,

>sth like transaction atomicity?
Frankly, I can't see how adding a flag in the message to indicate its 
direction (i.e., FE to CE, or CE to FE, and later maybe CE to CE and FE 
to FE ?) adds further information to help tracing transactions. Please 
explain. For simplicity I'd rather stick to the usual IP header 
semantics with a dst field and a src field.

Splitting the ID address space in two equal subspaces (which would be 
the case if we choose the MSB of the ID to distinguish among CE and FE 
ID) would be an overkill for CE space. I guesstimate the ratio of FEs vs 
CEs in an NE to be in the order of 100 to 1000.

Who has a proposal how to best split the address space ?

Regards,
-Robert

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 04 May 2004 22:57:57 -0400

> transport layer that does not provide reordering back.

Can we assume the TML will take care of ordering as well as
fragmentation issues? I think the idea of "more messages coming" is
useful per transaction - so i am not against it - but a single bit flag
should do it or maybe two: Start of Transaction (SoT) and End of
Transaction (EoT) to steal from DMA view of the world with SOP and EOP.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 5 May 2004 10:55:58 +0800

Roboert,

Pls see comments inline.
  ----- Original Message ----- 
  From: Robert Haas 
  To: Weiming Wang 
  Cc: [email-masked] 
  Sent: Wednesday, May 05, 2004 1:48 AM
  Subject: Re: [Forces-protocol] topic 4c: Common Header

  Weiming, and all,

  Weiming Wang wrote:

Hi All,

  Frankly, I can't see how adding a flag in the message to indicate its direction (i.e., FE to CE, or CE to FE, and later maybe CE to CE and FE to FE ?) adds further information to help tracing transactions. Please explain. For simplicity I'd rather stick to the usual IP header semantics with a dst field and a src field.

  [Weiming] Actually, two items in my thoughts. One is for address spacing for SrcID and DstID, the other is for transaction ID. I agree the former has little to do with transaction tracing, the latter may have. Just as I mentioned in my earlier email, especially when we treat e.g. a 'config - response' as one transaction. I'm now also trying to check wether a response (or ACK) will have ambiguous meaning or not. 

  Splitting the ID address space in two equal subspaces (which would be the case if we choose the MSB of the ID to distinguish among CE and FE ID) would be an overkill for CE space. I guesstimate the ratio of FEs vs CEs in an NE to be in the order of 100 to 1000.

  [Weiming] To equally split the space is only one scheme. I definitely agree with you to more generally assign the space, just like IP address did. How about let's do it when we compose the text?

  Regards,
  -Robert

  Cheers,
  Weiming

Sincerely,
Weiming

----- Original Message -----
From: <[email-masked]>

HI,

Avri,

Couple of questions...
In your previous email, you had sent a .txt file for the draft. Is
there
also some XML file which we need to use first to write the draft, which
later gets converted to a .txt file ?

      

a.