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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 29 Apr 2004 00:02:18 -0700

Hi Weiming,

Here is the other part of your email. My previous email has already
addressed most of your questions, see a few more replies below...

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

Leave - This message can be used by an FE or CE to leave an association

[Weiming] As mentioned above, If we decide to use 'Src.ID' and 'Dest.ID'
fields
instead of 'FEid' and 'CEid' field in the header and let FEid and CEid
universally defined, we then only need one message, or else, we may need
'FE
leave' and 'CE leave', two msgs.
[/Weiming]
[HK] See Jamal's email on this, direction is good enough for this. The
only time that we need Src, Dest ID is if we want to allow messages
between Ces (CE-to-CE) messages in the future.

* Capability Control Messages
[HK] I don't think a FE prefix is useful for any of these messages. Not
sure why you keep asking for this ? There is no good technical reason
that I can think of.

Configuration Req/Resp (FE, LFB attributes)

[Weiming]Still prefer '(FE) Configuration message' instead of
'configuration
request message' as the name. Note that here the 'resp' is not always
necessary.
For the contents,it may also include config of LFB topology.
[HK] Response is extremely important for this message. For e.g. Wouldn't
you like to know if the routing table install by a CE was successful or
not on the FE. This is a basic necessity.

* Control Packet or Traffic Maintenance Messages
CP Redirect to CE - This message will contain the packet to be
redirected along with some control information such as the FE Port ID on
which the FE arrived or the LFB ID on which it arrived.
CP Forward to FE - This message also contains the packet along with
control information such as the FE Port ID or LFB ID on which the packet
is to be forwarded.

[Weiming]Actually here I think we may only need to define one message
the
'Packet Redirect msg', leaving addressing body (FEid CEid) to decide the
direction. I don't think the FE port ID or LFB ID here will take effect
for the
FE to correctly get the packet to be redirected. This should highly rely
on the
LFB topology to decide where to induce the packets, e.g., from a
classifier or a
rate limiter (if used for DoS). I suppose that FE model should define a
default
datapath ID, via which packets enter and are encapusulated as a protocol
message. The same is for packets redirected from CE to FE.
[HK] Ok, I am thoroughly confused now. For some messages, you want CE/FE
prefixes (2 messages), here you want a single message ?? ...Port ID or
LFB ID is very important especially for Multicast forwarding & reception
on the FE. 

* Event Notification Messages
Event Register/De-register Req/Resp - This allows the CE to
register/de-register for FE events, LFB events, packets, etc.
Asynchronous FE Event (including FE events such as DoS events, LFB
events, etc)

[Weiming]In my opinion, we truly do not need to use two specific msgs
for event
register/de-register. It can be easily done by 'Configuration' msg. no?
[HK] Different semantics from Configuration, reg/de-reg is a clearer way
to express this.

* State Maintenance Messages or HA related messages
PE Up/Down - These indicate the state of the FE or CE.
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).
Move PrimaryCE - This command is used to change the Primary CE for an
FE.

[Weiming]Firstly, I strongly suggest we devide it into FE and CE. They
are so
different. Then, I think we may only need two messages:

FE maintenance msg (CE->FE)
    -including FE Shutown/Activate/Deactivate/... Note that for FE state
Up/Down
report, I'm with Jamal that they should be FE events.
CE maintenance msg
    -including move operation
To be hornest, I'm still not sure how the CE maintenance msg works, even
not
sure if it is a CE->FE action or FE->CE. Jamal, could you give more
details on
how such as Move action works?
[/Weiming]
[HK] Ok, let me think about this. Seems ok in the first read.

[Weiming]I think here we may have missed something that are so
important. How we
manage the LFB state, that is, how we lunch(mount), activate/deactivate
all the
LFBs? Can they be included in the 'FE Config msg'?
[HK] Yes, this will be part of the Config msg and the specifics for LFBs
will be defined by the Model team. We don't need to be concerned with
this level of detail,

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

[Weiming]We have never had a discussion on how SNMP can be supported
from the
perspective of protocol. Can we have some on it? What I think is just a
case
where the SNMP MO and the SNMP agent are located separately in CE and
FE. E.g.,
if an agent is in CE while the set MO is in FE, how then we deal with
this if we
do not have some protocol message support? A probable way is to define
all MOs
as FE attribute then to use Config msg to do it. But is is possible to
let all
MOs be FE attributes?

[HK] Yes, I think having the Config message take care of this will be
the best approach.

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 29 Apr 2004 17:53:27 +0800

Hi Hormuzd,

Thank you for your advice on the email length. Pls allow me to reply this email
first.

----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>
 Hi Weiming,

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

[Weiming] As mentioned above, If we decide to use 'Src.ID' and 'Dest.ID' fields
instead of 'FEid' and 'CEid' field in the header and let FEid and CEid
universally defined, we then only need one message, or else, we may need 'FE
leave' and 'CE leave', two msgs.
[/Weiming]
[HK] See Jamal's email on this, direction is good enough for this. The
only time that we need Src, Dest ID is if we want to allow messages
between Ces (CE-to-CE) messages in the future.

