Re: [Forces-protocol] Re: Section 6 update

"Wang,Weiming" <wmwang@mail.hzic.edu.cn> Fri, 22 October 2004 15:43 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14834 for <forces-protocol-web-archive@ietf.org>; Fri, 22 Oct 2004 11:43:08 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1mE-0000gn-UE for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 11:56:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1Td-0002va-JY; Fri, 22 Oct 2004 11:37:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1NO-00018X-ID for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 11:30:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14147 for <forces-protocol@ietf.org>; Fri, 22 Oct 2004 11:30:42 -0400 (EDT)
Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CL1Zz-0000UF-As for forces-protocol@ietf.org; Fri, 22 Oct 2004 11:44:01 -0400
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 23:49:32 +0800 (CST)
Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000085717@mail.gsu.cn>; Fri, 22 Oct 2004 23:25:48 +0800
Message-ID: <10ae01c4b84b$b3991ab0$845c21d2@Necom.hzic.edu.cn>
From: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
To: hadi@znyx.com
References: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408><0fe601c4b816$d55930c0$845c21d2@Necom.hzic.edu.cn><4178D3D1.3080608@zurich.ibm.com><102601c4b824$15a75dc0$845c21d2@Necom.hzic.edu.cn> <1098443159.1112.43.camel@jzny.localdomain>
Subject: Re: [Forces-protocol] Re: Section 6 update
Date: Fri, 22 Oct 2004 23:27:54 +0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 343d06d914165ffd9d590a64755216ca
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong <donglg@mail.hzic.edu.cn>, Robert Haas <rha@zurich.ibm.com>
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57

Hi Jamal, Robert,

----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
Subject: Re: [Forces-protocol] Re: Section 6 update


> Weiming/Robert,
>
> Also dont forget to look at the overview section in the latest draft
> posted by Avri. Theres a little refinement of the split of the two LFBs
> (each in its own section).
> As to what to do about the FE Object and FE Protocol object, My opinion
> is we should define everything taht we think we will need.
> I would think the model team will take those needs and make sure its
> part of the XML spec. Weiming, are you suggesting to do the xml from us?
[Weiming] Yes, but I'm not sure if it should be defined inside this protocol
text or just by another draft. I remember you also mentioned such thought
before. We actually have the same question on Redirect LFBs, anyway any LFB like
things that between FE model and protocol. Now it seems very popular to
summarize everything as LFB, I even think of TML layer as LFBs from PL layer,
but not sure.

