2006 Message-Id: Date: Thu, 26 Jan 2006 16:15:39 +0800 From: "Wang,Weiming" Subject: Re: [issue80] LFBClassIDs for Protocol Draft The draft 06 has fixed the problem along with the model team work. This issue is closed as accepted. Thank Evangelos. Weiming ehalep@ee.upatras.gr wrote: This is an editorial comment for the protocol draft. In Appendix B of the Protocol draft in page 80 an FE LFB is mentioned. It should be changed to FE Object LFB Also, in the Protocol Draft the FE Protocol LFB is assigned to value 0x01, and the FE Object LFB is assigned to value 0x02. In the Model Draft the FE Object LFB is assigned to value 0x01. In two tracker issues, i will insert reference of the LFBClassID values of the two LFBs. ------------- References to LFBClassID values for FE Protocol LFB and FE Object LFB: Page 43: The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The FE Protocol LFB Class ID is assigned the value 0x1. Page 80: 0x00000000 Reserved 0x00000001 FE Protocol LFB 0x00000002 FE LFB Page 84: (Must be changed by now to) FEPO". 2006 Message-Id: Date: Thu, 26 Jan 2006 16:02:59 +0800 From: "Wang,Weiming" Subject: Re: [issue75] More nits - Section 6.9 to appendix C Avri, In Section 7.9, the message header paragraph, after the sentense "When not soliciting for response(default behavior), the ACK flag is set to 'NoACK'", a full stop mark is missed. Eeditorial nits have been well repaired by sampling check. This issue can be closed after above small nit is fixed. Thank Ellen. Weiming Allen wrote: 6.9 (Message Header) Does the ACK flag have to be set to either 'NoACK' or 'AlwaysACK'? If so, the sentence should read: "The ACK flag in the header MUST be set to either 'NoACK' or 'AlwaysACK' when the HB is sent." "Correlator field can be ignored" is too vague. 7.1 /association have/ --> /associations have/ /it by enabling the FE/ --> /it enables the FE/ 7.2 /Figure below helps/ --> /The figure below helps/ 8. (1st paragraph) /there can only be one Primary CE controlling the FEs and there/ --> /only one Primary CE can control the FEs, but there/ (2nd paragraph) /There are 2 modes of HA defined/ --> /Two HA modes are defined/ 8.1. (PL Level:) /All the other/ --> /For all the other/ 9. (1st bullet) /Security mechanism/ --> /Security mechanisms/ /controlled that is/ --> /controlled. That is,/ (2nd bullet) /uniform operations/ --> /uniform operation/ (3rd bullet) /pre-established/ --> /pre-establish/ /reduce the security/ --> /reduce the number of security messages exchanged/ 9.1 (1st para) /When No security/ --> /When "No security"/ /needs be performed/ --> /needs to be performed/ /within an single/ --> /within a single/ 9.1.1. /PL layer maintain set of association list/ --> /PL layer maintains a set of association lists/ /FE MSUT connect/ --> /An FE MUST connect/ /similarly CE should/ --> /similarly, a CE should/ 10. /Allan DeKok/ --> /Alan DeKok/ B.4. /TheLFB/ --> /The LFB/ /iws/ --> /is/ B.5 Every instance of Response is misspelled as "Repsonse" (also Responses as "Repsonses") C. I didn't look at the XML carefully, but noticed that the RFC references need to be resolved, currently they are "XXXX". 2006 Message-Id: Date: Thu, 26 Jan 2006 13:04:20 +0800 From: "Wang,Weiming" Subject: Re: [issue74]Protocol comment The issue is closed because it is included in issue68.Thanks,WeimingHi Ellen, Thanks for pointing out this. It seems also a prominent question, for David mentioned this either (issue68). My view is it may provide more freedom if we define it as the sender can ignore it. For instance for Query message, the sender will always want a response, therefore, the coder may be more incline to set the ACK flag to 'AlwaysACK'. If we define Sender MUST set the ignored field to zero, the just mentioned case will then have to be treated as an message error by the receiver. I hope other protocol authors can give some comments on this, and we decide it quickly, then I can update the text accordingly. Thanks, WeimingEllen wrote:In cases where fields are ignored, it should be more explicit which side (sender or recipient) ignores the field. Also, most protocols that I've seen require the recipient to ignore the field (receiver MUST ignore), and the Sender MUST set the field to zero. (HW engineers want to have a fixed value, even if the other side ignores the field.) 2006 Message-Id: Date: Thu, 26 Jan 2006 12:46:39 +0800 From: "Wang,Weiming" Subject: Re: [issue73] Protocol draft - editorial nits up to section 6.8 Double checked by sampling the updated, quite sure that this editorial issue can be closed.So, closed as accepted.Thank EllenWeiming> Ellen wrote:General comment - running a spell checker would be helpful, it would probably catch most of the misspelled words found throughout the document. Also, there are a lot of places where articles (the, a, an) are missing, particularly before FE and CE (too many to list) that would make the text flow better - but this is really a nit. 2. Definitions Post-Association Phase - /FE does know/ --> /FE knows/ 3.1.1 /LFB'ss/ --> /LFB's/ 3.2 /looses/ --> /loses/ 3.3.1.1.1. /maybe/ --> /may be/ 3.3.1.1.2. /maybe/ --> /may be/ and /dissallowed/ -->/disallowed/ 3.3.1.1.5. /In which several/ --> /Several/ 3.3.1.1.6. /In which all/ --> /All/ 3.3.1.1.7. /the first one are/ --> /the first one is/ 3.3.2. /Heartbeating/ --> /Heartbeat/ 4. (item 8) /the TML only support/ --> /the TML only supports/ 5.1. (item c, 2nd bullet) /donot/ --> /do not/ 5.1. (Correlator) /ForCES Requests/ --> /Forces Request messages/ /Fe/ --> /FE/ 5.1. (Flags) /inidcate/ --> /indicate/ 6.2.1 /gramar/ --> /grammar/ 6.1.1.1. /a substantial amount of/ --> /a substantial number of/ 6.1.1.1.1. (4th bullet) /refered/ --> /referred/ (should probably spell out OTOH) 6.1.1.1.6. Is Idefined correct? /can not/ --> /cannot/ 6.1.1.1.8. /alignement/ --> /alignment/ /layout/ --> /lay out/ /element ordered in the order/ --> /element in the order/ /In the case of a SPARSEDATA we dont need to order/ --> /SPARSEDATA does not need to be ordered/ /For a GET responses/ --> /For a GET response/ /deleteing/ --> /deleting/ 6.1.1.1.9. /definitions as that was/ --> /definitions as/ /possible that one would/ --> /possible to/ /the GET-RESPONSE, merely editing the T to be set will endup overwritting/ --> /the GET-RESPONSE that merely edits the T to be set will end up overwriting/ 6.2.1 /used for the operation/ --> /used for correct operation/ (FE heartbeat policy) /define the operating/ --> /defines the operating/ /liveliness/ --> /liveness/ (FE restart policy) /pre-association phase definitely/ remove "definitely" /FE itself decides/ --> /FE decides/ /FE still keeps enough infomation of/ --> /FE is able to keep enough information from the/ /post-associatin/ --> /post-association/ (CE failover policy) /This basically makes the FE/ --> /This basically requires the FE/ (CE timeout interval) /message body optionally consist/ --> /message body optionally consists/ The statement that starts: "There is only one FE object LFB..." is inconsistent with previous text and redundant. This text could be removed without losing any information. Other sections led me to believe the instance ID must be set to 0x1 for the FE object and FE protocol LFBs. /notificationis/ --> /notification is/ 6.4.2 (Message Header) /more response/ --> /more responses/ /header MUST keep/ --> /header MUST be/ /association setup message to be responded/ --> /corresponding association setup message/ (Message body) /follows: is:/ --> /follows:/ 6.4.3 (Message Header) "correlator field in the header is also ignored owing to no further response requested" (even though the correlator field is ignored by the message recipient, in most protocol specs, it is usually a requirement that the sender set such fields to zero and the field MUST be ignored by the receiver) e.g. "the ACK flag and Correlator MUST be ignored by the message recipient". 6.5.1 (Message Header) /inidcate/ --> /indicate/ /or to indicate in which case/ --> /or to indicate under which conditions/ 6.5.2 (Message body) /TThe/ --> /The/ 6.6.1 /As usual, a query/ --> /A query/ 6.6.2 (Message Header) /MUST keep/ --> /MUST be/ /query message to be responded/ --> /associated query message/ 6.7. /All events happen in FE are subscribable by CE/ --> /All events that can happen in an FE are subscribable by the CE/ (Message Header) /MUST be ignored/ --> /MUST be ignored by the CE/ (Same comment as in the previous section, the CE MUST also ignore the correlator field in this case) 6.8 /usually happen/ --> /usually happens/ /CE and are decided by CE/ --> /CE that the CE decides/ /making the redirect path been congested/ --> /resulting in the redirect path becoming congested/ (Message Body) /describes the packet/ --> /describes packet redirection/ 2006 Message-Id: Date: Thu, 26 Jan 2006 11:14:24 +0800 From: "Wang,Weiming" Subject: Re: [issue67] TML requirements vagueness A standardized interface between PL and TML is essential for the separation of PL from TML, or it makes no sense for the separation. I suggest to change it to MUST and close the issue then if no objection. thanks, Weiming > David wrote: > 3.1.2 The TML Layer > * s/layer is essentially responsible for transport of/layer transports/ > ** There is a "should" in here ("All ForCES Protocol Layer > implementations > should be portable across all TMLs"). From the context, it feels like > Is should be a MUST. Which is it? If it is only a SHOULD, explain > why. [Jamal responded] Well, if we are going to define the service primitives then its a MUST; else it is a SHOULD. 2006 Message-Id: Date: Thu, 26 Jan 2006 11:13:45 +0800 From: "Wang,Weiming" Subject: Re: [issue66] Normative dependency on model (not clear)? Then, I suggest just to change the reference of FE- model to informative and noted with work in progress, and keep the original reference text. Note that because the protocol and the model are inter-referenced, theoretically, there must be an informative one in between. I suppose we can close the issue after some change. thanks, weiming ----- Original Message ----- From: "Avri Doria" > I agree. the linkage should remain. > > a. > > On 25 jan 2006, at 06.07, Joel M. Halpern wrote: > > > The reason for referencing the model document for the definitions > > is that any time things occur in two places (like these > > definitions) it is a good idea to be clear as to which one is the > > actual definition. (After all, the text can be different.) > > Here, our intent is that the model document defines what an LFB is, > > and what an LFB Class is, etc. > > So it is a good idea to say that. > > > > Yours, > > Joel > > > > At 02:03 AM 1/25/2006, Wang,Weiming wrote: > >> After some work, I think some model terminology related to > >> protocol like the > >> LFB, LFB instance, LFB metadata have all been included in the > >> protocol > >> definition section, therefore I don't think we need the sentence in > >> definition section on refering to model anymore, i.e., to change > >> the text: > >> > >> 3. Definitions > >> This document follows the terminology defined by the ForCES > >> Requirements in [RFC3654] and by the ForCES framework in > >> [RFC3746]. > >> This document also uses the terminology defined by ForCES the FE > >> model in [FE-MODEL]. The definitons below are repeated below for > >> clarity. > >> > >> to: > >> > >> 3. Definitions > >> This document follows the terminology defined by the ForCES > >> Requirements in [RFC3654] and by the ForCES framework in > >> [RFC3746]. > >> Some definitons below are repeated for clarity. > > 2006 Message-Id: Date: Wed, 25 Jan 2006 15:03:50 +0800 From: "Wang,Weiming" Subject: Re: [issue66] Normative dependency on model (not clear)? After some work, I think some model terminology related to protocol like the LFB, LFB instance, LFB metadata have all been included in the protocol definition section, therefore I don't think we need the sentence in definition section on refering to model anymore, i.e., to change the text: 3. Definitions This document follows the terminology defined by the ForCES Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. This document also uses the terminology defined by ForCES the FE model in [FE-MODEL]. The definitons below are repeated below for clarity. to: 3. Definitions This document follows the terminology defined by the ForCES Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. Some definitons below are repeated for clarity. In Page 10, remove the following sentence: The following terms are defined by this document: Please comments on the above change,and this issue is to be closed in one week. Thanks, Weiming > David Says: In the definitions section of the ForCES protocol, there is a reference to the model draft. The reference to the model seems normative to me. Is this the case? Jamal replied: "I dont think so - Joel? The dependency on the model at the moment rests with the FEO; which we may end removing." Solutions can be: * Clarify that this is informative * Bring the definitions into this doc * Make it normative, then both docs required to become RFCs 2006 Message-Id: Date: Wed, 25 Jan 2006 14:54:03 +0200 From: Evangelos Haleplidis Subject: Protocol draft 06 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-7 Content-Transfer-Encoding: 8bit Greetings to the list, I was reading the protocol draft-06, and i have some comments/questions/editorials. Regards, Evangelos Haleplidis ====================== Comments ----------- Page 48, Correlator in the Assoc. Setup message If I have understood correctly, the Correlator field is opaque to the FE. Meaning that it does not mean anything to the FE. In the association setup in page 48 in the draft-06 it is written: "The Correlator field in the header is set, so that FE can correlate the response coming back from CE correctly." Since the association setup message originates from the FE it should leave value 0 to the correlator and not insert a value. Is it an exception to the rule, or something I have not understood correctly? ----------- Page 38-39/42-44 Picture/Appendix-D. SET Operation Type In the document the SET operation type is defined simply as SET and is assigned the value of 0x0001 in Appendix-1. However later in the document (Pages 42-44) and in Appendix-D there is an operation called SET-REPLACE and SET-CREATE which is not specifically defined in the document. Do these two operations still exist? There is the DEL command, why not have also a CREATE command? If I understand correctly from the text in page 39: "Note that if a SET request with a structure in a FULLDATA is issued, and some field in the structure is invalid..." that SET does not create. Is it correct? What does invalid mean exactly? ----------- Page 50. About the FE requesting ID from the CE. What happens if two FEs request ID from the CE the same time. How can the CE make the distinction. Which FE should it associate with? How to send the association message correctly? How can the TML make the distinction based on the ForCES message? Which FE is associated and which not? Also the FE-ID is read-only. Even with the association setup-response, isn't it a write-attempt? Or is it considered a setup? Is the read-only attribute valid on the UP state? Proposal-1: Remove the feature. The manager(s) should have already set-up the IDs Proposal-2: Make the FE-ID read-write. As it is now, read-only the setting-up of the ID is contradictory. ----------- Appendices No changes in the Appendices. The following are still pending 1)(Page 78)Message Types. Missing Response types and Association Teardown type 2)(Pages 79-80) What is the difference between Operation Type and the OPER-TLV type. Does OPER-TLV exists? In page 80 it should be erased. Proposal-1: Make the Operation Types 0x0101, 0x0102 etc (if you want to put 0x010# (where # the different numbers of operation types) 3)(Page 80)LFB Class ID 1 is Protocol LFB or Object LFB? 4)Appendix-D Use cases: There exist SET-CREATE, SET-REPLACE etc... ====================== Proposal for TLV texts in page 31 The TLV length field is two octets and indicates the length of this TLV including the TLV Type, TLV Length, and the TLV data in octect. Proposed change to The TLV length field is two octets and indicates the length of this TLV including the TLV Type, TLV Length, and the TLV data in octect (prior to padding). ================= Editorial ----------- Page 6 "Section 9 describes mechanism ..." Correction to: "Section 9 describes a mechanism ..." ----------- Page 29 "No ACK... receiver MUST not to send...back to this message sender" Correction to "No Ack... receiver MUST not send...back to the message sender" ----------- Page 39 ...each FULLDATA or or SPARSEDATA... Correction to ...each FULLDATA or SPARSEDATA... ----------- 2006 Message-Id: Date: Wed, 25 Jan 2006 14:43:52 +0800 From: "Wang,Weiming" Subject: Re: [issue65] TLV Clarification I think 'extensive use of TLVs' has quite accurately described the use of TLV as well as ILV. No more text is needed as in the Introduction section. I suppose this issue can be closed in one week if theres no further comments. Thanks, Weiming David Says: In the Introduction section it says "Information exchanged between FEs and CEs makes extensive use of TLVs." Doesn't *all* control information use TLVs in ForCES? Jamal replied: We need to be more explicit: We have two types of TLVs: 16 bit T, 16bit L and then We have ILVs which use elementID for T ... 2006 Message-Id: Date: Wed, 25 Jan 2006 14:06:33 +0800 From: "Wang,Weiming" Subject: Re: [issue64] Forces Protocol Comments Most of the comments given by T. Sridhar have been accepted and the text has been updated by Avri. This issue can be closed. Thank T. Sridhar. Weiming 2006 Message-Id: Date: Wed, 25 Jan 2006 08:38:16 -0500 From: Avri Doria Subject: Re: [issue66] Normative dependency on model (not clear)? Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I agree. the linkage should remain. a. On 25 jan 2006, at 06.07, Joel M. Halpern wrote: > The reason for referencing the model document for the definitions > is that any time things occur in two places (like these > definitions) it is a good idea to be clear as to which one is the > actual definition. (After all, the text can be different.) > Here, our intent is that the model document defines what an LFB is, > and what an LFB Class is, etc. > So it is a good idea to say that. > > Yours, > Joel > > At 02:03 AM 1/25/2006, Wang,Weiming wrote: >> After some work, I think some model terminology related to >> protocol like the >> LFB, LFB instance, LFB metadata have all been included in the >> protocol >> definition section, therefore I don't think we need the sentence in >> definition section on refering to model anymore, i.e., to change >> the text: >> >> 3. Definitions >> This document follows the terminology defined by the ForCES >> Requirements in [RFC3654] and by the ForCES framework in >> [RFC3746]. >> This document also uses the terminology defined by ForCES the FE >> model in [FE-MODEL]. The definitons below are repeated below for >> clarity. >> >> to: >> >> 3. Definitions >> This document follows the terminology defined by the ForCES >> Requirements in [RFC3654] and by the ForCES framework in >> [RFC3746]. >> Some definitons below are repeated for clarity. > 2006 Message-Id: Date: Wed, 25 Jan 2006 06:38:12 +0000 From: Weiming Wang Subject: [issue84] RESULT TLV modification Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Weiming Wang : Some comments on the protocol draft mentioned the care about the modificati= on=20 of the Result TLV section. David mentioned the context on the 'permission=20 denided', Avri mentioned the bits consume about the error code. Based on th= e=20 suggestions, I give the following update on the Result TLV section. Pls=20 comments on it, and Avri pls help to put it in the new 07 after no more=20 comments.=20 7=2E1.1.1.7. Result TLV A RESULT TLV contains a 4 octet integer value. The defined values are 0 =3D success 1 =3D no such object 2 =3D permission denied 3 =3D invalid value (the encoded data could not validly be stored in the field) 4 =3D invalid array creation (when the subscript in an array create is not allowed) 255 =3D unspecified error (for when the FE can not decide what went wrong) 7=2E1.1.1.7. Result TLV The RESULT TLV is an instance of TLV defined in Section 6.2. The definition is as below:=20 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D RESULT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Value | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 The defined Result Values are 0 =3D success 1 =3D no such object 2 =3D permission denied (e.g., trying to configure an attribute that is = read- only) 3 =3D invalid value (the encoded data could not validly be stored in the field) 4 =3D invalid array creation (when the subscript in an array create is not allowed) 255 =3D unspecified error (for when the FE can not decide what went wrong) others =3D Reserved Thanks, Weiming ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 437 nosy: weiming priority: May fix status: No discussion title: RESULT TLV modification ___________________________________________________ Forces issue tracker ___________________________________________________ 2006 Message-Id: Date: Wed, 25 Jan 2006 06:07:50 -0500 From: "Joel M. Halpern" Subject: Re: [issue66] Normative dependency on model (not clear)? Comments: To: "Wang,Weiming" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The reason for referencing the model document for the definitions is that any time things occur in two places (like these definitions) it is a good idea to be clear as to which one is the actual definition. (After all, the text can be different.) Here, our intent is that the model document defines what an LFB is, and what an LFB Class is, etc. So it is a good idea to say that. Yours, Joel At 02:03 AM 1/25/2006, Wang,Weiming wrote: >After some work, I think some model terminology related to protocol like the >LFB, LFB instance, LFB metadata have all been included in the protocol >definition section, therefore I don't think we need the sentence in >definition section on refering to model anymore, i.e., to change the text: > >3. Definitions > This document follows the terminology defined by the ForCES > Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. > This document also uses the terminology defined by ForCES the FE > model in [FE-MODEL]. The definitons below are repeated below for > clarity. > >to: > >3. Definitions > This document follows the terminology defined by the ForCES > Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. > Some definitons below are repeated for clarity. 2006 Message-Id: Date: Wed, 25 Jan 2006 00:27:33 -0800 From: "Khosravi, Hormuzd M" Subject: Re: [issue66] Normative dependency on model (not clear)? Comments: To: "Wang,Weiming" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Weiming, Your change below sounds good to me. Thanks for all the good work closing so many issues! I think we should be ready to send the draft by IESG review by next week if we can get these changes in. Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Tuesday, January 24, 2006 11:04 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue66] Normative dependency on model (not clear)? After some work, I think some model terminology related to protocol like the LFB, LFB instance, LFB metadata have all been included in the protocol definition section, therefore I don't think we need the sentence in definition section on refering to model anymore, i.e., to change the text: 3. Definitions This document follows the terminology defined by the ForCES Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. This document also uses the terminology defined by ForCES the FE model in [FE-MODEL]. The definitons below are repeated below for clarity. to: 3. Definitions This document follows the terminology defined by the ForCES Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. Some definitons below are repeated for clarity. In Page 10, remove the following sentence: The following terms are defined by this document: Please comments on the above change,and this issue is to be closed in one week. Thanks, Weiming > David Says: In the definitions section of the ForCES protocol, there is a reference to the model draft. The reference to the model seems normative to me. Is this the case? Jamal replied: "I dont think so - Joel? The dependency on the model at the moment rests with the FEO; which we may end removing." Solutions can be: * Clarify that this is informative * Bring the definitions into this doc * Make it normative, then both docs required to become RFCs 2006 Message-Id: Date: Tue, 24 Jan 2006 12:00:46 +0800 From: "Guo, Xiaoyi" Subject: About the Model Library MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT hi, folks I and Joel work for one of the LFB Library in LFB library draft some days and now i think we need the workgroup comments. The following is the LFB library of the section 5.1. IPv4 Validator LFB[1] . And please comments. cheers, xiaoyi [1]. ErrorId Error Types. int32 WrongIpVersion the IP version wrong WrongLength the packet length is not as long as the header indicates otherError The errors we not defined now IPv4Validat An LFB Class definition for validates the IPv4 packet. 1.0 ValidatIn Normal packet input. IPv4 ValidatOut Normal packet Output. IPv4 packet FailOutput The port to send packets that do not match any entries. taggedFrame ErrorId This LFB validates the IP version and header length fields, including verifying that the packet length is at least as long as the header indicates. 2006 Message-Id: Date: Sat, 21 Jan 2006 07:34:19 +0000 From: Xiaoyi Subject: [issue83] LFB model Xml need correct Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Xiaoyi : i found a typo of xml lfb in LFB model draft, so please correct it in next=20 version. line 3825 need add one more ---------- category: Editorial draft: draft-ietf-forces-model messages: 435 nosy: Xiaoyi priority: Must fix status: Need clarifying text title: LFB model Xml need correct ___________________________________________________ Forces issue tracker ___________________________________________________ 2006 Message-Id: Date: Fri, 20 Jan 2006 14:42:23 +0800 From: "Wang,Weiming" Subject: Re: [issue63] Editorial nits from LC review Sorry a typo as: * Page 12, /... reference points Fc and Fe, is ... / here the Fe should be Ff, I think. Weiming ----- Original Message ----- From: "Wang,Weiming" Sent: Friday, January 20, 2006 2:38 PM Subject: Re: [issue63] Editorial nits from LC review > I have (quite carefully) double checked the update Avri made on 06 on this > issue. I think Avri has done good job on it. Only some left nits as I list below > that need to be worked further in next 07 version. > > * Page 12, /... reference points Fc and Fe, is ... / here the Fe should be > Fl, I think. > 2006 Message-Id: Date: Fri, 20 Jan 2006 14:38:48 +0800 From: "Wang,Weiming" Subject: Re: [issue63] Editorial nits from LC review I have (quite carefully) double checked the update Avri made on 06 on this issue. I think Avri has done good job on it. Only some left nits as I list below that need to be worked further in next 07 version. * Page 12, /... reference points Fc and Fe, is ... / here the Fe should be Fl, I think. * Merge the #7 and #8 of the TML requirements Section (Section 5). * 6.2.2. Scope of the T in TLV, The sentence that starts with "This means that wherever" is confusing, can it be reworded? I suggest to change the sentence to "This means that wherever TLVs are in the PDU, the same Type value refers to the same Type of TLV. " * 7.1.1. Protocol BNF, Reference is made to *0, but *0 appears to be illegal in this grammar? Isn't + more frequently used than 1* to indicate 1 or more repetitions? I am not a BNF expert however. Jamal, Please provide your thought ASAP. * 7.1.1.1.8. Data TLV, Padding is mentioned. What is the padding, 0s or some other value? I suggest to add to the sentence "If need be they MUST be padded to achieve the alignment." with the setence "Padding used for the alignment must be zero on transmission and must be ignored upon reception.". The same setence also applies to Page 32(Section 6.2) as I indicated in another emal. After above is done in 07, this issue can be closed. Thanks David. Weiming ----- Original Message ----- From: "David Putzolu" Sent: Tuesday, November 15, 2005 12:23 AM Subject: [issue63] Editorial nits from LC review New submission from David Putzolu : Abstract: * s/ForCES protocol is a message exchange protocol that is used for/ForCES protocol is used for/ 1. Introduction: * s/aims to define an architectural framework/defines an architecture framework/ * s/the term "ForCES protocol" refers only/"ForCES protocol" and "protocol" as used in this document refers/ * s/The ForCES protocol is defined to have a common header/The ForCES Protocol defines a common header 2. Definitions * s/(see below) to determine which FE to use./(see below) to determine which FE(s) to use. * LFB Metadata - same comment, functionally but not implementation accurate. * The definition of ForCES Protocol Transport Mapping Layer has the phrase "how to achieve and implement reliability, multicast, ordering, etc." Need to be very careful here as it is not in the ForCES charter to create a new transport protocol. Consider language such as "how to fulfill ForCES transport requirements using the capabilities of the identified underlying transport protocols and mediums" (although this language is ugly, hopefully someone can come up with something better). 3.1 Protocol Framework * "The protocol element configuration is out of scope of the ForCE protocol" - Do you mean CEM and FEM configuration here? Not clear. 3.1.2 The TML Layer * s/layer is essentially responsible for transport of/layer transports/ 3.3.1.1.3. Transactional protocol * There is an editorial note here that needs to be addressed. This feels borderline technical 3.3.1.1.5 continue-execute-on-failure * The first sentence appears to be a fragment. Same comment applies to 3.3.1.1.6. 3.3.1.1.6 execute-until-failure * There is an editorial note here that borders on technical. 3.3.3 FE Object and FE protocol LFBs * "speacilized" 3.3.4 Scaling by Concurrency * The section title is confusing. How about just "Scalability"? * s/mythical/hypothetical/ 4. TML Requirements * Shouldn't #3 also include preventing the link(s) to the CE being overwhelmed by traffic from FEs? * Is #8 really a separate requirement from #7? * s/priotity/priority/ 5. Message encapsulation * While it is probably safely assumed, I would like to see it explicitly called out that all fields are in network byte order. 5.1 Common Header * s/donot/do not/ * s/Fe/FE/ * s/inidcate/indicate/ 5.2. Type Length Value(TLV) Structuring * Is the length in units of octets or in 32-bit words? 5.2.2. Scope of the T in TLV * The sentence that starts with "This means that wherever" is confusing, can it be reworded? 6.1.1. Protocol BNF * Reference is made to *0, but *0 appears to be illegal in this grammar? * Isn't + more frequently used than 1* to indicate 1 or more repetitions? I am not a BNF expert however. 6.1.1.1. Discussion on Grammar * s/optionaly/optionally/ 6.1.1.1.6. Operation TLV * s/deleteing/deleting/ 6.1.1.1.7. Result TLV * Permission denied has no context. When might it be returned and why? 6.1.1.1.8. Data TLV * Padding is mentioned. What is the padding, 0s or some other value? 6.2.1. FE Protocol LFB * For clarity fully define the value. I.e. 0x0001 * The writable FE protocol attribute of ForCES protocol should call out that the only legal values are those that are returned in the ForCES protocol version capability. * s/associatin/association/ 6.5.2. Config Response Message * s/TThe/The/ 8. High Availability Support * Should the bottom All Msgs arrow in figure 33 have bidirectional arrows? Same comment for figure 34. Appendix C. ForCES Protocol LFB schema * Has this been run through an XML validation tool? Appendix F. changes between -03, -04, and -05 * Should there be RFC editor instructions to remove this section Upon publication? * Same comment applies to Appendix G, H, I Author's addresses appears twice ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 362 nosy: dputzolu priority: May fix status: Text proposed title: Editorial nits from LC review ___________________________________________________ Forces issue tracker ___________________________________________________ 2006 Message-Id: Date: Thu, 19 Jan 2006 23:02:41 +0800 From: Weiming Wang Subject: Re: [issue82] Author's list be modified Joel, I think you have a misunderstanding of the question. It does not ask to put all authors on the front page, it just asks to correct the Author's address section, which is obviously a mistake owing to the xml2rfc tool limitation. Thanks, Weiming ----- Original Message ----- From: "Joel M. Halpern" > This seems like an invitation to trouble. > The RFC editor is going to have serious question as to why more than 5 (or > sometimes 6) people are appearing on the front page. The accepted practice > is to put an editor on the front page, and have a "Contributors" section in > the document, distinct from the acknowledgements, where the folks who wrote > parts of the document are listed. > > Yours, > Joel M. Halpern > > PS: It is understood that this causes some university participants some > difficulty. But listing large numbers of authors on the front is also > ineffective and misleading. Sometimes, design teams reach a compromise and > list 3 members who did the most work on the front. > > At 02:14 AM 1/19/2006, Weiming Wang wrote: > >New submission from Weiming Wang : > > > >06 draft the Author's list only contains 5 editors rather than 7 authors. > >This > >must be fixed. > > > >Because the xml2rfc automatically generates an author list which only > >contains > >editors in the first page. To solve this question, I suggest: > > > >1. During the usual update process, keep the 7 author list aw well as the > >auto- > >generated 5 author list. > > > >2. Right before we submit to IESG, manually delete the 5 author list and > >substitute it with 7 author list. A page re-alignment may be needed to do so. > > > >Weiming > > > >---------- > >category: Editorial > >draft: draft-ietf-forces-protocol > >messages: 423 > >nosy: weiming > >priority: Must fix > >status: Pending > >title: Author's list be modified > > > >___________________________________________________ > >Forces issue tracker > > > >___________________________________________________ 2006 Message-Id: Date: Thu, 19 Jan 2006 15:49:09 +0800 From: "Wang,Weiming" Subject: Re: [issue70] Correlator closed as being accepted. Weiming ----- Original Message ----- From: "Ellen M Deleganes" Sent: Tuesday, November 15, 2005 9:02 AM Subject: [issue70] Correlator New submission from Ellen M Deleganes : 5.1 Common Header, Correlator The behavior of the FE as defined in the Correlator section should be made a MUST in order for the protocol to behave properly. That is, "The Correlator is handled transparently by the FE, i.e., for a particular Request message it MUST assign the same correlator value in the corresponding Response message." Nit - in this case, it would be helpful to replace "it" with "the FE". ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 371 nosy: ellen priority: Should fix status: No discussion title: Correlator ___________________________________________________ Forces issue tracker ___________________________________________________ 2006 Message-Id: Date: Thu, 19 Jan 2006 15:45:11 +0800 From: "Wang,Weiming" Subject: Re: [issue72] Fix text up with "a FE" or "an FE" closed as being accepted. Weiming ----- Original Message ----- From: "Xiaoyi" Sent: Wednesday, November 16, 2005 12:47 AM Subject: [issue72] Fix text up with "a FE" or "an FE" New submission from Xiaoyi : I think the words "a FE" and "an FE" all exist in the draft, we must choice only one. I prefer to choose the latter one as Alex 's opinion. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 373 nosy: Xiaoyi priority: Must fix status: Need clarifying text title: Fix text up with "a FE" or "an FE" ___________________________________________________ Forces issue tracker ___________________________________________________ 2006 Message-Id: Date: Thu, 19 Jan 2006 15:43:59 +0800 From: "Wang,Weiming" Subject: Re: [issue71] FE Protocol LFB required? closed as being accepted. Weiming ----- Original Message ----- From: "Ellen M Deleganes" Sent: Tuesday, November 15, 2005 9:39 AM Subject: [issue71] FE Protocol LFB required? New submission from Ellen M Deleganes : Section 6.2.1, Shouldn't the "MAY" be a "MUST"? Isn't it a requirement that an FE contain one and only one instance of a FE protocol LFB? It seems like the CE wouldn't be able to control the FE if it didn't contain this logical LFB. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 372 nosy: ellen priority: Should fix status: No discussion title: FE Protocol LFB required? ___________________________________________________ Forces issue tracker ___________________________________________________ 2006 Message-Id: Date: Thu, 19 Jan 2006 15:38:37 +0800 From: "Wang,Weiming" Subject: Re: [issue62] FE Protocol LFB Parsing The issue is closed as being accepted. Weiming ----- Original Message ----- From: "Avri Doria" Sent: Monday, November 28, 2005 10:11 PM Subject: Re: [issue62] FE Protocol LFB Parsing > done on -06 > > a. > > On 27 nov 2005, at 21.33, Wang,Weiming wrote: > > > > > On the cross checking 1, pls incorperate the following text with > > "add" mark. On > > the 2, pls just move the ...... part > > to the place > > after . > > > > 2006 Message-Id: Date: Thu, 19 Jan 2006 15:36:03 +0800 From: "Wang,Weiming" Subject: Re: [issue 39] Protocol LFB - Heart Beat Dead Interval The issue is to be closed as being rejected in one week if theres no further comments. thanks, Weiming ------------- Comments Comment #394 wmwang@mail.zjgsu.edu.cn 2005-11-25.08:24:36 removeDavid, I think what FE needs to know is just the CE Heartbeat Dead Interval(CE HDI) rather than the CE heartbeat interval, because the parameter does not make any sense to FE for its use. This also means CE does not have to set the parameter in the FE Protocol LFB definition. Thanks, Weiming Comment #369 david.putzolu@intel.com 2005-11-14.20:26:43 removeI could not find where the CE heartbeat interval (must be shorter than the CE HDI) was stated, nor could I find a place to set it. So this is still an open issue. Comment #354 hadi@znyx.com 2005-10-23.16:50:31 removeresolved in draft -05 Comment #127 avri@acm.org 2005-06-10.14:58:24 removesuperceeded by Issue 37 decsion to remove requirement for LFP protocol LFB. Need specifc text on default heartbeat intervals [who to privide text?] Comment #57 avri@acm.org 2005-05-22.18:57:58 removeC.3.2 HBDI This attribute carries the Heartbeat Dead Interval in millisecs. TBD: C.3.2 The original goal for HBDI was for HA purposes - to discover if the CE is still around by sending a heartbeat message to the CE with an ACK flag in the mainheader to request for a response. This hasnt been discussed in details yet; however, the general view at the time was for the FE to associate (failover) to another CE after that deadinterval period of not hearing from the CE - as defined by policy which resides in that same LFB definition. Two such failover methodologies are mentiooned briefly infact in the protocol draft but since the current attributes are unknown, the details are missing from the xml. 2006 Message-Id: Date: Thu, 19 Jan 2006 15:27:43 +0800 From: "Wang,Weiming" Subject: Re: [issue 9] Fix LFB definition The issue is closed as being accepted. Weiming ----- Original Message ----- From: "Wang,Weiming" Sent: Thursday, August 18, 2005 11:40 PM Subject: Re: [issue 9] Fix LFB definition > Hi, > > The LFB class definition has been modifed in the protocol draft as > below: > > LFB (Logical Functional Block) Class (or Type) -- the basic building > blocks that are operated on by the Forces protocol. The LFB is a well > defined, logically separable functional block that resides in the FE and > is controlled by the CE via ForCES protocol. The LFB may reside at the > FE's datapath and process packets or may be purely a control entity that > is operated on by the CE. > > Thanks, > Weiming > > ----- Original Message ----- > From: "Deleganes, Ellen M" > > I am also fine with this definition. > > Regards, > Ellen > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > Sent: Tuesday, August 16, 2005 8:38 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [issue 9] Fix LFB definition > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > BTW, I am really suprised at the weak definitions of LFB; i just > glanced > > at model and framework docs. > > > > Probably you want to emphasize the following: > > - it resides at the FE (since we killed CE based LFBs) > > - it _may_ process packets > > - it is managed/controlled by the CE > > > > i.e something along: > > "LFB classes are the basic building blocks that are operated on by the > > Forces protocol. The LFB is a well defined, logically separable > > functional block that resides in the FE and is controlled by the CE > via > > forces protocol. The LFB may reside at the FEs datapath and process > > packets or may be purely a control entity that is operated on by the > CE" > > I'm fine with the definition. How about model team thought? We need to > be consistent between the protocol and the team on the definition. > > Jamal, when it is solved, I will immediately modify the definition in > the protocol draft. > > Thanks, > Weiming > > > > > cheers, > > jamal 2006 Message-Id: Date: Thu, 19 Jan 2006 10:22:15 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Sorry, a typo I found by myself. > Page 28 changed to: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | | | | | | | > |ACK| Pri |X X|TP |A|TP | Reserved | > | | | | |T| | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | |ACK| Pri |x x|EM |A|TP | Reserved | | | | | |T| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Avri, I just found the tracker does not quote issue 76 from Forces list anymore, which may have to make your editing based on this list directly. Thanks, Weiming 2006 Message-Id: Date: Thu, 19 Jan 2006 09:31:05 -0500 From: "Joel M. Halpern" Subject: Re: [issue82] Author's list be modified Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed This seems like an invitation to trouble. The RFC editor is going to have serious question as to why more than 5 (or sometimes 6) people are appearing on the front page. The accepted practice is to put an editor on the front page, and have a "Contributors" section in the document, distinct from the acknowledgements, where the folks who wrote parts of the document are listed. Yours, Joel M. Halpern PS: It is understood that this causes some university participants some difficulty. But listing large numbers of authors on the front is also ineffective and misleading. Sometimes, design teams reach a compromise and list 3 members who did the most work on the front. At 02:14 AM 1/19/2006, Weiming Wang wrote: >New submission from Weiming Wang : > >06 draft the Author's list only contains 5 editors rather than 7 authors. >This >must be fixed. > >Because the xml2rfc automatically generates an author list which only >contains >editors in the first page. To solve this question, I suggest: > >1. During the usual update process, keep the 7 author list aw well as the >auto- >generated 5 author list. > >2. Right before we submit to IESG, manually delete the 5 author list and >substitute it with 7 author list. A page re-alignment may be needed to do so. > >Weiming > >---------- >category: Editorial >draft: draft-ietf-forces-protocol >messages: 423 >nosy: weiming >priority: Must fix >status: Pending >title: Author's list be modified > >___________________________________________________ >Forces issue tracker > >___________________________________________________ 2006 Message-Id: Date: Thu, 19 Jan 2006 07:14:17 +0000 From: Weiming Wang Subject: [issue82] Author's list be modified Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Weiming Wang : 06 draft the Author's list only contains 5 editors rather than 7 authors. T= his=20 must be fixed. Because the xml2rfc automatically generates an author list which only conta= ins=20 editors in the first page. To solve this question, I suggest: 1=2E During the usual update process, keep the 7 author list aw well as the= auto- generated 5 author list. 2=2E Right before we submit to IESG, manually delete the 5 author list and=20 substitute it with 7 author list. A page re-alignment may be needed to do s= o=2E Weiming ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 423 nosy: weiming priority: Must fix status: Pending title: Author's list be modified ___________________________________________________ Forces issue tracker ___________________________________________________ 2006 Message-Id: Date: Wed, 18 Jan 2006 20:53:41 -0800 From: "Khosravi, Hormuzd M" Subject: Re: Need Help ! (ForCES for my MSc dissertation) Comments: To: Abid Ghufran MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abid, Pls see my responses inline below...=20 Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Abid Ghufran Sent: Monday, January 16, 2006 2:18 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Need Help ! (ForCES for my MSc dissertation) Dear All, I am doing MSc in High Speed Networks and Distributed Systems, from Oxford Brookes University UK. For my dissertation I intend to take "something from the" ForCES protocol. After going through the standard documents on this protocol, I have found it very interesting and am therfore thinking of finally deciding for it. There is a condition for my dissertation, that it should involve both networking and programming related to distributed systems. I have found the ForCES concept to be covering both of these requirements. But before I finally decide, I would like some advise from the people on this list. 1) I have found that the protocol concept has a very extensive and a wide scope. I shall only be having 3 months for my dissertation. Of all the elements included in this concept of ForCES protocol, which aspect should be mose suitable for my dissertation? In simple words there are many things involved in the ForCES, which of them should I aim at, for my dissertation? [HK] That's a tough one to answer, it would depend on your comfort level with implementation or simulation, etc. One topic that I would suggest is evaluation of transport protocols for ForCES control/data channel. I have personally published 2 papers in conferences on this topic in 2004 and would be happy to give you those references. Currently, the wg is tending towards using TCP for the control channel and DCCP for the data channel. This is a very good theoretical combination; it would be good to get some experimental nos on this as well. Other topics would include simulation of different LFBs on the FE, simulations to test scalability of ForCES protocol, etc 2) Can I consider this protocol as similar to an out-of-band signalling model for coordination between the CE, FE and LFBs? [HK] yes, that's one of thinking about it 3) I feel that this concept will see prevalent usage in the networking field. What do you think? [HK] I Agree 4) Are there any vendors thinking or planning to incorporate this concept? [HK] Yes, some of them are active on this mailing list...no specific product announcements yet that I know of, so I wont take names. 5) What kind of language platform/functionality would be deemed suitable for the implementation of this protocol? [HK] I would say start of with a Linux based PC 6) Is it possilbe to study/analyze the protocol by simulating it? Which of its aspect could be simulated? [HK] The LFB behavior on the FE could be simulated. Also the TML behavior could be simulated as well I shall be most grateful if you could help me in this regard. Thank you very much, Abid Ghufran. 2006 Message-Id: Date: Wed, 18 Jan 2006 16:06:13 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Avri and all, I made the update as below. Please make your comments. Avri, please help to fit in if theres no further comments. thanks, Weiming --------- Section 4.3 updates as below: 4.3. Protocol Mechanisms Various semantics are exposed to the protocol users via the PL header including: Transaction capabilities, atomicity of transactions, two phase commits, batching/parallelization, High Availability and failover as well as command windows. EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP (Transaction Phase) flag defined in Common Header Section (Section 6.1) are highly related to these mechanisms. 4.3.1. Execution, Transactions, Atomicity, and Responses In the master-slave relationship the CE instructs one or more FEs on how to execute operations and how to report back the results. This section details the different modes of execution that a CE can order the FE(s) to perform as defined in Section 4.3.1.1. It also describes the different modes a CE can ask the FE(s) to use for formatting the responses after processing the operations as requested, which relates to transactional two phase commitment operations. 4.3.1.1. Execution There are 3 execution modes that could be requested for a batch of operations spanning one or more LFB selectors in one protocol message. The EM flag defined in Common Header Section (Section 6.1) selects the execution mode for a protocol message, as below: a. execute-all-or-none b. execute-until-failure c. continue-execute-on-failure 4.3.1.1.1. execute-all-or-none When set to this mode, indipendent operations in a message targeted at one or more LFB selectors will all be executed if no failure happens for the operations, or none of the operations will be executed if there is any failure for the operations. 4.3.1.1.2. continue-execute-on-failure If several independent operations are targeted at one or more LFB selectors, execution continues at the FE even if one or more operations fail. 4.3.1.1.3. execute-until-failure In this mode all operations are executed on the FE sequentially until the first failure. The rest of the operations are not executed but operations already completed are not undone, i.e. there is no roll back in this mode. 4.3.1.2. Transaction and Atomicity 4.3.1.2.1. Transaction Definition A transaction is defined as a collection of one or more ForCES operations within one or more PL messages that MUST meet the ACIDity properties[ACID], defined as: o *Atomicity*. In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are. o *Consistency*. A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started. o *Isolation*. A transaction in process and not yet committed must remain isolated from any other transaction. o *Durability*. Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state. There are cases where the CE knows exact memory and implementation details of the FE such as in the case of an FE-CE pair from the same vendor where the FE-CE pair is tightly coupled. In such a case, the transactional operations may be simplified further by extra computation at the CE. This view is not discussed further other than to mention that it is not disallowed. Defined as above, a transaction is always atomic and may be: a. Within an FE alone Example: updating multiple tables which are dependent on each other. If updating one fails, then any others already updated must be undone. b. Distributed across the NE Example: updating table(s) that are inter-dependent across several FEs (such as L3 forwarding related tables). 4.3.1.2.2. Transaction protocol By use of the execute mode as defined in Section 4.3.1.1, the protocol has provided a mechanism for transactional operations within one stand-alone message. The 'execute-all-or-none' mode can meet the ACID requirements. For transactional operations of multipul messages within one FE or across FEs, a classical transactional protocol known as Two Phase Commit (2PC) [2PCREF] is supported by the protocol to achieve the transactional operations. AT flag and TP flag in Common Header (Section 6.1) are provided for 2PC based transactional operations spaaning multipul messages. The AT flag, when set, indicates this message belongs to an Atomic Transaction. All messages for a transaction operation must have the AT flag set. If not set, it means the message is just stand-alone message and does not participate in any transaction operation that spans mulitpul messages. The TP flag indicates the Transaction Phase this message belongs to. There are possibly 4 phases for an transactional operation as: `SOT (Start of Transaction)` , `MOT (Middle of Transaction)`, `EOT (End of Transaction)`, and `ABT (Abort)`. A transaction operation is started with a message the TP flag is set to Start of Transaction (SOT). Multipart messages, after the first one, are indicated by the Middle of Transaction flag (MOT). The last message is indicated by by EOT. Any failure notified by the FE causes the CE to execute an Abort Transaction (ABT) to all FEs involved in the transaction, rolling back all previously executed operations in the transaction. The transaction commitment phase is signaled from the CE to the FE by an End of Transaction (EOT) configuration message. The FE MUST respond to the CE's EOT message. If no response is received from the FE within a specified timeout, the transaction MUST be aborted by the CE. Note that a transactional operation is generically atomic, therefore it requires that the execute modes of all messages in a transaction operation should always be kept the same and be set to 'execute-all-or-none'. If the EM flag is set to other execute modes, it will result in a transaction failure. As noted above, a transaction may span multiple messages. It is up to the CE to keep track of the different outstanding messages making up a transaction. As an example, the correlator field could be used to mark transactions and a sequence field to label the different messages within the same atomic transaction, but this is out of scope and up to implementations. 4.3.1.2.3. Recovery Any of the participating FEs, or the CE, or the associations between them, may fail after the EOT response message has left the FE but before it has received all the responses, e.g if the EOT response never reaches the CE. In this protocol revision, for sake of simplicity as indicated in Section 4.2.2.3, an FE losing an association would be required to get new state from the newly associated CE from scratch upon a re- association. The decision on what an FE should do after a lost association is dictated by the CE Failover policy (refer to Section 9 and Section 7.2). 4.3.2. Scalability It is desirable that the PL layer not become the bottleneck when larger bandwidth pipes become available. To pick a hypothetical example in today's terms, if a 100Gbps pipe is available and there is sufficient work then the PL layer should be able to take advantage of this and use all of the 100Gbps pipe. Two mechanisms have actually been provided to achieve this. The first one is batching and the second one is a command window. Batching is the ability to send multiple commands (such as Config) in one Protocol Data Unit (PDU). The size of the batch will be affected by, amongst other things, the path MTU. The commands may be part of the same transaction or part of unrelated transactions that are independent of each other. Command windowing allows for pipelining of independent transactions which do not affect each other. Each independent transaction could consist of one or more batches. 4.3.2.1. Batching There are several batching levels at different protocol hierarchies. o multiple PL PDUs can be aggregated under one TML message o multiple LFB classes and instances (as indicated in the LFB selector) can be addressed within one PL PDU o Multiple operations can be addressed to a single LFB class and instance 4.3.2.2. Command Pipelining The protocol allows any number of messages to be issued by the CE before the corresponding acknowledgments (if requested) have been returned by the FE. Hence pipelining is inherently supported by the protocol. Matching responses with requests messages can be done using the correlator field in the message header. 4.3.3. Heartbeat Mechanism Heartbeats (HB) between FEs and CEs are traffic sensitive. A HB is sent only if no PL traffic is sent between the CE and FE within a configured interval. This has the effect of reducing the amount of HB traffic in the case of busy PL periods. A HB can be sourced by either the CE or FE. When sourced by the CE, a response can be requested (similar to the ICMP ping protocol). The FE can only generate HBs in the case of being configured to do so by the CE. Refer to Section 7.2.1 and Section 7.9 for details. 4.3.4. FE Object and FE protocol LFBs All PL messages operate on LFB constructs as this provides more flexibility for future enhancements. This means that maintenance and configurability of FEs, NE, as well as the ForCES protocol itself must be expressed in terms of this LFB architecture. For this reason special LFBs are created to accommodate this need. In addition, this shows how the ForCES protocol itself can be controlled by the very same type of structures (LFBs) it uses to control functions such as IP forwarding, filtering, etc. To achieve this, the following specialized LFBs are introduced: o FE Protocol LFB which is used to control the ForCES protocol. o FE Object LFB which is used to controls attributes relative to the FE itself. Such attributes include FEState (refer to model draft), vendor, etc. These LFBs are detailed in Section 7.2. ------- some more changes as below: Page 28 changed to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | |ACK| Pri |X X|TP |A|TP | Reserved | | | | | |T| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ACK: ACK indicator(2 bit) The ACK indicator flag is only used by the CE when sending a Config Message(Section 7.5.1) or a HB message (Section 7.9) to indicate to the message receiver whether or not a response is required by the sender. Note that for all other messages this flag MUST be ignored. (note the change in the text above) Page 30 changed to: - EM: Execution mode (2 bits) There are 3 execution modes, refer to Section 4.3.1.1 for details. Reserved.................... (0b00) `execute-all-or-none` ....... (0b01) `execute-until-failure` ..... (0b10) `continue-execute-on-failure` (0b11) - AT: Atomic Transaction (1 bit) This flag indicates if the message is stand-alone message or one of multipul messages that belongs to 2PC transaction operations. See Section 4.3.1.2 for details. 'Stand-alone message'........ (0b0) `2PC transaction message' ... (0b1) - TP: Transaction phase (2 bits) A message from the CE to the FE within a transaction could be indicative of the different phases the transaction is in. Refer to Section 4.3.1.2 for details. `SOT (Start of Transaction)` --- (0b00) `MOT (Middle of Transaction)` -- (0b01) `EOT (End of Transaction)` ----- (0b10) `ABT (Abort)` ------------------ (0b11) 2006 Message-Id: Date: Wed, 18 Jan 2006 15:21:36 +0800 From: "Guo, Xiaoyi" Subject: Re: problem about Packet Redirect TLV encapsulation MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT That's a good suggestion, i agree. and Joel ? cheers, xiaoyi ----- Original Message ----- From: "Weiming Wang" Sent: Wednesday, January 18, 2006 10:15 AM Subject: Re: problem about Packet Redirect TLV encapsulation | Xiaoyi, | | I think the rule should apply to all TLVs rather than the last TLV. Only should | we note that for nested TLVs padding is possible only in the last(the deepest) | TLV. | | thanks, | weiming | | From: "Guo, Xiaoyi" | | > hi,weiming, | > | > Joel said the padding after the last TLV must be zero. | > If the TLV section changes to the follow, it looks | > the padding for all TLVs should be zero instead of the last one, | > right? | > | > cheers, | > xiaoyi | > | > ----- Original Message ----- | > From: "Weiming Wang" | > Sent: Tuesday, January 17, 2006 10:43 PM | > Subject: Re: problem about Packet Redirect TLV encapsulation | > | > | > | Avri, | > | | > | Based on the discussion, I suggest changes as below: | > | | > | Page 32(Section 6.2): | > | | > | | > | TLV Value (variable): | > | The TLV Value field carries the data. For | > | extensibility, the TLV value may in fact be a TLV. | > | TLVs must be 32 bit aligned | > | | > | | > | | > | TLV Value (variable): | > | The TLV Value field carries the data. For | > | extensibility, the TLV value may in fact be a TLV. | > | TLVs must be 32 bit aligned. Padding used | > | for the alignment must be zero on transmission and must | > | be ignored upon reception. | > | | > | All types of TLVs used in this document follow the TLV rules described as | > | above. | > | | > | | > | Thanks, | > | Weiming | > | | > | From: "Jia Fenggen" | > | | > | > Agree,and for the consistency,i think the same rule applys to all the | other | > | > TLVs. | > | > | > | > Yours,fenggen | > | > | > | > >From: "Joel M. Halpern" | > | > > | > | > >We probably should specify in the protocol spec that the padding | > | > >after the last TLV (if any such padding is need) must be zero on | > | > >transmission and must be ignored upon reception. | > | > > | > | > >Yours, | > | > >Joel | > | > > 2006 Message-Id: Date: Wed, 18 Jan 2006 15:02:11 +0800 From: Jia Fenggen Subject: Question about the ForCES Reference Point naming mechanism Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Hi,all: In Page 11 of draft 06,i find the following definitions of ForCES Reference Points: Fp: CE-FE interface Fi: FE-FE interface Fr: CE-CE interface Fc: Interface between the CE Manager and a CE Ff: Interface between the FE Manager and an FE Fl: Interface between the CE Manager and the FE Manager Fi/f: FE external interface I can't see any relationship between the Reference point names and their explanation,could someone tell me the reason behind the naming mechanism,thanks! Yours, Fenggen _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn 2006 Message-Id: Date: Wed, 18 Jan 2006 11:15:38 -0500 From: Alex Audu Subject: Re: Need Help ! (ForCES for my MSc dissertation) Comments: To: abidghufran@HOTMAIL.COM Content-Type: multipart/alternative; boundary="--------MailBlocks_8C7EA618E1C4ECB_C6C_851A_FWM-M06.sysops.aol.com" MIME-Version: 1.0 ----------MailBlocks_8C7EA618E1C4ECB_C6C_851A_FWM-M06.sysops.aol.com Content-Type: text/plain; charset="us-ascii" Hello Abid, One possible approach to take is to start from the basic premise of FORCES. What were the driving forces behind ForCES model? Some of them are: 1) Complexity of NEs as they try to cope with increasingly demanding features like policy based routing, firewalls, NATS, QoS-aware routing,..etc. How does the ForCes model help in managing such complexity growth? 2) Scalability: The ability to cost-effectively grow a network as demand increases 3) Programmability: The ability to dynamically program the network for some specific services by programming the NEs to handle those services explicitly. 4) Security: This is becoming increasingly important. What are the mechanisms in place in ForCES to help bolster network security? 5) Reliability: Service reliability is crucial in a globally networked world. What mechanisms does the ForCES model provide to ensure uninteruptible service? Any of these topics can be studied, and put to test with a software model. I am not sure how much tangible work can be done in the three months you have alloted to the project though. Cheers, Alex. www.garlandsoftworx.com -----Original Message----- From: Abid Ghufran To: FORCES@PEACH.EASE.LSOFT.COM Sent: Mon, 16 Jan 2006 17:17:48 -0500 Subject: Need Help ! (ForCES for my MSc dissertation) Dear All, I am doing MSc in High Speed Networks and Distributed Systems, from Oxford Brookes University UK. For my dissertation I intend to take "something from the" ForCES protocol. After going through the standard documents on this protocol, I have found it very interesting and am therfore thinking of finally deciding for it. There is a condition for my dissertation, that it should involve both networking and programming related to distributed systems. I have found the ForCES concept to be covering both of these requirements. But before I finally decide, I would like some advise from the people on this list. 1) I have found that the protocol concept has a very extensive and a wide scope. I shall only be having 3 months for my dissertation. Of all the elements included in this concept of ForCES protocol, which aspect should be mose suitable for my dissertation? In simple words there are many things involved in the ForCES, which of them should I aim at, for my dissertation? 2) Can I consider this protocol as similar to an out-of-band signalling model for coordination between the CE, FE and LFBs? 3) I feel that this concept will see prevalent usage in the networking field. What do you think? 4) Are there any vendors thinking or planning to incorporate this concept? 5) What kind of language platform/functionality would be deemed suitable for the implementation of this protocol? 6) Is it possilbe to study/analyze the protocol by simulating it? Which of its aspect could be simulated? I shall be most grateful if you could help me in this regard. Thank you very much, Abid Ghufran. ----------MailBlocks_8C7EA618E1C4ECB_C6C_851A_FWM-M06.sysops.aol.com Content-Type: text/html; charset="us-ascii"
Hello Abid,
 