[Weiming Re] I don't think so. You may know Jamal's approach is different from
pure CEid and FEid in that, the Src ID field can either be CEid and FEid, just
the same as IP address for IP protocol.

* Capability Control Messages
[HK] I don't think a FE prefix is useful for any of these messages. Not
sure why you keep asking for this ? There is no good technical reason
that I can think of.
[Weiming Re] I don't quite like the way you use the word 'keep' here. I think
you shoud be more open to different ideas if you like to first propose something
for discussion. My idea is very clear, for pure single direction msgs, we'd
better to mark the destination, why not? I can also say that there is no good
technical reason not to mark the destination, to let customers to read the
protocol text carefully then to understand the direction. It's just much more
clearer, with little cost.

[Weiming]Still prefer '(FE) Configuration message' instead of 'configuration
request message' as the name. Note that here the 'resp' is not always necessary.
For the contents,it may also include config of LFB topology.
[HK] Response is extremely important for this message. For e.g. Wouldn't
you like to know if the routing table install by a CE was successful or
not on the FE. This is a basic necessity.

[Weiming Re] I'm just a little confused with the 'resp msg' and the 'ACK msg'.
Do you mean we then do not need any ACK msg? I noticed in your previous email
that you may hope FE model can define the command result. Could you take a
example (e.g., add route ) to show what the FE model defined 'command result'
look like? I think in mose cases, we only need to know the echo like
'successful', "unsuccessful', 'reason', 'error code', etc. All this can be
included in a universal ACK msg. ( maybe we need to discuss the ACK msg format
first). One more question is, can customers choose not to ask resp? If can, it
becomes even more like ACK. If not,  I think it may have burdened customers and
system resources quite a lot when sometimes they don't actually need the 'resp'
so as to fast the huge config tasks, e.g., to add hundreds of thousands of
routes.  In this case, we may ask only send back echoes when not successful.

[Weiming]Actually here I think we may only need to define one message the
'Packet Redirect msg', leaving addressing body (FEid CEid) to decide the
direction. I don't think the FE port ID or LFB ID here will take effect for the
FE to correctly get the packet to be redirected. This should highly rely on the
LFB topology to decide where to induce the packets, e.g., from a classifier or a
rate limiter (if used for DoS). I suppose that FE model should define a default
datapath ID, via which packets enter and are encapusulated as a protocol
message. The same is for packets redirected from CE to FE.

[HK] Ok, I am thoroughly confused now. For some messages, you want CE/FE
prefixes (2 messages), here you want a single message ?? ...

[Weiming Re] I'm not sure if you are truly confused or not. Let me just keep
saying it again, for the msgs that can be used in single direction, we should
mark it. For the msgs like  packet redirect msg,  I dont see any difference for
CE->FE and FE->CE, why we should mark it. I have to say you are just
unnecessarily using CE/FE prefix here. Actually the confusion is from your side
to me, why should you use the CE/FE prefix in the unnecessary place while
against using them when they are actually needed?  Pls don't let me have a
feeling that it is because FACT does like this.

Port ID or LFB ID is very important especially for Multicast forwarding &
reception on the FE.
[Weiming Re] Could you give more details on how these PortID and LFBID are used?
What does Port ID here mean? I just can not see every thing here.

[Weiming]In my opinion, we truly do not need to use two specific msgs for event
register/de-register. It can be easily done by 'Configuration' msg. no?
[HK] Different semantics from Configuration, reg/de-reg is a clearer way
to express this.

[Weiming Re] I suppose you also ask a clearer description here. But just the
cost for the 'clearer' here is too much. Pls also don't let me have a feeling
that it is because FACT does like this.

[Weiming]Firstly, I strongly suggest we devide it into FE and CE. They are so
different. Then, I think we may only need two messages:

FE maintenance msg (CE->FE)
    -including FE Shutown/Activate/Deactivate/... Note that for FE state Up/Down
report, I'm with Jamal that they should be FE events.
CE maintenance msg
    -including move operation
To be hornest, I'm still not sure how the CE maintenance msg works, even not
sure if it is a CE->FE action or FE->CE. Jamal, could you give more details on
how such as Move action works?
[/Weiming]
[HK] Ok, let me think about this. Seems ok in the first read.

[Weiming]I think here we may have missed something that are so important. How we
manage the LFB state, that is, how we lunch(mount), activate/deactivate all the
LFBs? Can they be included in the 'FE Config msg'?
[HK] Yes, this will be part of the Config msg and the specifics for LFBs
will be defined by the Model team. We don't need to be concerned with
this level of detail,

[Weiming RE] Not completely agree. At least the protocol level should be
responsible to manange LFB instances.

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

[Weiming]We have never had a discussion on how SNMP can be supported from the
perspective of protocol. Can we have some on it? What I think is just a case
where the SNMP MO and the SNMP agent are located separately in CE and FE. E.g.,
if an agent is in CE while the set MO is in FE, how then we deal with this if we
do not have some protocol message support? A probable way is to define all MOs
as FE attribute then to use Config msg to do it. But is is possible to let all
MOs be FE attributes?

[Weiming Re] Then, we need to define an FE attribute for MO operation? I'm
thinking it further to see the possibility.

Cheers,
Weiming