cheers,
weiming
>
> cheers,
> jamal
>
> On Fri, 2004-10-22 at 06:44, Wang,Weiming wrote:
> > Hi Robert,
> >         ----- Original Message -----
> >         From: Robert Haas
> >         To: Wang,Weiming
> >         Cc: Khosravi, Hormuzd M ; Ligang Dong ; hadi@znyx.com ;
> >         avri@psg.com ; ram.gopal@nokia.com ; forces-protocol@ietf.org
> >         Sent: Friday, October 22, 2004 5:33 PM
> >         Subject: Re: Section 6 update
> >
> >         Weiming.
> >         I suggest we make a  new section "FE LFB and FE Protocol LFB"
> >         just before Section 5 "Common Header", instead of leaving this
> >         to section 3.3.2.
> >         This will reflect the importance of those two LFBs in the
> >         operation of the protocol.
> >         [Weiming]I'm not objective to this, just a little worry if it
> >         may make the whoel text change too much(some cross references
> >         of section number). What I see more is if we need to add a sub
> >         section to detailedly define the attributes mentioned. Talking
> >         about this, one thing I'm not very sure of your idea is, do
> >         you think these attributes of LFBs (or even the whole LFB
> >         definition ) should be defined by our protocol or by FE model?
> >         I just see that there is some logical problem if it is defined
> >         by FE model.
> >
> >         I'll post my text when ready, please do the same, and we'll
> >         merge.
> >         [Weiming]I think your current version has already done well
> >         and  made good summary on the issue. I'l be more interested in
> >         trying to input something based on your text. To join
> >         in, because as you know this part is one of that I'm most
> >         interested and I hope to have more exchange with you on this
> >         later.  We'v actually implemented such model in our testbed.
> >         Best regards,
> >         Weiming
> >         -Robert
> >
> >         Wang,Weiming wrote:
> >
> >         > Robert,
> >         >
> >         > Don't worry too much about the FE LFB and Protocol LFB, I
> >         > think it can be fit it well in the sections.
> >         >
> >         > Actually I can do something for Protocol LFB and FE LFB if
> >         > you think possible.
> >         >
> >         > Regards,
> >         > Weiming
> >         >
> >         > ----- Original Message -----
> >         >         From: Khosravi, Hormuzd M
> >         >         To: Robert Haas
> >         >         Cc: Ligang Dong ; hadi@znyx.com ; avri@psg.com ;
> >         >         ram.gopal@nokia.com ; Weiming Wang ;
> >         >         forces-protocol@ietf.org
> >         >         Sent: Friday, October 22, 2004 4:35 PM
> >         >         Subject: Section 6 update
> >         >
> >         >
> >         >         Hi Robert, All
> >         >
> >         >
> >         >
> >         >         Here you goI have updated sections 6.1, 6.3, 6.6
> >         >         (remove), 6.7 (same). I have directly used the text
> >         >         that Jamal sent out wherever applicable.
> >         >
> >         >         You can update sections 6.2, 6.4, 6.5 -> however, I
> >         >         would check with Weiming first as courtesy since he
> >         >         is working on these sections.
> >         >
> >         >
> >         >
> >         >         BTW, there were lots of things in the todo list I
> >         >         sent out
> >         >
> >         >
> >         >
> >         >         Header Section - Jamal/Robert/Weiming?
> >         >
> >         >         Protocol LFB - Robert/Others?
> >         >
> >         >         FE LFB - Robert/Others?
> >         >
> >         >         CE LFB - ?
> >         >
> >         >         State Machine for Protocol  Ligang (taken)
> >         >
> >         >
> >         >
> >         >         Will you be working on any of these ??
> >         >
> >         >
> >         >
> >         >         Pls do let us knowI will start working on whatever
> >         >         hasnt been claimed by tomorrow morning my time.
> >         >
> >         >
> >         >
> >         >         Thanks
> >         >
> >         >         Hormuzd
> >         >
> >         >
> >         >
> >         >
> >         >         ____________________________________________________
> >         >
> >         >         From: Robert Haas [mailto:rha@zurich.ibm.com]
> >         >         Sent: Friday, October 22, 2004 12:39 AM
> >         >         To: Khosravi, Hormuzd M
> >         >         Cc: Ligang Dong; hadi@znyx.com; avri@psg.com;
> >         >         ram.gopal@nokia.com; Weiming Wang;
> >         >         forces-protocol@ietf.org
> >         >         Subject: Re: Applying changes to Section 6 (Protocol
> >         >         Messages)
> >         >
> >         >
> >         >
> >         >
> >         >         Hormuzd,
> >         >         Could you please pass the token on section 6
> >         >         together with your latest version so I can start
> >         >         editing it ?
> >         >         Thanks,
> >         >         -Robert
> >         >
> >         >         Khosravi, Hormuzd M wrote:
> >         >
> >         >
> >         >
> >         >         Robert,
> >         >
> >         >
> >         >
> >         >         As I said, your note mostly looks...I have put some
> >         >         more comments below...
> >         >
> >         >         (It would help a lot if you start defining the FE,
Protocol LFBs...)
> >         >
> >         >
> >         >         ____________________________________________________
> >         >
> >         >         From: Robert Haas [mailto:rha@zurich.ibm.com]
> >         >
> >         >
> >         >         All: below is a rough list of changes and pending
> >         >         issues regarding section 6. Please review.
> >         >
> >         >          6.1.1 Association: The CE could obtain the HBI with
> >         >         a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given
> >         >         the new Assoc msg strcutrue, we have to remove HBI
> >         >         from the Assoc Setup msg.  [Agreed, this would be
> >         >         part of ProtocolLFB even if it is in this message]
> >         >
> >         >          6.1.2 How has the srcID=0 case been handled in the
> >         >         interop tests ? Is this really feasible ?  [Yes it
> >         >         worked fine during Interop]
> >         >
> >         >          6.2 Query: coarse FE info (inter/intra-FE topology,
> >         >         etc) goes into the FEProtocolLFB.  [Agreed it would
> >         >         be in some LFB, but not sure which LFB this would be
> >         >         part of...?]
> >         >
> >         >          6.4: Events: coarse CE and FE events go into
> >         >         CE/FEProtocolLFB. Note that for the sake of
> >         >         symmetry, we should introduce a CEProtocolLFB.
> >         >         [Sure, why dont you start defining some of these
> >         >         objects...then we can discuss more in detail]
> >         >
> >         >          6.6 State Maintenance: FE
> >         >         Activate/Deactivate/Shutdown become settable
> >         >         attributes in the FEProtocolLFB.  [Yes, these
> >         >         messages will be part of Events or Config...we need
> >         >         to specify this]
> >         >
> >         >          6.7 HB remains as is.  [Agreed]
> >         >
> >         >         In summary, we have the following operations defined
> >         >         for each message type ( I broke the table into 3
> >         >         parts):
> >         >          [looks good!]
> >         >         OPERATION       APPLICABLE MESSAGE TYPES
> >         >
> >         >                         Assoc-Setup  Assoc-Setup-Resp
> >         >         Assoc-Teardown Heartbeat
> >         >
> >         >         no operations
> >         >         defined
> >         >
> >         >
> >         >                         Query  Query-Resp  Config
> >         >         Config-Resp
> >         >         SET, DEL, UPDATE                     x          x
> >         >         GET               x         x
> >         >         EV_S, EV_U                           x          x
> >         >
> >         >         (for event subscribe/unsubscribe)
> >         >
> >         >
> >         >                         Packet-Redir
> >         >
> >         >         PAYLOAD            x
> >         >
> >         >
> >         >                         Event-Notif  Event-Notif-Resp
> >         >         EVENT              x                x
> >         >
> >         >         Note that for Query(-Resp), Packet-Redir, and
> >         >         Event-Notif(-Resp), we have each time only one
> >         >         operation. Looks a bit redundant. Ideas ?  [These
> >         >         are all very different, lets leave them as is, its
> >         >         not necessary to have multiple operations in all
> >         >         messages]
> >         >
> >         >         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
> >
> >
> >         --
> >         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
> >
> >
> > ______________________________________________________________________
> >
> > _______________________________________________
> > Forces-protocol mailing list
> > Forces-protocol@ietf.org
> > https://www1.ietf.org/mailman/listinfo/forces-protocol
>
>


--------------------------------------------------------------------------------


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



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