Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 27 Apr 2004 22:04:55 -0700

Jamal,

Thanks for your comments ! I am fine with most of them, will make
appropriate changes.
Pls see some replies below...

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
> 
> Since the discussion around the HA seems to be coming to a reasonable
> conclusion, 
> I am taking this opportunity to post some text around the Protocol
> Messages (PL level).
> This covers both topic 3 (capability exchange) & 4 a,b.

Non-tech question:
Where are we going with all the txt that so far you are the serial
interface to. From the size of it, it seem inadequate to be going into a
draft. I know sooner or later we are going to start editing xml pieces.
Is this text a lead/summary to that?

[HK] Sure, you can use it as reference, summary or actually use some of
the text if you like (of course, I assume some elaboration will be
needed in some/most cases)

> Couple of comments...I have categorized the messages in a certain way,
> however that is Not important to me at this point. I am fine with
> however, you guys would like to categorize this or Not categorize this
> at all (?) Also, I have tried to incorporate some of the comments that
I
> received from Weiming, Jamal, others.
> 
> Note to Weiming: The reason for not categorizing these messages as "FE
> messages" is so that they can be used by the CEs also in the future. 

I like this. the ID should clearly identify if it is a CE or FE, no?
[HK] Yes IDs can be used for this.

> For
> e.g., the Leave message can be used by the CE also to leave a ForCES
> association with a FE (actually this is a requirement as well but I
wont
> mention the RFC here, don't want to piss off my friend(Jamal) :-)).
> Also, the State messages such as UP/DOWN can be used by CEs also thus
> making the protocol future-proof in a way & simplifying some of the HA
> schemes.
> 
> * Association Setup Messages
> Join Request/Response - The Join Request is used by the FE to join or
> start an association with the CE. The Join Response is sent by the CE
> and indicates whether the Join Request was successful or not. The CE
> also assigns the FE ID to the FE in this message.

I am trying my best not to bring up how we did things in order to
expidite things(as an example, the way HA is being approached is totaly
different from how we did and i hope it makes Ram happy ;->). In some
cases, however, sharing the experience helps.
We implemented slightly differently. The FEM CEM interface provides the
FE its ID. The join/syn/association message could of course be used to
override this ID. Infact, in some of the h/ware we used the FE ID could
be associated by slot and chasis ID(sometimes referd to as geographical
information) which is known to the FE on bootup.

[HK] I am fine with this. If the FE already has an ID assigned (e.g. by
FEM), it should specify that in the Join Request msg. The CE can always
overwrite this value. If an ID has not been assigned for an FE, it
should have value of 0 for FE ID in Join Request, in which case the CE
must assign an ID for the FE. Does that sound good ?

> * State Maintenance Messages or HA related messages

Call them maintainance messages. [Sure]

> PE Up/Down - These indicate the state of the FE or CE.

Sounds like an event to me. [Yes, there is a very subtle difference.
What do others think ? ]

> PE Active/InActive - These are actually commands which can be used by
> the CE to Activate or Inactivate an FE (change its state). By
activating
> an FE, I mean asking it to start forwarding packets. This is a useful
> during initial startup of protocol operations, to take the FE into
> steady state. These commands can also be very useful to handle HA
> scenarios when there are multiple FEs connected to the CE, some are
> active and some are standby (or inactive).

Could you remove "PE" from that? Should probably be activate/deactivate
[Ok]

> Move PrimaryCE - This command is used to change the Primary CE for an
> FE.

Again, probably "move" is sufficient. [Sure]

> TBD...(Not sure if this is needed, may be Config Req/Resp can be used
> for this)
> * Management Object or SNMP support Messages
> MO Get/Set
> MO Response

Not sure of need for this.

> HeartBeat or Keep-alive - This message may Not be needed, depending on
> whether we want this functionality to be provided by the TML

I think there is desire to have heartbeats at PL level. So a hearbeat
message is needed.

[HK] I am fine with this. What does Weiming think ?

> Changes since last post on Protocol Messages...
> Removed - Leave Response
> Removed - Vendor Specific messages
> Added - Move message
> 
> Hope we can get agreement on this basic set, let me know what you guys
> think.

I am a little slow right now, seems like you covered almost everything.

> I will send out a separate email, with some diagrams describing the
> Protocol scenarios showing the different messages.

Hormuzd, can i accuse you of hogging this? ;->
What text can i write? I asked in the other email

[HK] That's the nicest accusation I have heard so far :-)) After the
protocol scenarios, which are mostly diagrams clarifying the messages,
the next topic 4.c. is the Common Header. We had one main issue on Type
ID which needed to be discussed & closed. Feel free to post some text on
that.
Here is the remaining list for your reference,
4.c. Common Header
5. Support for Vendor functions
6. Master-Slave or Peer-to-Peer model

BTW, even though you may not post text on all issues, I find comments
from yourself, Weiming and others very useful...that adds a lot of value
to the text. In most cases, I try to reuse most of the text in your
comments.

regards,
Hormuzd

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 28 Apr 2004 08:01:22 -0400

> needed in some/most cases)

I can see you are doing this out of necessity; progress is slow around
here. 

> must assign an ID for the FE. Does that sound good ?

I know we had some problem with starting with PID 0 in our
implementation.
I will take a look at the code and my notes to see why. Essentially we
eventually went with PID being known preassociation and overriden post
association. In the long run we found no need for overriding.
I will get back on this.

> 6. Master-Slave or Peer-to-Peer model

Wheres the discussion on FEM/CEM? 

> to the text. In most cases, I try to reuse most of the text in your

The problem is people are lined up to write some XML text; however, in
retrospect what you are doing is ok - so continue with the momentum and
on my part i will try to respond ASAP - which should keep the ball
roling faster. I will do something else that is useful when opportunity
presents itself. 

cheers,
jamal