One possible approach to take is to start from the basic premise of FORCES. What were the driving forces behind ForCES model?  Some of them are:
1) Complexity of NEs as they try to cope with increasingly demanding features like policy based
    routing, firewalls, NATS, QoS-aware routing,..etc.   How does the ForCes model help in managing
    such complexity growth?  
 
2) Scalability:  The ability to cost-effectively grow a network as demand increases
 
3) Programmability: The ability to dynamically program the network for some specific services by
    programming the NEs to handle those services explicitly.
 
4) Security:  This is becoming increasingly important. What are the mechanisms in place in ForCES
    to help bolster network security?
 
5) Reliability: Service reliability is crucial in a globally networked world.  What mechanisms does
    the ForCES model provide to ensure uninteruptible service?
 
Any of these topics can be studied, and put to test with a software model.   I am not sure how
much tangible work can be done in the three months you have alloted to the project though.
 
Cheers,
Alex.
 
     
 
-----Original Message-----
From: Abid Ghufran <abidghufran@HOTMAIL.COM>
To: FORCES@PEACH.EASE.LSOFT.COM
Sent: Mon, 16 Jan 2006 17:17:48 -0500
Subject: Need Help ! (ForCES for my MSc dissertation)

Dear All,

I am doing MSc in High Speed Networks and Distributed Systems, from Oxford
Brookes University UK. For my dissertation I intend to take "something from
 the" ForCES protocol.

After going through the standard documents on this protocol, I have found it
very interesting and am therfore thinking of finally deciding for it. There
is a condition for my dissertation, that it should involve both networking
and programming related to distributed systems. I have found the ForCES
concept to be covering both of these requirements. But before I finally
decide, I would like some advise from the people on this list.

1) I have found that the protocol concept has a very extensive and a wide
scope. I shall only be having 3 months for my dissertation. Of all the
elements included in this concept of ForCES protocol, which aspect should be
mose suitable for my dissertation? In simple words there are many things
involved in the ForCES, which of them should I aim at, for my dissertation?

2) Can I consider this protocol as similar to an out-of-band signalling
model for coordination between the CE, FE and LFBs?

3) I feel that this concept will see prevalent usage in the networking
field. What do you think?

4) Are there any vendors thinking or planning to incorporate this concept?

5) What kind of language platform/functionality would be deemed suitable for
the implementation of this protocol?

6) Is it possilbe to study/analyze the protocol by simulating it? Which of
its aspect could be simulated?


I shall be most grateful if you could help me in this regard.

Thank you very much,

Abid Ghufran.
----------MailBlocks_8C7EA618E1C4ECB_C6C_851A_FWM-M06.sysops.aol.com-- 2006 Message-Id: Date: Wed, 18 Jan 2006 10:15:35 +0800 From: Weiming Wang Subject: Re: problem about Packet Redirect TLV encapsulation Xiaoyi, I think the rule should apply to all TLVs rather than the last TLV. Only should we note that for nested TLVs padding is possible only in the last(the deepest) TLV. thanks, weiming From: "Guo, Xiaoyi" > hi,weiming, > > Joel said the padding after the last TLV must be zero. > If the TLV section changes to the follow, it looks > the padding for all TLVs should be zero instead of the last one, > right? > > cheers, > xiaoyi > > ----- Original Message ----- > From: "Weiming Wang" > Sent: Tuesday, January 17, 2006 10:43 PM > Subject: Re: problem about Packet Redirect TLV encapsulation > > > | Avri, > | > | Based on the discussion, I suggest changes as below: > | > | Page 32(Section 6.2): > | > | > | TLV Value (variable): > | The TLV Value field carries the data. For > | extensibility, the TLV value may in fact be a TLV. > | TLVs must be 32 bit aligned > | > | > | > | TLV Value (variable): > | The TLV Value field carries the data. For > | extensibility, the TLV value may in fact be a TLV. > | TLVs must be 32 bit aligned. Padding used > | for the alignment must be zero on transmission and must > | be ignored upon reception. > | > | All types of TLVs used in this document follow the TLV rules described as > | above. > | > | > | Thanks, > | Weiming > | > | From: "Jia Fenggen" > | > | > Agree,and for the consistency,i think the same rule applys to all the other > | > TLVs. > | > > | > Yours,fenggen > | > > | > >From: "Joel M. Halpern" > | > > > | > >We probably should specify in the protocol spec that the padding > | > >after the last TLV (if any such padding is need) must be zero on > | > >transmission and must be ignored upon reception. > | > > > | > >Yours, > | > >Joel > | > > 2006 Message-Id: Date: Wed, 18 Jan 2006 09:59:47 +0800 From: "Guo, Xiaoyi" Subject: Re: problem about Packet Redirect TLV encapsulation MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT hi,weiming, Joel said the padding after the last TLV must be zero. If the TLV section changes to the follow, it looks the padding for all TLVs should be zero instead of the last one, right? cheers, xiaoyi ----- Original Message ----- From: "Weiming Wang" Sent: Tuesday, January 17, 2006 10:43 PM Subject: Re: problem about Packet Redirect TLV encapsulation | Avri, | | Based on the discussion, I suggest changes as below: | | Page 32(Section 6.2): | | | TLV Value (variable): | The TLV Value field carries the data. For | extensibility, the TLV value may in fact be a TLV. | TLVs must be 32 bit aligned | | | | TLV Value (variable): | The TLV Value field carries the data. For | extensibility, the TLV value may in fact be a TLV. | TLVs must be 32 bit aligned. Padding used | for the alignment must be zero on transmission and must | be ignored upon reception. | | All types of TLVs used in this document follow the TLV rules described as | above. | | | Thanks, | Weiming | | From: "Jia Fenggen" | | > Agree,and for the consistency,i think the same rule applys to all the other | > TLVs. | > | > Yours,fenggen | > | > >From: "Joel M. Halpern" | > > | > >We probably should specify in the protocol spec that the padding | > >after the last TLV (if any such padding is need) must be zero on | > >transmission and must be ignored upon reception. | > > | > >Yours, | > >Joel | > > 2006 Message-Id: Date: Tue, 17 Jan 2006 22:43:32 +0800 From: Weiming Wang Subject: Re: problem about Packet Redirect TLV encapsulation Avri, Based on the discussion, I suggest changes as below: Page 32(Section 6.2): TLV Value (variable): The TLV Value field carries the data. For extensibility, the TLV value may in fact be a TLV. TLVs must be 32 bit aligned TLV Value (variable): The TLV Value field carries the data. For extensibility, the TLV value may in fact be a TLV. TLVs must be 32 bit aligned. Padding used for the alignment must be zero on transmission and must be ignored upon reception. All types of TLVs used in this document follow the TLV rules described as above. Thanks, Weiming From: "Jia Fenggen" > Agree,and for the consistency,i think the same rule applys to all the other > TLVs. > > Yours,fenggen > > >From: "Joel M. Halpern" > > > >We probably should specify in the protocol spec that the padding > >after the last TLV (if any such padding is need) must be zero on > >transmission and must be ignored upon reception. > > > >Yours, > >Joel > > 2006 Message-Id: Date: Tue, 17 Jan 2006 17:49:09 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Avri, Please incorparate the following text changes if theres no further comments. Thanks, Weiming 4.2. ForCES Protocol Phases ForCES, in relation to NEs, involves two phases: the Pre-Association phase where configuration/initialization/bootup of the TML and PL layer happens, and the association phase where the ForCES protocol operates to manipulate the parameters of the FEs. start FEObject Admin up -------+ +--->---->---->---->------->----+ | | Y Y | | | | Y +------+--+ +--------+ | | | | | DOWN | | UP | | State | | State | | | | | +---------+ +--------+ ^ Y | | +-<---<------<-----<------<----<---+ FEObject Admin Down/ Association lost Figure 4: The FE State Machine The FE can only be in one of two states as indicated above. When the FE is in the DOWN state, it is not forwarding packets. When the FE is in the UP state it may be forwarding packets depending on the configuration of its specific LFBs. On start up the FE is in the DOWN state unless explicitly configured by the CE to transition to the UP state. This MUST be done before configuring any other LFBs that affect packet forwarding. The FE transitions from the DOWN to the UP state when explicitly configured to do so by the CE or when it loses its association with the CE. For the FE to properly complete the transition to the DOWN state it MUST stop packet forwarding and that this may affect multiple LFBs. How this is achieved is outside the scope of this specification. 4.2. ForCES Protocol Phases ForCES, in relation to NEs, involves two phases: the Pre-Association phase where configuration/initialization/bootup of the TML and PL layer happens, and the Post-association phase where the ForCES protocol operates to manipulate the parameters of the FEs. FE start CE configures -------+ +--->---->---->---->------->----+ | | Y Y | | | | Y +------+--+ +--------+ | FE | | FE | | DOWN | | UP | | State | | State | | | | | +---------+ +--------+ ^ Y | | +-<---<------<-----<------<----<---+ CE configures or FE loses association Figure 4: The FE State Machine The FE can only be in one of two states as indicated above. When the FE is in the DOWN state, it is not forwarding packets. When the FE is in the UP state it may be forwarding packets depending on the configuration of its specific LFBs. CE configures FE states transitions by means of a so-called FEObject LFB, which is defined in [FE-MODEL] and also explained in Section 4.3.3 of this document. In FEObject LFB, FE state is defined as an attribute of the LFB, and CE configuration of the FE state equals CE configuration of this attribute. Note that even in the FE DOWN state, the FEObject LFB itself is active. On start up the FE is in the DOWN state unless explicitly configured by the CE to transition to the UP state. This must be done before configuring any other LFBs that affect packet forwarding. The FE transitions from the UP to the DOWN state when explicitly configured to do so by the CE or when FE loses its association with CE. Note that in the association lost case, FE can also possibly not go to DOWN state. Whether or not FE goes to DOWN state in this case depends on the policy CE sets for the FE to do when such failover happens. See the 'CE failover policy' part in Section 7.2.1 for more details on this. For the FE to properly complete the transition to the DOWN state it must stop packet forwarding and that this may affect multiple LFBs. How this is achieved is outside the scope of this specification. 2006 Message-Id: Date: Tue, 17 Jan 2006 14:43:57 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Hi, When discussing the FE state machine, I checked the FE model-05 for the FEObject definition and found that the 'FEState' has been defined as 'read-only', as: FEState model of this FE FEStatusValues And there are three FEstatusvalues defined as 'AdminDisable', 'OperDisable', and 'OperEnable'. To make the consistency, I think that the state attribute should be 'read-write', or a new 'read-write' attribute should be additively defined for 'FEState' (the original attribute can be called 'FEStatus'). And I also ask some explanation on the difference of 'AdminDisable' and 'OperDisable'. Thanks a lot. Weiming > > > > > The text doesnt say what causes the transition. Association lost > > > effect maybe one such reason after checking what the policy is. > > > Administrative choice maybe another. If this is not clear it should be. > > > I dont see a conflict - If the text is not clear it needs to be fixed. > > > > The original text has a strong feeling that association lost will lead to FE > > DOWN. > > > > We need to fix it then. > > [other in-context text deleted here ..] > > > But, anyway, please provide your proposals for the text modification then. > > > > I dont have time Weiming. I may disappear again for another 2-3 weeks > and that doesnt work well for the drafts progress. You understand where > i stand - propose the compromising text and pass it on to Avri and if i > have any issues with it i will raise them in the future. > > cheers, > jamal 2006 Message-Id: Date: Tue, 17 Jan 2006 13:36:19 +0800 From: Jia Fenggen Subject: Re: problem about Packet Redirect TLV encapsulation Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Agree,and for the consistency,i think the same rule applys to all the other TLVs. Yours,fenggen >From: "Joel M. Halpern" >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: problem about Packet Redirect TLV encapsulation >Date: Tue, 17 Jan 2006 00:27:17 -0500 > >We probably should specify in the protocol spec that the padding >after the last TLV (if any such padding is need) must be zero on >transmission and must be ignored upon reception. > >Yours, >Joel > >At 12:22 AM 1/17/2006, Jia Fenggen wrote: >>Thanks!Catched what you are saying. >>If I understand well then there will possibly be some padding >>octets in the final ForCES message in order to compy with the >>32bits alligment requriment and i may choose to use an arbitrary >>value for the padding purpose,am i right? >> >> >>>From: "Joel M. Halpern" >>>To: FORCES@PEACH.EASE.LSOFT.COM >>>Subject: Re: problem about Packet Redirect TLV encapsulation >>>Date: Mon, 16 Jan 2006 22:24:45 -0500 >>> >>>Evangelos was quite correct. >>>The length of the TLV (see section 6.2 at the top of page 31) is >>>in octets. The length of the total message is in DWORDs, (as >>>described on page 26) but that is not the relevant length. The >>>length field (the L portion of TLV) of the Redirect TLV gives the >>>length in octets of the packet being redirected. >>> >>>Yours, >>>Joel M. Halpern >>> >>>At 10:19 PM 1/16/2006, Jia Fenggen wrote: >>>>this conflict with the saying about the common header length >>>>definition(page 26 of the 06 draft),which says "length of header >>>>+ the rest of the message in DWORDS (4 byte increments)." And >>>>still i think there is the same probem with the metadata ILV >>>>especially when the meta data is not 32bits.what's you opinion? >>>> >>>>Yours,fenggen >> >>_________________________________________________________________ >>ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: >>http://messenger.msn.com/cn _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn 2006 Message-Id: Date: Tue, 17 Jan 2006 13:22:53 +0800 From: Jia Fenggen Subject: Re: problem about Packet Redirect TLV encapsulation Comments: To: joel@stevecrocker.com Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Thanks!Catched what you are saying. If I understand well then there will possibly be some padding octets in the final ForCES message in order to compy with the 32bits alligment requriment and i may choose to use an arbitrary value for the padding purpose,am i right? >From: "Joel M. Halpern" >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: problem about Packet Redirect TLV encapsulation >Date: Mon, 16 Jan 2006 22:24:45 -0500 > >Evangelos was quite correct. >The length of the TLV (see section 6.2 at the top of page 31) is in >octets. The length of the total message is in DWORDs, (as described >on page 26) but that is not the relevant length. The length field >(the L portion of TLV) of the Redirect TLV gives the length in >octets of the packet being redirected. > >Yours, >Joel M. Halpern > >At 10:19 PM 1/16/2006, Jia Fenggen wrote: >>this conflict with the saying about the common header length >>definition(page 26 of the 06 draft),which says "length of header + >>the rest of the message in DWORDS (4 byte increments)." And still i >>think there is the same probem with the metadata ILV especially >>when the meta data is not 32bits.what's you opinion? >> >>Yours,fenggen _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn 2006 Message-Id: Date: Tue, 17 Jan 2006 11:19:27 +0800 From: Jia Fenggen Subject: Re: problem about Packet Redirect TLV encapsulation Comments: To: ehalep@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Hi,Evangelos: According to your comments then we have non 32bits aligned redirect TLVs encapsulation in a Packet Redirect Message,the message is shown below: common header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |version| rsvd | Message Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlator | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message is 32 bit aligned.(page 26 of draft 06) Redirect TLVs: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Redirect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirect Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ this conflict with the saying about the common header length definition(page 26 of the 06 draft),which says "length of header + the rest of the message in DWORDS (4 byte increments)." And still i think there is the same probem with the metadata ILV especially when the meta data is not 32bits.what's you opinion? Yours,fenggen >From: "Evangelos Haleplidis" >To: "'Jia Fenggen'" >Subject: RE: problem about Packet Redirect TLV encapsulation >Date: Mon, 16 Jan 2006 17:46:54 +0200 > >Hello Jia, > >I'm not part of the WG and I'm not 100% sure, but I think that the answer to >your question lies with the definition of the TLV (page 31 of the 06 draft). >The Length field is measured in octects and includes the Type, the Length >and the Data without the padding. So, the actual packet is: Length-4. > >While this is not clearly stated in the draft I think this is what the WG >mean. If not then nothing can work correctly, because you cannot insert >variable size in a TLV. > >I hope this clears it up, > >Regards, > >Evangelos Haleplidis. > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jia Fenggen >Sent: Monday, January 16, 2006 10:44 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: problem about Packet Redirect TLV encapsulation > >Hi,all: > I have excerpt the following text from the draft-forces-protocol-6.txt >for easing my explanation: > > >Redirect Data TLV > > This is a TLV describing one packet of data to be directed via the > > redirect operation. The TLV format is as follows: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = REDIRECTDATA | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Redirected Data | > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Redirected Data: > > This field presents the whole packet that is to be redirected. > > The packet should be 32bits aligned. > > >my question is: > how to use the above TLV to express the vary sized redirect packet?since >the length field is the total length of the padded redirect packet in quad >words including the type and length field, when CE receive such a redirect >packet,it can't infer from the TLV how long the redirect packet really >is,should we further define the Redirect Data to include the real length of >the redirect packet? > >Yours,fenggen > >_________________________________________________________________ >ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn > > _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn 2006 Message-Id: Date: Tue, 17 Jan 2006 07:46:39 -0500 From: "Joel M. Halpern" Subject: Re: [issue76] Comments from Alex Comments: To: "Wang,Weiming" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sounds like a good idea to me. I will put it on the list of things to do. Joel At 01:43 AM 1/17/2006, Wang,Weiming wrote: >Hi, > >When discussing the FE state machine, I checked the FE model-05 for the >FEObject >definition and found that the 'FEState' has been defined as 'read-only', as: > > > FEState > model of this FE > FEStatusValues > > >And there are three FEstatusvalues defined as 'AdminDisable', >'OperDisable', and >'OperEnable'. > >To make the consistency, I think that the state attribute should be >'read-write', or a new 'read-write' attribute should be additively defined for >'FEState' (the original attribute can be called 'FEStatus'). And I also >ask some >explanation on the difference of 'AdminDisable' and 'OperDisable'. Thanks >a lot. > >Weiming 2006 Message-Id: Date: Tue, 17 Jan 2006 00:27:17 -0500 From: "Joel M. Halpern" Subject: Re: problem about Packet Redirect TLV encapsulation Comments: To: Jia Fenggen Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable We probably should specify in the protocol spec that the padding after the= =20 last TLV (if any such padding is need) must be zero on transmission and=20 must be ignored upon reception. Yours, Joel At 12:22 AM 1/17/2006, Jia Fenggen wrote: >Thanks!Catched what you are saying. >If I understand well then there will possibly be some padding octets in=20 >the final ForCES message in order to compy with the 32bits alligment=20 >requriment and i may choose to use an arbitrary value for the padding=20 >purpose,am i right? > > >>From: "Joel M. Halpern" >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Re: problem about Packet Redirect TLV encapsulation >>Date: Mon, 16 Jan 2006 22:24:45 -0500 >> >>Evangelos was quite correct. >>The length of the TLV (see section 6.2 at the top of page 31) is in=20 >>octets. The length of the total message is in DWORDs, (as described on=20 >>page 26) but that is not the relevant length. The length field (the L=20 >>portion of TLV) of the Redirect TLV gives the length in octets of the=20 >>packet being redirected. >> >>Yours, >>Joel M. Halpern >> >>At 10:19 PM 1/16/2006, Jia Fenggen wrote: >>>this conflict with the saying about the common header length=20 >>>definition(page 26 of the 06 draft),which says "length of header + the=20 >>>rest of the message in DWORDS (4 byte increments)." And still i think=20 >>>there is the same probem with the metadata ILV especially when the meta= =20 >>>data is not 32bits.what's you opinion? >>> >>>Yours,fenggen > >_________________________________________________________________ >=D3=EB=C1=AA=BB=FA=B5=C4=C5=F3=D3=D1=BD=F8=D0=D0=BD=BB=C1=F7=A3=AC=C7=EB=CA= =B9=D3=C3 MSN Messenger: http://messenger.msn.com/cn 2006 Message-Id: Date: Mon, 16 Jan 2006 22:24:45 -0500 From: "Joel M. Halpern" Subject: Re: problem about Packet Redirect TLV encapsulation Comments: To: Jia Fenggen Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Evangelos was quite correct. The length of the TLV (see section 6.2 at the top of page 31) is in octets. The length of the total message is in DWORDs, (as described on page 26) but that is not the relevant length. The length field (the L portion of TLV) of the Redirect TLV gives the length in octets of the packet being redirected. Yours, Joel M. Halpern At 10:19 PM 1/16/2006, Jia Fenggen wrote: >this conflict with the saying about the common header length >definition(page 26 of the 06 draft),which says "length of header + the >rest of the message in DWORDS (4 byte increments)." And still i think >there is the same probem with the metadata ILV especially when the meta >data is not 32bits.what's you opinion? > >Yours,fenggen 2006 Message-Id: Date: Mon, 16 Jan 2006 17:17:48 -0500 From: Abid Ghufran Subject: Need Help ! (ForCES for my MSc dissertation) Dear All, I am doing MSc in High Speed Networks and Distributed Systems, from Oxford Brookes University UK. For my dissertation I intend to take "something from the" ForCES protocol. After going through the standard documents on this protocol, I have found it very interesting and am therfore thinking of finally deciding for it. There is a condition for my dissertation, that it should involve both networking and programming related to distributed systems. I have found the ForCES concept to be covering both of these requirements. But before I finally decide, I would like some advise from the people on this list. 1) I have found that the protocol concept has a very extensive and a wide scope. I shall only be having 3 months for my dissertation. Of all the elements included in this concept of ForCES protocol, which aspect should be mose suitable for my dissertation? In simple words there are many things involved in the ForCES, which of them should I aim at, for my dissertation? 2) Can I consider this protocol as similar to an out-of-band signalling model for coordination between the CE, FE and LFBs? 3) I feel that this concept will see prevalent usage in the networking field. What do you think? 4) Are there any vendors thinking or planning to incorporate this concept? 5) What kind of language platform/functionality would be deemed suitable for the implementation of this protocol? 6) Is it possilbe to study/analyze the protocol by simulating it? Which of its aspect could be simulated? I shall be most grateful if you could help me in this regard. Thank you very much, Abid Ghufran. 2006 Message-Id: Date: Mon, 16 Jan 2006 16:44:14 +0800 From: Jia Fenggen Subject: problem about Packet Redirect TLV encapsulation Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Hi,all: I have excerpt the following text from the draft-forces-protocol-6.txt for easing my explanation: >Redirect Data TLV > This is a TLV describing one packet of data to be directed via the > redirect operation. The TLV format is as follows: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = REDIRECTDATA | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Redirected Data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >Redirected Data: > This field presents the whole packet that is to be redirected. > The packet should be 32bits aligned. > my question is: how to use the above TLV to express the vary sized redirect packet?since the length field is the total length of the padded redirect packet in quad words including the type and length field, when CE receive such a redirect packet,it can't infer from the TLV how long the redirect packet really is,should we further define the Redirect Data to include the real length of the redirect packet? Yours,fenggen _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn 2006 Message-Id: Date: Mon, 16 Jan 2006 12:26:20 +0100 From: Tom Petch Subject: Re: Model Draft: events comments Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Joel M. Halpern" Sent: Thursday, January 12, 2006 3:48 PM Subject: Re: Model Draft: events comments > I have trouble envisioning a situation in which a packet directly produces > an event. One would not have an event tied to the bad IP header event. > >From a management perspective, you are asking if there are single packets which are so momentous in their impact that they need immediate attention. I believe there are, or will be, for example in signalling, such as congestion notification or packets that indicate substantial changes to the topology. I also hear a concern about how feasible it is to implement such as '3 events in 5 minutes' to which I suspect the answer is feasible when they are based on a pre-existing timers - such as TimeTicks in SNMP - and on shift/add, as opposed to anything resembling decimal arithmetic. Over the years, SNMP has got much more sophisticated in the ability of a user to tailor what it is they need to know to run a network - eg the work of rmon/disman - and it would be a shame to lose that. Tom Petch 2006 Message-Id: Date: Fri, 13 Jan 2006 23:34:25 +0800 From: Weiming Wang Subject: Re: [issue76] Comments from Alex Jamal, > Thats fine Weiming. Since you feel strongly about the current text, go > ahead and make the changes and before final call i will make sure to > review. I simply dont have time at the moment. > That's ok then. How about the update for Section 4.3 based on our previous discussions then? I can try to make it but I have to take some time. I do hope you can do some of it before you disappear for a moment. Note the time even for the 63th meeting is closing, I'm just a little worry. Thanks, Weiming 2006 Message-Id: Date: Fri, 13 Jan 2006 13:24:18 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Comments: To: hadi@znyx.com Jamal, > > But, anyway, please provide your proposals for the text modification then. > > > > I dont have time Weiming. I may disappear again for another 2-3 weeks > and that doesnt work well for the drafts progress. You understand where > i stand - propose the compromising text and pass it on to Avri and if i > have any issues with it i will raise them in the future. The text I provided is my proposed text for the update, but it seems you are not satisfied with the text generally. I can only do modification of the text based on your comments, I cannot provide a new one for the whole modification. If you are generally not satisfied with the text I provided last time, I suggest you provide a new one for this, which may not take you too much time. Thanks, Weiming 2006 Message-Id: Date: Fri, 13 Jan 2006 09:47:37 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue76] Comments from Alex Comments: To: "Wang,Weiming" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Fri, 2006-13-01 at 13:24 +0800, Wang,Weiming wrote: > The text I provided is my proposed text for the update, but it seems you are not > satisfied with the text generally. I can only do modification of the text based > on your comments, I cannot provide a new one for the whole modification. Thats fine Weiming. Since you feel strongly about the current text, go ahead and make the changes and before final call i will make sure to review. I simply dont have time at the moment. cheers, jamal 2006 Message-Id: Date: Fri, 13 Jan 2006 09:45:38 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Event Generation Conditions Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Thu, 2006-12-01 at 19:55 -0500, Joel M. Halpern wrote: > Yes, the alternative to adding this capability to events is that folks who > have specific need for information with this property can use LFBs (one or > more) to produce and limit the delivery of meta-data through the redirect > channel. > I think going into some metadata LFB only for certain events (but having all other attributes defined some other way) is overboard almost to implementation details. We dont need to define timers that work with these events just a spec that defines time. Folks, this is a real generic requirement to scale events. cheers, jamal 2006 Message-Id: Date: Fri, 13 Jan 2006 09:16:48 +0100 From: Patrick Droz Organization: IBM Research Division Subject: MIB Draft issue Comments: cc: "Putzolu, David" , Bill Fenner , Alex Zinin MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080308030905070409040705" This is a cryptographically signed message in MIME format. --------------ms080308030905070409040705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Shortly before Christmas holiday the chairs asked the opinion on the list concerning the adoption of the MIB draft as a ForCES WG. Feedback has been positive on the list thus far. In order to close this issues we would like to set a deadline as follows: Please submit any further feedback by January 21st 06, at which time we will evaluate the group consensus on this matter. David and Patrick --------------ms080308030905070409040705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6jCC BSwwggSVoAMCAQICEDhxwVOTyOj0nx4MTQ30ZkMwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykg MTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4XDTAzMDUwNjAwMDAwMFoXDTA4MDUwNTIzNTk1 OVowgfkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1h Y2hpbmVzIENvcnBvcmF0aW9uMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwMzEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANVnrTXdoH79V2HWnacXy7mjjSNcnOi3Z+cXSBh9uSDhCLAUUeuvoHub uA5ImrJI5k/dA+Q0L+WNzR7OZr4TRpw3DOksYS/0o+RZ5+luJ7ltXcdVgsHU6qqHDpvF1hAe gqpNz670JVVfUs4ThC1AafMIBHwmJbqFG4Iy39OH37oBAgMBAAGjggHpMIIB5TASBgNVHRMB Af8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8v Y3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEB BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEyNzAdBgNV HQ4EFgQUkcFzsHPV2ZJ0Z80b8VEUNDG2LFowgegGA1UdIwSB4DCB3aGBx6SBxDCBwTELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1 YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShj KSAxOTk4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmuCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAA4GBAAgYBRMDGzUl8C495yDmyE78QHSxQjkpKbJ61i0GkSYGUmkRYc3czKUlkV3s dHWe28su0SRO8HKhXzfUdR2D2n6UixORmR/tobmuxlkfwqHWDvNVuJD0iCV1e2cXT9qf38vM zMiC55lQmnCoUfTg131ovM/V1EI2aT181HWu/pM8MIIFWTCCBMKgAwIBAgIQJSBAG0BqCBRf YEFUSgK+mTANBgkqhkiG9w0BAQQFADCB+TELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTAzMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0ExJDAiBgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTAeFw0wNTA5MTMwMDAwMDBaFw0wNjA5MTMyMzU5NTlaMIGFMS4wLAYDVQQKFCVJbnRl cm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnAuMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBFAkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzY/XBh1oeyjfCK5XtJf8 x4gwxYZE2Fdv28a2WVGy71OyQm1G9T2npUUH2AE4ywrZmOXeZ4o1kltzBwZ8p1gA9e9YAyue 49wzt6nd/4pWlg9S2uVNL7tckQ9sb7RLbBEywjpXPI7a6OqPUjh9NPNva8SzaDDr9X7kuooR fKjdqw8CAwEAAaOCAlIwggJOMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgMGYGA1UdHwRfMF0w W6BZoFeGVWh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0ludGVybmF0aW9uYWxCdXNp bmVzc01hY2hpbmVzQ29ycENvcnBvcmF0ZUNJTy9MYXRlc3RDUkwwggEpBgNVHSAEggEgMIIB HDCCARgGC2CGSAGG+EUBBxcCMIIBBzArBggrBgEFBQcCARYfaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL3JwYS1rcjCB1wYIKwYBBQUHAgIwgcoagcdOb3RpY2UgVGV4dD1OT1RJQ0U6IFBy aXZhdGUga2V5IG1heSBiZSByZWNvdmVyZWQgYnkgVmVyaVNpZ24ncyBjdXN0b21lciB3aG8g bWF5IGJlIGFibGUgdG8gZGVjcnlwdCBtZXNzYWdlcyB5b3Ugc2VuZCB0byBjZXJ0aWZpY2F0 ZSBob2xkZXIuICBVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyMB8GA1UdIwQYMBaAFJHBc7Bz1dmSdGfNG/FRFDQxtixaMB0GA1Ud DgQWBBT1SwvrAN7a2KY54Zg5FdemL/4+QDAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwS ZHJvQHp1cmljaC5pYm0uY29tMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBglg hkgBhvhCAQEEBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAajRRbaYOGmyMgkHnwcEJIZsBSZbv O3uZO6weMCnPim/YUrYz8QIuyTYzV32bH1k0QhOnjSeHlUKxQBiSnyRmu/4lVvTOckqpUM3T sQibi+vQR/bOdP/CqC6n8MY55X74949PjFkX0Qdd5W5C1IkMTe6UOABFUDfvv19S22JebB0w ggVZMIIEwqADAgECAhAlIEAbQGoIFF9gQVRKAr6ZMA0GCSqGSIb3DQEBBAUAMIH5MQswCQYD VQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jw b3JhdGlvbjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDMxMDAuBgNV BAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEkMCIGA1UEAxMb SUJNIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MDkxMzAwMDAwMFoXDTA2MDkxMzIz NTk1OVowgYUxLjAsBgNVBAoUJUludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29y cC4xFTATBgNVBAMTDFBhdHJpY2sgRHJvejEZMBcGCgmSJomT8ixkAQEUCTMzMTkwMzg0ODEh MB8GCSqGSIb3DQEJARYSZHJvQHp1cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDNj9cGHWh7KN8Irle0l/zHiDDFhkTYV2/bxrZZUbLvU7JCbUb1PaelRQfYATjL CtmY5d5nijWSW3MHBnynWAD171gDK57j3DO3qd3/ilaWD1La5U0vu1yRD2xvtEtsETLCOlc8 jtro6o9SOH00829rxLNoMOv1fuS6ihF8qN2rDwIDAQABo4ICUjCCAk4wCQYDVR0TBAIwADAL BgNVHQ8EBAMCBaAwZgYDVR0fBF8wXTBboFmgV4ZVaHR0cDovL29uc2l0ZWNybC52ZXJpc2ln bi5jb20vSW50ZXJuYXRpb25hbEJ1c2luZXNzTWFjaGluZXNDb3JwQ29ycG9yYXRlQ0lPL0xh dGVzdENSTDCCASkGA1UdIASCASAwggEcMIIBGAYLYIZIAYb4RQEHFwIwggEHMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMIHXBggrBgEFBQcCAjCByhqB x05vdGljZSBUZXh0PU5PVElDRTogUHJpdmF0ZSBrZXkgbWF5IGJlIHJlY292ZXJlZCBieSBW ZXJpU2lnbidzIGN1c3RvbWVyIHdobyBtYXkgYmUgYWJsZSB0byBkZWNyeXB0IG1lc3NhZ2Vz IHlvdSBzZW5kIHRvIGNlcnRpZmljYXRlIGhvbGRlci4gIFVzZSBpcyBzdWJqZWN0IHRvIHRl cm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwHwYDVR0jBBgwFoAUkcFz sHPV2ZJ0Z80b8VEUNDG2LFowHQYDVR0OBBYEFPVLC+sA3trYpjnhmDkV16Yv/j5AMC0GA1Ud EQQmMCSgIgYKKwYBBAGCNxQCA6AUDBJkcm9AenVyaWNoLmlibS5jb20wHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMBEGCWCGSAGG+EIBAQQEAwIFoDANBgkqhkiG9w0BAQQFAAOB gQBqNFFtpg4abIyCQefBwQkhmwFJlu87e5k7rB4wKc+Kb9hStjPxAi7JNjNXfZsfWTRCE6eN J4eVQrFAGJKfJGa7/iVW9M5ySqlQzdOxCJuL69BH9s50/8KoLqfwxjnlfvj3j0+MWRfRB13l bkLUiQxN7pQ4AEVQN++/X1LbYl5sHTGCBLcwggSzAgEBMIIBDjCB+TELMAkGA1UEBhMCVVMx NDAyBgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAzMTAwLgYDVQQLEydDbGFz cyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eQIQJSBAG0BqCBRfYEFUSgK+mTAJBgUrDgMCGgUAoIIC/TAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAxMTMwODE2NDha MCMGCSqGSIb3DQEJBDEWBBSM4QDaU3juRhohVdYPfrC++x5cjTBSBgkqhkiG9w0BCQ8xRTBD MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDCCASEGCSsGAQQBgjcQBDGCARIwggEOMIH5MQswCQYDVQQGEwJVUzE0 MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDMxMDAuBgNVBAsTJ0NsYXNz IDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEkMCIGA1UEAxMbSUJNIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5AhAlIEAbQGoIFF9gQVRKAr6ZMIIBIwYLKoZIhvcNAQkQAgsx ggESoIIBDjCB+TELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5l c3MgTWFjaGluZXMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTAzMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExJDAiBgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQJSBAG0BqCBRf YEFUSgK+mTANBgkqhkiG9w0BAQEFAASBgC4VkrlsvxiCUpTapjccSWrxKeqEITNV2Xm2Z8bo olYBgco0ke8Qqp68o5D5tSmyxfViHMZFFL4Qp/naM///sGR0EOvgJDDLBT0hptULA9bjeIYg zAVtcsAv/tQtRrh1juoJchXPqSz9WWyCcjLrR5+T0dl+PW1N45g62ywnKbCCAAAAAAAA --------------ms080308030905070409040705-- 2006 Message-Id: Date: Thu, 12 Jan 2006 19:55:58 -0500 From: "Joel M. Halpern" Subject: Re: Event Generation Conditions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Yes, the alternative to adding this capability to events is that folks who have specific need for information with this property can use LFBs (one or more) to produce and limit the delivery of meta-data through the redirect channel. Yours, Joel At 07:46 PM 1/12/2006, Putzolu, David wrote: >I wonder could a specific LFB be design to support this, >perhaps being metadata based? > >E.g. write a LFB definition that has all sorts of knobs >for timers, and is driven by metadata being fed into it. >Then one could use a classifier LFB to feed metadata to >the "timer LFB", which would then generate the desired >events. Those FEs that do not have the required complex >timer capabilities would simply not expose the LFB in >question. > >-David > >P.S. I guess you where referring to something similar with >the ICMP rate limiter idea, although I was thinking of a >specific programmable "metadata that generates events" LFB. > > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Thursday, January 12, 2006 3:54 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Event Generation Conditions > >The current draft of the model provides for simple event detection >conditions. >It also provides for optional hysteresis to suppress repeated generation >of >events. > >Jamal has asked for a combined duration / count condition which will >generate the event notification if either the event occurs enough times, >or >enough time passes since the last generation. > >While he and I disagree as to the need for this, what really matters >here >is what the rest of the working group thinks. > >My concern is that this support will require more complex timer >capabilities in the FE. >Jamal feels the capability has more value than the complexity. > >Does anyone else care? > >As the old song goes, "is anybody there?" > >Yours, >Joel 2006 Message-Id: Date: Thu, 12 Jan 2006 18:53:57 -0500 From: "Joel M. Halpern" Subject: Event Generation Conditions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The current draft of the model provides for simple event detection conditions. It also provides for optional hysteresis to suppress repeated generation of events. Jamal has asked for a combined duration / count condition which will generate the event notification if either the event occurs enough times, or enough time passes since the last generation. While he and I disagree as to the need for this, what really matters here is what the rest of the working group thinks. My concern is that this support will require more complex timer capabilities in the FE. Jamal feels the capability has more value than the complexity. Does anyone else care? As the old song goes, "is anybody there?" Yours, Joel 2006 Message-Id: Date: Thu, 12 Jan 2006 16:46:25 -0800 From: "Putzolu, David" Subject: Re: Event Generation Conditions Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wonder could a specific LFB be design to support this,=20 perhaps being metadata based? E.g. write a LFB definition that has all sorts of knobs=20 for timers, and is driven by metadata being fed into it.=20 Then one could use a classifier LFB to feed metadata to the "timer LFB", which would then generate the desired events. Those FEs that do not have the required complex timer capabilities would simply not expose the LFB in=20 question. -David P.S. I guess you where referring to something similar with the ICMP rate limiter idea, although I was thinking of a specific programmable "metadata that generates events" LFB. -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, January 12, 2006 3:54 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Event Generation Conditions The current draft of the model provides for simple event detection conditions. It also provides for optional hysteresis to suppress repeated generation of=20 events. Jamal has asked for a combined duration / count condition which will=20 generate the event notification if either the event occurs enough times, or=20 enough time passes since the last generation. While he and I disagree as to the need for this, what really matters here=20 is what the rest of the working group thinks. My concern is that this support will require more complex timer=20 capabilities in the FE. Jamal feels the capability has more value than the complexity. Does anyone else care? As the old song goes, "is anybody there?" Yours, Joel 2006 Message-Id: Date: Thu, 12 Jan 2006 11:28:11 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex > From: "Jamal Hadi Salim" > The text doesnt say what causes the transition. Association lost > effect maybe one such reason after checking what the policy is. > Administrative choice maybe another. If this is not clear it should be. > I dont see a conflict - If the text is not clear it needs to be fixed. The original text has a strong feeling that association lost will lead to FE DOWN. > > | | > > +-<---<------<-----<------<----<---+ > > CE configure or FE association lost > > > > And while it is true: > - "CE Configure" is insufficient - it doesnt say what is being > configured (original text did) original text has a feeling that it is to let FEObject LFB up to let the FE UP and let FEObject LFB down to let FE DOWN. Another is theres no FEObject definition before the figure in the draft, hense if you use the original text, you should mention the FEObject LFB in the followed text. Note that the original text does not mention FEObject anymore except in the figure. > - "FE Association lost" suffers from the same problem. Theres some, but it depends on the text followed to explain the figure. > > The FE is down by default on startup. Only after the association has > happened can the CE configure it to be up. Yes, the text does not conflict with this. > I agree with the general principle of mentioning the relation of the > Admin state to what can force transitions - but i think the text above > may be getting into a lot more details on the FEObject LFB than is > necessary. I think it is necessary, or else, it is hard for readers to understand how this state machine matches the actual operations the draft provides (many of my implementation team members have asked about this question). But, anyway, please provide your proposals for the text modification then. Thanks, Weiming 2006 Message-Id: Date: Thu, 12 Jan 2006 11:18:55 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model Draft: events comments Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Thu, 2006-12-01 at 10:38 -0500, Joel M. Halpern wrote: > I think that this may be better addressed with a custom LFB that generates > a redirect packet with meta-data. (it probably would actually produce a > smaller packet, too...) Let me position it differently: Consider a packet arrival at the FE that updates a table row. Say i am interested in such an update for the purposes of updating another FEs (backup) so the table states between them are synced. I believe this would be a generic desire and not one that necessitates a custom LFB. > For one thing, as you describe it this can probably cope with loss or > significant delay in reporting. indeed - it is a trade off. The longer you wait for the updates, the longer it would take to failover or the more compute/bandwidth it would take etc. So let the CE control those two knobs as configured by the admin. > The events use the reliable control channel. We could use a reliable channel but it is unnecessary. You can afford to loose some of these updates (as you stated above) since they tend to be accumulative updates of some table entry. A reliable channel will retransmit obsolete knowledge under congestion. > Also, the number of variables I can imagine for synchronization are much > higher than I think makes sense for event reporting. > > I would like to keep the amount of state that the FE needs to keep for each > event small. Since one assumes the FE has whatever the current state is, > and has the information as to the definition of the event, hysteresis only > requires one extra bit. > > A reseting counter only seems useful if it also has a time limit. Time > limits imply timers per event. This is implementation details really not architectural concerns. Weiming and I have had long debates on the timers - and depending on how you implement your timers, yes you could suffer. > I fear that could increase the complexity > noticeably (many boxes I have built have had limits on the numbers of > timers they could implement efficiently.) > I think every box would have a limit, no doubt. Most contentious issue i have come across is RAM - at least on Linux[1]. My fear at the moment (based on experience) is the scalability of a Forces cluster because we decided not to add event congestion control. cheers, jamal [1]I can do hundreds of thousands of flows in Linux today each monitored by a timer or two without any problems. I would rather pay for the extra RAM than worry about overwhelming the CE with just a few hundred FEs only. 2006 Message-Id: Date: Thu, 12 Jan 2006 10:38:33 -0500 From: "Joel M. Halpern" Subject: Re: Model Draft: events comments Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I think that this may be better addressed with a custom LFB that generates a redirect packet with meta-data. (it probably would actually produce a smaller packet, too...) For one thing, as you describe it this can probably cope with loss or significant delay in reporting. The events use the reliable control channel. Also, the number of variables I can imagine for synchronization are much higher than I think makes sense for event reporting. I would like to keep the amount of state that the FE needs to keep for each event small. Since one assumes the FE has whatever the current state is, and has the information as to the definition of the event, hysteresis only requires one extra bit. A reseting counter only seems useful if it also has a time limit. Time limits imply timers per event. I fear that could increase the complexity noticeably (many boxes I have built have had limits on the numbers of timers they could implement efficiently.) Yours, Joel At 09:59 AM 1/12/2006, Jamal Hadi Salim wrote: >On Thu, 2006-12-01 at 09:48 -0500, Joel M. Halpern wrote: > > I have trouble envisioning a situation in which a packet directly produces > > an event. One would not have an event tied to the bad IP header event. > > > >Think of a scenario where an arriving packet possesses some state that >is needed to be synced in with another FE for HA purposes. > > > The case where this sort of thing comes up is with redirected > > packets. Many routers support rate limiting specific sets of packets > (ICMP > > for example) to the control processor. ForCES needs to support that. But > > that is a data plane event. It would be done with a meter applied to > > either the aggregate ICMP to the CE or on a per-flow basis for ICMPs to > the > > CE (implemenation / CE choice). Assuming (as we should) that we have a > > meter LFB, the CE can include that in the data path and provide the > > appropriate control. > > > > To phrase it differently, any condition which can be provoked by a single > > data packet should not result in an event. Redirect with meta-data will > > handle such circumstances better. > > > >Refer to what i said above. It's for state synchronization. You dont >need the whole packet[1] - you need a few small pieces of bits and bytes >of info from it. > >cheers, >jamal >[1]so redirect is a really bad way of doing this, not wrong - just dumb >because it would need a lot more resources (both compute and bandwidth). 2006 Message-Id: Date: Thu, 12 Jan 2006 09:59:24 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model Draft: events comments Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Thu, 2006-12-01 at 09:48 -0500, Joel M. Halpern wrote: > I have trouble envisioning a situation in which a packet directly produces > an event. One would not have an event tied to the bad IP header event. > Think of a scenario where an arriving packet possesses some state that is needed to be synced in with another FE for HA purposes. > The case where this sort of thing comes up is with redirected > packets. Many routers support rate limiting specific sets of packets (ICMP > for example) to the control processor. ForCES needs to support that. But > that is a data plane event. It would be done with a meter applied to > either the aggregate ICMP to the CE or on a per-flow basis for ICMPs to the > CE (implemenation / CE choice). Assuming (as we should) that we have a > meter LFB, the CE can include that in the data path and provide the > appropriate control. > > To phrase it differently, any condition which can be provoked by a single > data packet should not result in an event. Redirect with meta-data will > handle such circumstances better. > Refer to what i said above. It's for state synchronization. You dont need the whole packet[1] - you need a few small pieces of bits and bytes of info from it. cheers, jamal [1]so redirect is a really bad way of doing this, not wrong - just dumb because it would need a lot more resources (both compute and bandwidth). 2006 Message-Id: Date: Thu, 12 Jan 2006 09:48:59 -0500 From: "Joel M. Halpern" Subject: Re: Model Draft: events comments Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I have trouble envisioning a situation in which a packet directly produces an event. One would not have an event tied to the bad IP header event. The case where this sort of thing comes up is with redirected packets. Many routers support rate limiting specific sets of packets (ICMP for example) to the control processor. ForCES needs to support that. But that is a data plane event. It would be done with a meter applied to either the aggregate ICMP to the CE or on a per-flow basis for ICMPs to the CE (implemenation / CE choice). Assuming (as we should) that we have a meter LFB, the CE can include that in the data path and provide the appropriate control. To phrase it differently, any condition which can be provoked by a single data packet should not result in an event. Redirect with meta-data will handle such circumstances better. Yours, Joel M. Halpern At 09:40 AM 1/12/2006, you wrote: >On Wed, 2006-11-01 at 17:53 -0500, Joel M. Halpern wrote: > > I think that is simply much too complicated. > > To put it differently, I don't think that is a threshold that the CE will > > want to respond to. That is the kind of thing that a management system > > provides so that Human beings can respond to truly anomalous > > occurrences. > >In our case the reasoning has to do with performance and not Human >interaction. > >Assume a worst case scenario (without saying what specific LFB would do >this): >Every time a packet of a certain flow arrives, an event to the FE is >generated. Imagine further this is a high throughput flow and add to >that the fact you have several thousand such flows. >The amount of events that could be generated to the CE by such a LFB >would be horrendously high. > > > I don't think we need that much power on the FE-CE > > interface. I do want to avoid excessive notifications (which is why I put > > in the hysteresis, and I am willing to look at other modest controls.) > > > >If you can show me how the above problem is solved by the hysteris you >scheme proposed or other additional controls, that would suffice. > >cheers, >jamal 2006 Message-Id: Date: Thu, 12 Jan 2006 09:45:03 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue76] Comments from Alex Comments: To: "Wang,Weiming" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Thu, 2006-12-01 at 11:28 +0800, Wang,Weiming wrote: > > From: "Jamal Hadi Salim" > > > The text doesnt say what causes the transition. Association lost > > effect maybe one such reason after checking what the policy is. > > Administrative choice maybe another. If this is not clear it should be. > > I dont see a conflict - If the text is not clear it needs to be fixed. > > The original text has a strong feeling that association lost will lead to FE > DOWN. > We need to fix it then. [other in-context text deleted here ..] > But, anyway, please provide your proposals for the text modification then. > I dont have time Weiming. I may disappear again for another 2-3 weeks and that doesnt work well for the drafts progress. You understand where i stand - propose the compromising text and pass it on to Avri and if i have any issues with it i will raise them in the future. cheers, jamal 2006 Message-Id: Date: Thu, 12 Jan 2006 09:40:03 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model Draft: events comments Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Wed, 2006-11-01 at 17:53 -0500, Joel M. Halpern wrote: > I think that is simply much too complicated. > To put it differently, I don't think that is a threshold that the CE will > want to respond to. That is the kind of thing that a management system > provides so that Human beings can respond to truly anomalous > occurrences. In our case the reasoning has to do with performance and not Human interaction. Assume a worst case scenario (without saying what specific LFB would do this): Every time a packet of a certain flow arrives, an event to the FE is generated. Imagine further this is a high throughput flow and add to that the fact you have several thousand such flows. The amount of events that could be generated to the CE by such a LFB would be horrendously high. > I don't think we need that much power on the FE-CE > interface. I do want to avoid excessive notifications (which is why I put > in the hysteresis, and I am willing to look at other modest controls.) > If you can show me how the above problem is solved by the hysteris you scheme proposed or other additional controls, that would suffice. cheers, jamal 2006 Message-Id: Date: Wed, 11 Jan 2006 17:53:08 -0500 From: "Joel M. Halpern" Subject: Re: Model Draft: events comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I think that is simply much too complicated. To put it differently, I don't think that is a threshold that the CE will want to respond to. That is the kind of thing that a management system provides so that Human beings can respond to truly anomalous occurrences. I don't think we need that much power on the FE-CE interface. I do want to avoid excessive notifications (which is why I put in the hysteresis, and I am willing to look at other modest controls.) Yours, Joel At 05:23 PM 1/11/2006, you wrote: >Joel, > >apologies for taking so long to post. >Let me start with the most important concern and then later go into the >little issues in other emails (I have to run unfortunately): > >Generally, I think there is a lot of good thinking that went into the >events descriptions - so kudos. > >My desire is to have a nagle-like feature such that one can define >thresholds for events; example >"tell me when 3 such events occur or every five minutes" > >Thoughts? > >cheers, >jamal 2006 Message-Id: Date: Wed, 11 Jan 2006 17:23:23 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Model Draft: events comments Comments: cc: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Joel, apologies for taking so long to post. Let me start with the most important concern and then later go into the little issues in other emails (I have to run unfortunately): Generally, I think there is a lot of good thinking that went into the events descriptions - so kudos. My desire is to have a nagle-like feature such that one can define thresholds for events; example "tell me when 3 such events occur or every five minutes" Thoughts? cheers, jamal 2006 Message-Id: Date: Wed, 11 Jan 2006 17:13:13 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue76] Comments from Alex Comments: To: "Wang,Weiming" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Wed, 2006-11-01 at 16:22 +0800, Wang,Weiming wrote: > Jamal, > > On the state machine, my question mainly lies in the expression that the > association lost will lead to FE to DOWN state. The text doesnt say what causes the transition. Association lost effect maybe one such reason after checking what the policy is. Administrative choice maybe another. If this is not clear it should be. > This is not the scheme that we currently apply in the draft. I dont see a conflict - If the text is not clear it needs to be fixed. > I agree with you that the state machine only deals > with the FE as a whole, therefore it can observe FE only with UP and DOWN, but > some expression should be modified so as to make the state machine not conflict > with other part of the protocol draft. Another expression that may lead to > confusion is the text'FEObject Admin up' and the 'FEObject Admin down' in the > figure. This can easily be taken as 'to start FEObject LFB will make FE UP, to > shutdown the FEObject LFB will make FE DOWN'. I don't think this is the case. > The true is FEObject LFB will always be there after FE is electrically started. > The FE UP or FE DOWN state is only managed as an attribute of the FEObject LFB, > which can be configured by CE. > Yes, this is true. > Based on my above views, I suggest the following modifications: > > 1. modify the figure > start FEObject Admin up > -------+ +--->---->---->---->------->----+ > | | Y > Y | | > | | Y > +------+--+ +--------+ > | | | | > | DOWN | | UP | > | State | | State | > | | | | > +---------+ +--------+ > ^ Y > | | > +-<---<------<-----<------<----<---+ > FEObject Admin Down/ > Association lost > > to a figure as: > > FE start CE configure > -------+ +--->---->---->---->------->----+ > | | Y > Y | | > | | Y > +------+--+ +--------+ > | FE | | FE | > | DOWN | | UP | > | State | | State | > | | | | > +---------+ +--------+ > ^ Y > | | > +-<---<------<-----<------<----<---+ > CE configure or FE association lost > And while it is true: - "CE Configure" is insufficient - it doesnt say what is being configured (original text did) - "FE Association lost" suffers from the same problem. > 2. Accordingly make modifications in the followed text > > Original: > > The FE can only be in one of two states as indicated above. When the > FE is in the DOWN state, it is not forwarding packets. When the FE > is in the UP state it may be forwarding packets depending on the > configuration of its specific LFBs. > > On start up the FE is in the DOWN state unless explicitly configured > by the CE to transition to the UP state. This MUST be done before > configuring any other LFBs that affect packet forwarding. > > The FE transitions from the DOWN to the UP state when explicitly > configured to do so by the CE or when it loses its association with > the CE. For the FE to properly complete the transition to the DOWN > state it MUST stop packet forwarding and that this may affect > multiple LFBs. How this is achieved is outside the scope of this > specification. > > Changed to: > > The FE as a whole can only be in one of two states as indicated above. When > the FE is in the DOWN state, it is not forwarding packets. When the FE is in > the UP state it may be forwarding packets depending on the configuration of its > specific LFBs. > On start up the FE is in the DOWN state unless explicitly configured by the > CE to transition to the UP state. This MUST be done before configuring any > other LFBs that affect packet forwarding. > > The FE transitions from the UP to the DOWN (Note the original 'from DOWN to > UP' is a typo, I think) The FE is down by default on startup. Only after the association has happened can the CE configure it to be up. > state when explicitly configured to do so by the CE. When > FE loses its association with CE, it MAY also go to DOWN state, depending on the > policy CE wants FE to do after FE loses association with the CE. The policy is > called the CE failover policy and is defined in Section 7.2.1. Note that > according to this policy, FE may also no go to DOWN state after association > lost, instead it may just keep packet forwarding so that it keeps FE in UP > state. For the FE to properly complete the transition to the DOWN state it MUST > stop packet forwarding and that this may affect multiple LFBs. How this is > achieved is outside the scope of this specification. > > CE configures FE states transitions by means of a so-called FEObject LFB, > which is defined in Section 4.3.3 and Section 7.2. FE state is defined as an > attribute of the FEObject LFB, and CE configuration of the attribute exactly > matches CE configuration of the FE state. Note that even in the FE DOWN state, > the FEObject LFB is still active. FEObject LFB will be automatically loaded and > is in an active state right after FE is started. Refer to Section 4.3.3 and > Section 7.2 for more details. I agree with the general principle of mentioning the relation of the Admin state to what can force transitions - but i think the text above may be getting into a lot more details on the FEObject LFB than is necessary. cheers, jamal 2006 Message-Id: Date: Wed, 11 Jan 2006 16:22:03 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Jamal, On the state machine, my question mainly lies in the expression that the association lost will lead to FE to DOWN state. This is not the scheme that we currently apply in the draft. I agree with you that the state machine only deals with the FE as a whole, therefore it can observe FE only with UP and DOWN, but some expression should be modified so as to make the state machine not conflict with other part of the protocol draft. Another expression that may lead to confusion is the text'FEObject Admin up' and the 'FEObject Admin down' in the figure. This can easily be taken as 'to start FEObject LFB will make FE UP, to shutdown the FEObject LFB will make FE DOWN'. I don't think this is the case. The true is FEObject LFB will always be there after FE is electrically started. The FE UP or FE DOWN state is only managed as an attribute of the FEObject LFB, which can be configured by CE. Based on my above views, I suggest the following modifications: 1. modify the figure start FEObject Admin up -------+ +--->---->---->---->------->----+ | | Y Y | | | | Y +------+--+ +--------+ | | | | | DOWN | | UP | | State | | State | | | | | +---------+ +--------+ ^ Y | | +-<---<------<-----<------<----<---+ FEObject Admin Down/ Association lost to a figure as: FE start CE configure -------+ +--->---->---->---->------->----+ | | Y Y | | | | Y +------+--+ +--------+ | FE | | FE | | DOWN | | UP | | State | | State | | | | | +---------+ +--------+ ^ Y | | +-<---<------<-----<------<----<---+ CE configure or FE association lost 2. Accordingly make modifications in the followed text Original: The FE can only be in one of two states as indicated above. When the FE is in the DOWN state, it is not forwarding packets. When the FE is in the UP state it may be forwarding packets depending on the configuration of its specific LFBs. On start up the FE is in the DOWN state unless explicitly configured by the CE to transition to the UP state. This MUST be done before configuring any other LFBs that affect packet forwarding. The FE transitions from the DOWN to the UP state when explicitly configured to do so by the CE or when it loses its association with the CE. For the FE to properly complete the transition to the DOWN state it MUST stop packet forwarding and that this may affect multiple LFBs. How this is achieved is outside the scope of this specification. Changed to: The FE as a whole can only be in one of two states as indicated above. When the FE is in the DOWN state, it is not forwarding packets. When the FE is in the UP state it may be forwarding packets depending on the configuration of its specific LFBs. On start up the FE is in the DOWN state unless explicitly configured by the CE to transition to the UP state. This MUST be done before configuring any other LFBs that affect packet forwarding. The FE transitions from the UP to the DOWN (Note the original 'from DOWN to UP' is a typo, I think)state when explicitly configured to do so by the CE. When FE loses its association with CE, it MAY also go to DOWN state, depending on the policy CE wants FE to do after FE loses association with the CE. The policy is called the CE failover policy and is defined in Section 7.2.1. Note that according to this policy, FE may also no go to DOWN state after association lost, instead it may just keep packet forwarding so that it keeps FE in UP state. For the FE to properly complete the transition to the DOWN state it MUST stop packet forwarding and that this may affect multiple LFBs. How this is achieved is outside the scope of this specification. CE configures FE states transitions by means of a so-called FEObject LFB, which is defined in Section 4.3.3 and Section 7.2. FE state is defined as an attribute of the FEObject LFB, and CE configuration of the attribute exactly matches CE configuration of the FE state. Note that even in the FE DOWN state, the FEObject LFB is still active. FEObject LFB will be automatically loaded and is in an active state right after FE is started. Refer to Section 4.3.3 and Section 7.2 for more details. -------- Comments pls! Thanks, Weiming 2006 Message-Id: Date: Wed, 11 Jan 2006 11:02:58 +0800 From: Weiming Wang Subject: Re: [issue76] Comments from Alex Jamal, > > > > When I read once more on the Section 4.3.1 (Transactions, Atomicity, Execution > > and Responses), I do believe that a specific flag(1bit) for 2PC should be added. > > In this way, the execution as well as 2PC can be unambigious as: > > > > 1. EM(2bits) flag in one message scope only. > > > > 2. 2PC(1bit) flag with TP(2bits) flag in multi-messages scopes only. > > > > 3. when 2PC is set, the EM MUST be set to 'all-or-none'. > > > > This is also fine by me as opposed to what I suggested in my previous > email. I would need to think through how it affects our implementation. > The name 2PC doesnt seem fitting. Maybe restore the "AT" flag? I'm ok with the 'AT' flag. I hope this issue can be set asap. How about other guys' thoughts? > > > > > BTW, I also suggest Section 4.3 the subsetion be re-arranged some for > > readability. The current subsetion is show as below: > > > > 4.3. Protocol Mechanisms > > 4.3.1. Transactions, Atomicity, Execution and Responses > > 4.3.1.1. Execution > > 4.3.1.1.1. 'execute-all-or-none' Atomic transaction > > 4.3.1.1.2. Transaction Definition > > 4.3.1.1.3. Transaction protocol > > 4.3.1.1.4. Recovery > > 4.3.1.1.5. continue-execute-on-failure > > 4.3.1.1.6. execute-until-failure > > 4.3.1.1.7. Relation to Multipart messages > > 4.3.2. Heartbeat Mechanism > > 4.3.3. FE Object and FE protocol LFBs > > 4.3.4. Scalability > > 4.3.4.1. Batching > > 4.3.4.2. Command Pipelining > > > > I suggest we may re-arrange it as something like: > > > > 4.3. Protocol Mechanisms > > 4.3.1. Execution, Transactions, Atomicity, and Responses > > 4.3.1.1. Execution > > 4.3.1.1.1. execute-all-or-none > > 4.3.1.1.2. continue-execute-on-failure > > 4.3.1.1.3. execute-until-failure > > 4.3.1.1. Transaction and Atomicity > > 4.3.1.1.1. Transaction Definition > > 4.3.1.1.2. Transaction protocol > > 4.3.1.1.3. Atomic Transaction > > 4.3.1.1.4. Relation to Multipart messages > > 4.3.1.1.5. Recovery > > 4.3.2. Scalability > > 4.3.2.1. Batching > > 4.3.2.2. Command Pipelining > > 4.3.3. Heartbeat Mechanism > > 4.3.4. FE Object and FE protocol LFBs > > > > Just my 2 cent. > > > > Sounds reasonable.. Jamal, could you provide an update text to Avri so that we can close this whole issue? Thanks a lot. cheers, weiming 2006 Message-Id: Date: Wed, 11 Jan 2006 00:05:15 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Jamal, When I read once more on the Section 4.3.1 (Transactions, Atomicity, Execution and Responses), I do believe that a specific flag(1bit) for 2PC should be added. In this way, the execution as well as 2PC can be unambigious as: 1. EM(2bits) flag in one message scope only. 2. 2PC(1bit) flag with TP(2bits) flag in multi-messages scopes only. 3. when 2PC is set, the EM MUST be set to 'all-or-none'. BTW, I also suggest Section 4.3 the subsetion be re-arranged some for readability. The current subsetion is show as below: 4.3. Protocol Mechanisms 4.3.1. Transactions, Atomicity, Execution and Responses 4.3.1.1. Execution 4.3.1.1.1. 'execute-all-or-none' Atomic transaction 4.3.1.1.2. Transaction Definition 4.3.1.1.3. Transaction protocol 4.3.1.1.4. Recovery 4.3.1.1.5. continue-execute-on-failure 4.3.1.1.6. execute-until-failure 4.3.1.1.7. Relation to Multipart messages 4.3.2. Heartbeat Mechanism 4.3.3. FE Object and FE protocol LFBs 4.3.4. Scalability 4.3.4.1. Batching 4.3.4.2. Command Pipelining I suggest we may re-arrange it as something like: 4.3. Protocol Mechanisms 4.3.1. Execution, Transactions, Atomicity, and Responses 4.3.1.1. Execution 4.3.1.1.1. execute-all-or-none 4.3.1.1.2. continue-execute-on-failure 4.3.1.1.3. execute-until-failure 4.3.1.1. Transaction and Atomicity 4.3.1.1.1. Transaction Definition 4.3.1.1.2. Transaction protocol 4.3.1.1.3. Atomic Transaction 4.3.1.1.4. Relation to Multipart messages 4.3.1.1.5. Recovery 4.3.2. Scalability 4.3.2.1. Batching 4.3.2.2. Command Pipelining 4.3.3. Heartbeat Mechanism 4.3.4. FE Object and FE protocol LFBs Just my 2 cent. Sincerely, Weiming 2006 Message-Id: Date: Tue, 10 Jan 2006 23:10:08 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Jamal, Very glad to see your comments. (I'd also appreciate it if you can make comments on the "state machine quesiont" also. thanks.) I think all the comments have gone to the tracker issue 76, therefore I havn't tried to open new one for this issue. To summarize your comments, I'd like to show my understanding of of your idea of the use of EM and TP flags as below: 1. EM defines if it is a 2PC or not (by setting EM=all-or-none; 2. Then, TP further to define individual messages for the 2PC. 3. When EM is not set to 'all-or-none', the TP is If it is like this, I do have more question: 1. My former understanding was that EM is not only for inter-messages execution mode but also for inter-operation TLVs in one message for the execution mode, i.e., when we set EM=all-or-none, we also mean all operation-TLVs in one message are also executed in a all-or-none mode. As a result, if we now define EM only for inter-message execution mode, how we then define intra-message operation execution mode? 2. If we come back to define that EM is for intra-message as well as for inter-message, then the question I raised is still there, i.e., when EM is set to 'all-or-none' and when we only have one message, how should we set the TP flag? thanks, Weiming 2006 Message-Id: Date: Tue, 10 Jan 2006 14:49:32 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue76] Comments from Alex Comments: To: "Wang,Weiming" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi Weiming, Is this the message you were refering to? On Fri, 2006-06-01 at 13:20 +0800, Wang,Weiming wrote: > Hi, > > The questions below are not editorial ones and have not been solved, so I just > list them again for more discussions. > > Question 1. On the State Machine > > [Original Text]: > > > > On start up the FE is in the DOWN state unless explicitly configured > > by the CE to transition to the UP state. This MUST be done before > > configuring any other LFBs that affect packet forwarding. > > > > The FE transitions from the DOWN to the UP state when explicitly > > configured to do so by the CE or when it looses its association with > > the CE. It should be noted that what needs to be done for the FE to > > properly complete the transition to the DOWN state is to stop packet > > forwarding and that this may affect multiple LFBs. How this is > > achieved is left as an implementation detail. > > <--- > > > > [Comments]: > > > Comments(From Alex): The "State Machine" as aspounced in the segment > below is > > incomplete in my view. It doesn't address redundancy operation. Is > > the UP state the same as the ACTIVE state? Remember, in an ACTIVE/ > > STANDBY operation, the STANDBY element is UP but not ACTIVE. Also, > > show the events that cause a transition from STANDBY to ACTIVE and > > vice-versa. > > [Comments from Weiming] I agree that we should refine the 'State Machine'. One > obvious reason is it even confilits with the following text in this same > document: > > (06 version Page 47): > > * CE failover policy - This specifies the behavior of the FE > during a CE failure and restart time interval, or when the FE > loses the CE association. It should be noted that this policy > in the case of HA only takes effect after total failure to > connect to a new CE. A timeout parameter, the CE Timeout > Interval (CE TI) is associated with this attribute. Values of > this policy are defined as below: > > 0(default) - The FE should continue running and do what it > can even without an associated CE. This basically requires > that the FE support CE Graceful restart. Note that if the > CE still has not been restarted or hasn't been associated > back to the FE, after the CE TI has expired, the FE will go > operationally down. > > 1 - FE should go down to stop functioning immediately. > > 2 - FE should go inactive to temporarily stop functioning. > If the CE still has not been restarted after a time interval > of specified by the CE TI, the FE will go down completely. > > Others - Reserved > > Comments please! > The applicability on the HA states (active/backup) is really per _LFB instance_ NOT per FE as Alex is suggesting. A failover is not necessarily initiated because a FE is down; as an example a single instance of a port/link could be failed over from one FE to another. A failure on a FE or CE OTOH is may mean a failover of all LFB instances based on the policies you are quoting. So in summary, I dont see that we need to change that state machine. cheers, jamal 2006 Message-Id: Date: Tue, 10 Jan 2006 14:42:22 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue76] Comments from Alex Comments: To: "Wang,Weiming" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi Weiming, On Wed, 2006-11-01 at 00:05 +0800, Wang,Weiming wrote: > Jamal, > > When I read once more on the Section 4.3.1 (Transactions, Atomicity, Execution > and Responses), I do believe that a specific flag(1bit) for 2PC should be added. > In this way, the execution as well as 2PC can be unambigious as: > > 1. EM(2bits) flag in one message scope only. > > 2. 2PC(1bit) flag with TP(2bits) flag in multi-messages scopes only. > > 3. when 2PC is set, the EM MUST be set to 'all-or-none'. > This is also fine by me as opposed to what I suggested in my previous email. I would need to think through how it affects our implementation. The name 2PC doesnt seem fitting. Maybe restore the "AT" flag? > > BTW, I also suggest Section 4.3 the subsetion be re-arranged some for > readability. The current subsetion is show as below: > > 4.3. Protocol Mechanisms > 4.3.1. Transactions, Atomicity, Execution and Responses > 4.3.1.1. Execution > 4.3.1.1.1. 'execute-all-or-none' Atomic transaction > 4.3.1.1.2. Transaction Definition > 4.3.1.1.3. Transaction protocol > 4.3.1.1.4. Recovery > 4.3.1.1.5. continue-execute-on-failure > 4.3.1.1.6. execute-until-failure > 4.3.1.1.7. Relation to Multipart messages > 4.3.2. Heartbeat Mechanism > 4.3.3. FE Object and FE protocol LFBs > 4.3.4. Scalability > 4.3.4.1. Batching > 4.3.4.2. Command Pipelining > > I suggest we may re-arrange it as something like: > > 4.3. Protocol Mechanisms > 4.3.1. Execution, Transactions, Atomicity, and Responses > 4.3.1.1. Execution > 4.3.1.1.1. execute-all-or-none > 4.3.1.1.2. continue-execute-on-failure > 4.3.1.1.3. execute-until-failure > 4.3.1.1. Transaction and Atomicity > 4.3.1.1.1. Transaction Definition > 4.3.1.1.2. Transaction protocol > 4.3.1.1.3. Atomic Transaction > 4.3.1.1.4. Relation to Multipart messages > 4.3.1.1.5. Recovery > 4.3.2. Scalability > 4.3.2.1. Batching > 4.3.2.2. Command Pipelining > 4.3.3. Heartbeat Mechanism > 4.3.4. FE Object and FE protocol LFBs > > Just my 2 cent. > Sounds reasonable.. cheers, jamal 2006 Message-Id: Date: Tue, 10 Jan 2006 14:38:39 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue76] Comments from Alex Comments: To: "Wang,Weiming" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Tue, 2006-10-01 at 23:10 +0800, Wang,Weiming wrote: > Jamal, > > Very glad to see your comments. (I'd also appreciate it if you can make > comments > on the "state machine quesiont" also. thanks.) > I will - what is the subject line? I will look for it, but if i dont respond it is because i havent found it. > I think all the comments have gone to the tracker issue 76, therefore I havn't > tried to open new one for this issue. > > To summarize your comments, I'd like to show my understanding of of your idea of > the use of EM and TP flags as below: > > 1. EM defines if it is a 2PC or not (by setting EM=all-or-none; Well, more like EM defines the execution mode. In which case, an atomic execution mode (all-or-none) which is used by 2pc is a subset. > 2. Then, TP further to define individual messages for the 2PC. > 3. When EM is not set to 'all-or-none', the TP is > TP would be b00 in this case. > If it is like this, I do have more question: > > 1. My former understanding was that EM is not only for inter-messages execution > mode but also for inter-operation TLVs in one message for the execution mode, > i.e., when we set EM=all-or-none, we also mean all operation-TLVs in one message > are also executed in a all-or-none mode. As a result, if we now define EM only > for inter-message execution mode, how we then define intra-message operation > execution mode? > > 2. If we come back to define that EM is for intra-message as well as for > inter-message, then the question I raised is still there, i.e., when EM is set > to 'all-or-none' and when we only have one message, how should we set the TP > flag? > > When we started all this (in the earlier drafts), the EOT and SOT were two separate bits, in such a scenario one could set the EOT and SOT together at the same time to mean "this message is the start and end". Since we have combined them together - the reason being to save on bits and aggregate the semantice, I would suggest that we need two messages for atomic transactions (one with a start and another with and end). If, however, it is perceived that the majority of the messages are going to be atomic in nature then the extra message is unjustified. We then could redefine the TP bits appropriately. This is not a big change in our implementation and i am willing to go back and make changes depending on consensus. cheers, jamal 2006 Message-Id: Date: Tue, 10 Jan 2006 09:27:57 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: I-D ACTION:draft-ietf-forces-protocol-06.txt Comments: To: Avri Doria Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Olla, Apologies for not participating for a while now .. I am trying to go over the emails - I hope i dont miss any. I reviewed the -06 draft and don't see any issues that are technical; rather they are mostly editorial. Perhaps we should close all the issues that have been addressed in -06? You can certainly close all the ones opened by myself. As far as interop: - I strongly believe we should _not_ make it a gating issue for the protocol to move to the RFC queue. The rules call out for implementations existing not necessarily inter-oping. I can tell you inter-op at the moment is very low prio for us (that doesnt equate we wouldnt be interested in a future interop, just that it is something we cant adequately allocate resources to at the moment) cheers, jamal On Tue, 2006-03-01 at 17:25 -0500, Avri Doria wrote: > Hi, > > > On 3 jan 2005, at 08.56, Weiming Wang wrote: > > > ----- Original Message ----- > > From: "Khosravi, Hormuzd M" > > Subject: Re: I-D ACTION:draft-ietf-forces-protocol-06.txt > > > > > > Greetings, > > > > Wish all the WG members a very Happy New Year!! > > > > I haven't seen much activity on the protocol draft after the last > > update > > by Avri. > > Should I set up a conference call to close on any issues that need > > to be > > discussed? > > > > - That would be very helpful. Thanks, Hormuzd. > > > what issues need to be dealt with in a phone call? > > My expectation was that those who had put in issues/change requests > would decide whether more was still needed or if they had been > addressed adequately. and if they felt more was needed, would > explicitly say what was needed. so either people haven't reviewed > -06 yet, or there are no issues ( i cannot believe this is the case - > though it would make me happy) > > I personally, have no issues i want to deal with, though i will do > another clean up pass and try to get some more labels in on figures > (was having trouble with the xml2rfc - sometimes it works and puts a > label in based on title attribute in the figure element and > sometimes it doesn't. and of course will fix anything the WG thinks > need fixing. > > i am still also interested in hearing from the developers who are > using -06 to write code. what are the ambiguities? what's missing? > what still needs to be done for an interoperability (which i define > as CE from X and FE from Y and maybe Z) . > > thanks > a. 2006 Message-Id: Date: Tue, 10 Jan 2006 08:40:16 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue76] Comments from Alex Comments: To: "Wang,Weiming" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi Weiming, On Fri, 2006-06-01 at 14:14 +0800, Wang,Weiming wrote: > Hi, > > Question 2. On the Transaction Operation > > This question is raised from our implementation attempt(As Avri mentioned). We > are trying to implement the transaction operation based on the EM and TP flags, > but we just find some questions and unclear points on the usage. We summarize > them in the following text. > > Thanks, > Weiming > > 4.3.1.1.3. Transaction protocol > > A 2PC [2PCREF] configuration message starts with the header flags > containing a Start of Transaction (SOT) and Atomic Transaction (AT) > on its first message configuration message. A transaction may span > multiple messages. It is up to the CE to keep track of the different > outstanding messages making up a transaction. As an example, the > correlator field could be used to mark transactions and a sequence > field to label the different messages within the same atomic > transaction. > [Weiming] Obviously, we are missing the definition of the AT(Atomic Transaction) > flag in the draft. I'm not sure if the AT flag is just the 'EM(Excute Mode)' > flag? right - we replaced AT with EM == all-or-none Can you open an editorial issue tracker on this? > Any failure notified by the FE causes the CE to execute an Abort > Transaction (ABT) to all FEs involved in the transaction, rolling > back all previously executed operations in the transaction. > > The transaction commitment phase is signaled from the CE to the FE by > an empty End of Transaction (EOT) configuration message. > [Weiming]What does it mean by 'empty' here? Is it a config msg that has no > LFBselect? I'm not sure if current BNF grammar allows an config msg without > LFBselect or not? > The idea was to avoid the LFBSelect altogether since there could be multiple LFBSelects within a transaction. i.e empty means lacking LFBselect. If the grammar needs resolving, then we should do so - else if the empty message sounds unreasonable then lets work on alternatives. > The transaction commitment phase is signaled from the CE to the FE by > an empty End of Transaction (EOT) configuration message. > The FE MUST respond to the CE's EOT message. If no response is > received from the FE within a specified timeout, the transaction MUST > be aborted by the CE. > [Weiming]We havn't made an attribute to describe the 'timeout' for the > transaction operation here. I suggest we just mention "If no response is > received from the CE, the transaction MUST be aborted by the CE." Another > question here is, what we really mean 'aborted by the CE'? As we know an > 'abort > operation' should be done by CE and FE as well. Purely CE abortion will > lead to > error in FE. > Probably the danger in the above text is trying to define how someone writing code or an app at CE would do two phase commits. Such a person would have a timeout involved. Maybe we should totally avoid talking from an app point of view ? > 4.3.1.1.5. continue-execute-on-failure > > If several independent operations are targeted at one or more LFB > selectors, execution continues at the FE even if one or more > operations fail. This mode is signaled by AT flag set to zero (0). > [Weiming]Again, should it be to 'set the EM flag to 0' rather than the AT flag > to set? > indeed. When you open the tracker issue, please create just one to cover all the AT=> EM translation > 4.3.1.1.7. Relation to Multipart messages > > Multipart messages, after the first one, are indicated by the Middle > of Transaction flag (MOT). The first message is indicated by SOT and > the last by EOT. > > Multi-part messages MUST be consistent in their use of execution > modes. If the first message starts with one exectution mode (such as "exectution" is a typo > continue-execute-on-failure mode), then all other parts of the same > multi-part messages MUST continue with the same execution mode. Any > inconsistency implies an error and a canceled transaction in which "canceled" should be "cancelled". > all messages are dropped and the sender NACKED. > [Weiming] the NACKED is not clear on its meaning and operation method. > This is also one of those editorial issues that need fixing. NACK has disappeared; above is implying a negative acknowledgement will be returned as in an error. > 6.1. Common Header > ..... > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | | | | | > |ACK| Pri | EM|TP | Reserved | > | | | | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ..... > > - EM: Execution mode (2 bits) > There are 3 execution modes refer to Section 4.3.1.1 for > details. > > Reserved..................... (0b00) > > `execute-all-or-none` ....... (0b01) > > `execute-until-failure` ..... (0b10) > > `continue-execute-on-failure` (0b11) > > - TP: Transaction phase (2 bits) > A message from the CE to the FE within a transaction could be > indicative of the different phases the transaction is in. > Refer to Section 4.3.1.1.3 for details. > > `MOT (Middle of transaction)` (0b00) > > `SOT (start of transaction)` (0b01) > > `EOT (end of transaction)` (0b10) > > `ABT (abort)` (11) > > [Weiming] > Q1: is the TP flag only applied to Config message? It makes sense to be in the config message; i dont see it as being harmful in any other message. > Q2: if we now only have one message and we don't use spanning messages > transaction, i.e., we only have one message as one transaction, how should we > set the flag? Just set it to SOT or EOT? An atomic transaction must have at least two messages. A start and end/commit. > Q3: It seems we now support transactions spanning FEs. Let's show some cases: > > Case1. two FEs (FE1 and FE2), with a transaction of 5 messages, msg1 and 2 sent > to FE1 and msg 3,4,5 sent to FE2. How shall we set the TP flag then? Shall we > set the msg1 with SOT msg 2,3,4, with MOT and msg5 with EOT? or shall we set the > msg1 and msg3 with SOT and msg2 and msg 5 with EOT? > All the rules are based on how 2pc is defined. The danger again is perhaps in trying to define how someone should code a 2ps. In this case i would say: FE1: msg1(SOT), msg2(MOT), msgcommit(EOT) FE2: msg3(SOT),msg4(MOT),msg5(MOT), msgcommit(EOT) The "empty" msgcommit is issued to both. A timer is started. If the timer expires before positive response from all, an ABT is issued to all. if a response is issued positively from all then the timer is cancelled. These are almost implementation issues and the underlying assumption is that the coder knows what a 2PC is - we just provide the mechanisms. > Case2. two FEs (FE1 and FE2), with a transaction of 5 messages which should be > sent to FE1 and FE2 via multicast messages. How shall we set the messages then? > The text in the protocol draft should not describe how one would go implementing 2pc. I think we should probably put a disclaimer saying so and perhaps in an appendix suggest how this is achieved. > Anyway, we are now not very clear by reading the text that, if the SOT, MOT, and > EOT are all only one FE specific or multipul FEs specific. I hope the above clarifies things. cheers, jamal 2006 Message-Id: Date: Fri, 6 Jan 2006 14:14:21 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Hi, Question 2. On the Transaction Operation This question is raised from our implementation attempt(As Avri mentioned). We are trying to implement the transaction operation based on the EM and TP flags, but we just find some questions and unclear points on the usage. We summarize them in the following text. Thanks, Weiming 4.3.1.1.3. Transaction protocol A 2PC [2PCREF] configuration message starts with the header flags containing a Start of Transaction (SOT) and Atomic Transaction (AT) on its first message configuration message. A transaction may span multiple messages. It is up to the CE to keep track of the different outstanding messages making up a transaction. As an example, the correlator field could be used to mark transactions and a sequence field to label the different messages within the same atomic transaction. [Weiming] Obviously, we are missing the definition of the AT(Atomic Transaction) flag in the draft. I'm not sure if the AT flag is just the 'EM(Excute Mode)' flag? Any failure notified by the FE causes the CE to execute an Abort Transaction (ABT) to all FEs involved in the transaction, rolling back all previously executed operations in the transaction. The transaction commitment phase is signaled from the CE to the FE by an empty End of Transaction (EOT) configuration message. [Weiming]What does it mean by 'empty' here? Is it a config msg that has no LFBselect? I'm not sure if current BNF grammar allows an config msg without LFBselect or not? The transaction commitment phase is signaled from the CE to the FE by an empty End of Transaction (EOT) configuration message. The FE MUST respond to the CE's EOT message. If no response is received from the FE within a specified timeout, the transaction MUST be aborted by the CE. [Weiming]We havn't made an attribute to describe the 'timeout' for the transaction operation here. I suggest we just mention "If no response is received from the CE, the transaction MUST be aborted by the CE." Another question here is, what we really mean 'aborted by the CE'? As we know an 'abort operation' should be done by CE and FE as well. Purely CE abortion will lead to error in FE. 4.3.1.1.5. continue-execute-on-failure If several independent operations are targeted at one or more LFB selectors, execution continues at the FE even if one or more operations fail. This mode is signaled by AT flag set to zero (0). [Weiming]Again, should it be to 'set the EM flag to 0' rather than the AT flag to set? 4.3.1.1.7. Relation to Multipart messages Multipart messages, after the first one, are indicated by the Middle of Transaction flag (MOT). The first message is indicated by SOT and the last by EOT. Multi-part messages MUST be consistent in their use of execution modes. If the first message starts with one exectution mode (such as continue-execute-on-failure mode), then all other parts of the same multi-part messages MUST continue with the same execution mode. Any inconsistency implies an error and a canceled transaction in which all messages are dropped and the sender NACKED. [Weiming] the NACKED is not clear on its meaning and operation method. 6.1. Common Header ..... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | |ACK| Pri | EM|TP | Reserved | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... - EM: Execution mode (2 bits) There are 3 execution modes refer to Section 4.3.1.1 for details. Reserved..................... (0b00) `execute-all-or-none` ....... (0b01) `execute-until-failure` ..... (0b10) `continue-execute-on-failure` (0b11) - TP: Transaction phase (2 bits) A message from the CE to the FE within a transaction could be indicative of the different phases the transaction is in. Refer to Section 4.3.1.1.3 for details. `MOT (Middle of transaction)` (0b00) `SOT (start of transaction)` (0b01) `EOT (end of transaction)` (0b10) `ABT (abort)` (11) [Weiming] Q1: is the TP flag only applied to Config message? Q2: if we now only have one message and we don't use spanning messages transaction, i.e., we only have one message as one transaction, how should we set the flag? Just set it to SOT or EOT? Q3: It seems we now support transactions spanning FEs. Let's show some cases: Case1. two FEs (FE1 and FE2), with a transaction of 5 messages, msg1 and 2 sent to FE1 and msg 3,4,5 sent to FE2. How shall we set the TP flag then? Shall we set the msg1 with SOT msg 2,3,4, with MOT and msg5 with EOT? or shall we set the msg1 and msg3 with SOT and msg2 and msg 5 with EOT? Case2. two FEs (FE1 and FE2), with a transaction of 5 messages which should be sent to FE1 and FE2 via multicast messages. How shall we set the messages then? Anyway, we are now not very clear by reading the text that, if the SOT, MOT, and EOT are all only one FE specific or multipul FEs specific. 2006 Message-Id: Date: Fri, 6 Jan 2006 13:20:20 +0800 From: "Wang,Weiming" Subject: Re: [issue76] Comments from Alex Hi, The questions below are not editorial ones and have not been solved, so I just list them again for more discussions. Question 1. On the State Machine [Original Text]: > 3.2. ForCES Protocol Phases > ---> > ...... > > > > start FEObject Admin up > -------+ +--->---->---->---->------->----+ > | | Y > Y | | > | | Y > +------+--+ +--------+ > | | | | > | DOWN | | UP | > | State | | State | > | | | | > +---------+ +--------+ > ^ Y > | | > +-<---<------<-----<------<----<---+ > FEObject Admin Down/ > Association lost > > > Figure 4: The FE State Machine > > The FE can only be in one of two states as indicated above. When the > FE is in the DOWN state, it is not forwarding packets. When the FE > is in the UP state it may be forwarding packets depending on the > configuration of its specific LFBs. > > On start up the FE is in the DOWN state unless explicitly configured > by the CE to transition to the UP state. This MUST be done before > configuring any other LFBs that affect packet forwarding. > > The FE transitions from the DOWN to the UP state when explicitly > configured to do so by the CE or when it looses its association with > the CE. It should be noted that what needs to be done for the FE to > properly complete the transition to the DOWN state is to stop packet > forwarding and that this may affect multiple LFBs. How this is > achieved is left as an implementation detail. > <--- > [Comments]: > Comments(From Alex): The "State Machine" as aspounced in the segment below is > incomplete in my view. It doesn't address redundancy operation. Is > the UP state the same as the ACTIVE state? Remember, in an ACTIVE/ > STANDBY operation, the STANDBY element is UP but not ACTIVE. Also, > show the events that cause a transition from STANDBY to ACTIVE and > vice-versa. [Comments from Weiming] I agree that we should refine the 'State Machine'. One obvious reason is it even confilits with the following text in this same document: (06 version Page 47): * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval, or when the FE loses the CE association. It should be noted that this policy in the case of HA only takes effect after total failure to connect to a new CE. A timeout parameter, the CE Timeout Interval (CE TI) is associated with this attribute. Values of this policy are defined as below: 0(default) - The FE should continue running and do what it can even without an associated CE. This basically requires that the FE support CE Graceful restart. Note that if the CE still has not been restarted or hasn't been associated back to the FE, after the CE TI has expired, the FE will go operationally down. 1 - FE should go down to stop functioning immediately. 2 - FE should go inactive to temporarily stop functioning. If the CE still has not been restarted after a time interval of specified by the CE TI, the FE will go down completely. Others - Reserved Comments please! Thanks, Weiming 2006 Message-Id: Date: Fri, 6 Jan 2006 11:56:56 +0800 From: "Wang,Weiming" Subject: Re: [issue68] Section 5.1 ACK issue Avri, Pls help to put the following change in the next draft update, which is in 06 version's Section 6.1 on 'ACK indicator' flag. Thanks, Weiming > Avri, > pls just change the sentense "Note that for all other messages than Config > Message this flag MUST be ignored." to "Note that for all other messages this > flag MUST be ignored by the message receiver." 2006 Message-Id: Date: Thu, 5 Jan 2006 22:36:30 -0800 From: "Khosravi, Hormuzd M" Subject: Re: I-D ACTION:draft-ietf-forces-protocol-06.txt Comments: To: Avri Doria MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Avri, I was under the impression that the authors needed to discuss some issues based on your last email. Guess I misunderstood. In any case we need to get things moving ahead. Either via a call or just email, doesn't matter. It would be helpful if the chairs would set a deadline for people to post any comments they have, so that way we could move to IESG review soon.=20 If you need help on any of the remaining editorial work, pls do let us know Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria Sent: Tuesday, January 03, 2006 2:26 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] I-D ACTION:draft-ietf-forces-protocol-06.txt what issues need to be dealt with in a phone call? My expectation was that those who had put in issues/change requests =20 would decide whether more was still needed or if they had been =20 addressed adequately. and if they felt more was needed, would =20 explicitly say what was needed. so either people haven't reviewed =20 -06 yet, or there are no issues ( i cannot believe this is the case - =20 though it would make me happy) 2005 Message-Id: Date: Mon, 3 Jan 2005 21:56:14 +0800 From: Weiming Wang Subject: Re: I-D ACTION:draft-ietf-forces-protocol-06.txt ----- Original Message ----- From: "Khosravi, Hormuzd M" Subject: Re: I-D ACTION:draft-ietf-forces-protocol-06.txt Greetings, Wish all the WG members a very Happy New Year!! I haven't seen much activity on the protocol draft after the last update by Avri. Should I set up a conference call to close on any issues that need to be discussed? - That would be very helpful. Thanks, Hormuzd. Weiming 2006 Message-Id: Date: Tue, 3 Jan 2006 17:25:42 -0500 From: Avri Doria Subject: Re: I-D ACTION:draft-ietf-forces-protocol-06.txt Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, On 3 jan 2005, at 08.56, Weiming Wang wrote: > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > Subject: Re: I-D ACTION:draft-ietf-forces-protocol-06.txt > > > Greetings, > > Wish all the WG members a very Happy New Year!! > > I haven't seen much activity on the protocol draft after the last > update > by Avri. > Should I set up a conference call to close on any issues that need > to be > discussed? > > - That would be very helpful. Thanks, Hormuzd. what issues need to be dealt with in a phone call? My expectation was that those who had put in issues/change requests would decide whether more was still needed or if they had been addressed adequately. and if they felt more was needed, would explicitly say what was needed. so either people haven't reviewed -06 yet, or there are no issues ( i cannot believe this is the case - though it would make me happy) I personally, have no issues i want to deal with, though i will do another clean up pass and try to get some more labels in on figures (was having trouble with the xml2rfc - sometimes it works and puts a label in based on title attribute in the figure element and sometimes it doesn't. and of course will fix anything the WG thinks need fixing. i am still also interested in hearing from the developers who are using -06 to write code. what are the ambiguities? what's missing? what still needs to be done for an interoperability (which i define as CE from X and FE from Y and maybe Z) . thanks a. 2006 Message-Id: Date: Mon, 2 Jan 2006 17:38:52 -0800 From: "Khosravi, Hormuzd M" Subject: Re: I-D ACTION:draft-ietf-forces-protocol-06.txt Comments: To: Avri Doria MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings,=20 Wish all the WG members a very Happy New Year!!=20 I haven't seen much activity on the protocol draft after the last update by Avri. Should I set up a conference call to close on any issues that need to be discussed? Avri, could you send us a list of issues that you feel need to be further discussed, that would be very helpful. I am trying to figure out what's needed to take the draft to the next stage for IESG review. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria Sent: Thursday, December 15, 2005 9:19 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] I-D ACTION:draft-ietf-forces-protocol-06.txt On 15 dec 2005, at 04.45, Wang,Weiming wrote: > > To better reflect the editing work of the draft in the issue =20 > trackers, may I > suggest short comments be made to the issues and even a closure be =20 > made to some > of them after your editing work? yes, there are some comments in the doc. I can go through the =20 tracker and add some more comments, but i am not sure they would be =20 more complete then the ones i put in the doc itself. also i think =20 the people who put in the items, and the chairs, should decide =20 whether issues are closed or not - sort of a check and balance - who =20 am i to decide that i closed something adequately as i might have a =20 conflict of interest in making such a determination (i.e. the desire =20 to be finished with an issue). Note by using ietf wg tools, one can go to: http://tools.ietf.org/wg/forces/draft-ietf-forces-protocol/draft-ietf-=20 forces-protocol-06-from-05.diff.html and see a side by side comparison of -05 and -06 to check out the =20 changes. a.