Subject: Re: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 15 Nov 2005 15:05:18 -0800

Wajdi,
 
Thanks a lot for reviewing the draft !
Your comments are valuable and we will start incorporating these shortly.
 
regards
Hormuzd

________________________________

From: louati [mailto:[email-masked]] 
Sent: Monday, November 14, 2005 4:56 AM
To: [email-masked]
Cc: Khosravi, Hormuzd M; Djamal ZEGHLACHE; wajdi - int
Subject: Re: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

Dear all,

I have read the ForCES Protocol Specification draft and it is very clear and well structured and written. I have checked also the technical level of this draft and it seems fine for me. I have just some comments and questions:

*	
	In section 3.3. Protocol Mechanisms, for both continue-execute-on-failure (3.3.1.1.5) and execute-until-failure (3.3.1.1.6) execution modes, is it possible to extend the description to several FEs case (distributed FEs). (just like the Atomic transaction execution mode description).

*	
	In section 6.4 Association Messages, each Message Header description (from CE to FE) provides almost all header fields except of two flags:
	- EM: Execution mode  and
	- TP: Transaction phase
	A brief description and possible values for these specific fields in each message would be helpful.

*	
	Page 28, using "execute-all-or-none" Atomic Transaction (AT) sentence should be better than using only "execute-all-or-none" sentence since AT flags is already used before in section 3.3.1

*	
	For the section (7. Protocol Scenarios), assuming that a new LFB wants to join an FE in a dynamic manner, in this case the LFB object FE will be upgraded with new attributes and capabilities. In this case, what kind of message the FE should send to the CE? Asso Setup Req !

*	
	In case when distributed FEs are integrated in separated boxes (physical separation between the CEs and FEs at the box level).  In such a configuration,
	is it possible to give a scenario example in section 7 to show the message exchange between CEs and FEs (several FEs can join or leave).

Best Regards,

Wajdi LOUATI
_________________________________
Wajdi LOUATI
Wireless Networks and Services Group 
Wireless Networks and Multimedia Services Department
Institut National des Télécommunications
9 rue Charles Fourier
91011 EVRY Cedex, France
_______________________________

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

	----- Original Message ----- 
	From: Putzolu, David <mailto:[email-masked]>  
	To: [email-masked] 
	Sent: Wednesday, November 02, 2005 3:11 AM
	Subject: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

	All,
	
	The authors of the ForCES protocol have requested
	working group last call and the document appears to
	have stabilized and reached a technically complete state. 
	URL:
	
	http://ietf.org/internet-drafts/draft-ietf-forces-protocol-05.txt <http://ietf.org/internet-drafts/draft-ietf-forces-protocol-05.txt>  
	
	This email begins a last call period for the ForCES
	protocol document. This last call period is
	two weeks in length and ends on Tuesday, November 15th 
	one week after the ForCES meeting at IETF 64.
	
	Please send to the list any suggested changes
	and/or comments on this document.
	
	Thanks,
	David & Patrick

---

From: "Chawla, Shuchi" <[email-masked]>
Date: Tue, 15 Nov 2005 20:50:42 -0800

Hello all,

Apologies for the delay in reviewing this. I have only done a quick
review due to lack of time, and have reviewed through Section 4. Here's
what I have found so far.  The first section in this mail has
comments/questions etc., and the next section has minor issues/typos
etc.

Thanks,

Shuchi

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

Section 2

Conflict between what CEM and FEM come up with regarding CE/FE
Communication -- how is it resolved?  Is this considered out of scope of
the ForCES protocol?

Datapath -- It doesn't include (control packets associated with
signaling/routing etc.) forwarded to a CE?

Section 3.1

After Figure 3:

/On receive, the TML delivers the message to its destination PL

   layer(s)./

This seems to suggest that a TML can deliver a message to multiple PL
layers (since the term layer(s) is used).  Is that true?  I thought
there is a 1-1 association between a PL Layer and a TML Layer.

Section 3.1.2

/All

   ForCES Protocol Layer implementations should be portable across all

   TMLs, because all TMLs have the same top edge semantics as defined in

   this document./

Are the TML top-edge semantics defined in this document?  Aren't the TML
service primitives etc. being placed in a different spec.? (I haven't
had a chance to go through the entire spec., so I may be missing this
info.)

Section 3.2

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

As per the figure,  the FE can also transition to the DOWN state if
configured/instructed by the FE to do so (via the FEObject Admin DOWN
msg). I assume that doesn't necessarily break up the association of the
FE with the CE, or does it?  If it does, may need tp be clarified).
Unclear if the FE can be in the DOWN state other than during
pre-association/association phases.  What is the difference in behavior
between an administrative down from the CE to the FE versus the FE, due
to some fault or other connectivity issue, losing its association from
the CE and hence going DOWN.

Also, is there/should there be a coresponding CE state machine?  Or do
the states a CE is in have no bearing at this point. I assume the CE can
also lose its association with the FE (maybe the CE goes down due to a
fault while the FE is technically up) -- in such a case, what state does
the CE enter, and who/what cares about it.  Some bearing on HA, I
assume.

Section 3.2.1 Pre-association

At a minimum, it might help to mention/clarify as to how conflicts are
resolved between configuration issued by the FEM versus CEM -- say FE1
thinks it is associated with CE1, but CE1 doesn't have FE1 in the list
of FEs associated with it.

Section 3.2.2.1

Here there is a mention of an Established state for an FE.  How is this
related to the previous FE state diagram?  Can an FE be administratively
DOWN (that is, a CE configured it to go down, so that it is not
forwarding packets, but still has its configuration/attributes etc.),
but be considered to be in the Established state?  I think further
clarification is needed on the various FE states and their
relationships, and what it means to be in one state versus another.  See
earlier comment regarding this.

In a later paragraph, there is mention that the FE upon re-association
should declare all current state as invalid and retrieve new state.  Is
this true even if the FE was administratively set to DOWN by the CE?

Section 3.3.1.1

- General comment on descriptions of the execution modes: Some of the
descriptions refer to operations carried out on FEs, versus others
specify LFB selectors.  Is that intentional?  What is the difference
between the two?  Unclear...

If there is no real difference, might be better to make the usage
consistent in all cases. 

- General comment on transaction protocol and related execution modes:
Unclear if the transaction protocol in Section 3.3.1.1.3 is applicable
to all modes or only to the "Transactional execute-all-or-none" mode.
This may be partially due to the ordering of the sections.

Section 3.3.1.1.1 and Section 3.3.1.1.2

It seems that latter section defines a transaction and the former
specifies a certain specific type of transaction.  Would it make sense
to switch the oredr of these two sections?

Section 3.3.1.1.3

/If no response is

   received from the CE within a specified timeout, the transaction MUST

   be aborted by the CE./ -->

?? /If no response is

   received by the CE (from the FE) within a specified timeout, the
transaction MUST

   be aborted by the CE./

Should this be, "by the CE" versus "from the CE"?

Section 3.3.1.1.4

/Any of the participating FEs, or the CE, or the associations between

   them, may fail after the EOT response message has left the FE and

   before it has received all the responses, (possibly the EOT response

   never reached the CE)./

Rephrase -- doesn't read right, hence unclear.

Section 3.3.1.1.6

/In which all operations/ --> 

?? /In which all independent operations/

Are these intended to be independent operations?  If so, should specify.
If not indepdendent, then not undoing what has completed may leave the
FE in a partial state.

Section 3.2

Unclear if Heartbeats are "required" at the PL Layer or if this is
optional.  If neither the CE nor the FE generate Heartbeats, is that ok?

Section 3.3.4

It's not completely clear on reading this section as to how
batching/command pipelining would be implemented at the PL/TML layers.
I haven't had a chance to go through the rest of the spec., so if the
details are covered there, that's good, else I think this section needs
more detail.

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

Minor issues/typos etc.

Section 1.

/plane in an ForCES Network Element (ForCES NE)./ -->

/plane in a ForCES Network Element (ForCES NE)./ 

Duplicate use of only

/the term "ForCES protocol" refers only

   to the protocol used to standardize the information exchange between

   Control Elements(CEs) and Forwarding Elements(FEs) only./ -->

/the term "ForCES protocol" refers only

   to the protocol used to standardize the information exchange between

   Control Elements(CEs) and Forwarding Elements(FEs)./

Section 2.

Doesn't read well.

/This document also uses the terminology defined by ForCES FE model in

   [FE-MODEL] repeated below for clarity./

/Post-association Phase - The period of time during which a FE does

   know which CE/ -->

/Post-association Phase - The period of time during which a FE knows
which CE/

Capitalize start of sentence and Forces

/LFB (Logical Function Block) Class (or Type) -- the basic building

blocks that are operated on by the Forces protocol./ -->

LFB (Logical Function Block) Class (or Type) -- The basic building 

blocks that are operated on by the ForCES protocol./

/LFB (Logical Function Block) Class (or Type) -- /

Use of "the" FE and "the" CE in the definition of LFB seems to indicate
that this is part of fixed or well-defined FE.  Replace with an FE, a
CE.

ForCES Protocol Transport Mapping Layer (ForCES TML) --

Use of comma (,) for readability

/The ForCES TML specifications are detailed in

   separate ForCES documents one for each TML./

/The ForCES TML specifications are detailed in

   separate ForCES documents, one for each TML./

Section 3.1 (after Figure 1)

ForCES versus Forces (check throughout the document)

/a role in the booting up of the Forces Protocol./ -->

/a role in the booting up of the ForCES Protocol./

Prior to Figure 2

Use of an

/of a MPLS QoS enabled Network Element./ -->

/of an MPLS QoS enabled Network Element./

After Figure 2:

/The ForCES Interface shown in Figure 2 constitutes two pieces: the PL

   and TML layer./ -->

/The ForCES Interface shown in Figure 2 constitutes two pieces: the PL

   and TML layers./

After Figure 3:

This seems to suggest that a TML can deliver a message to multiple PL
layers (since the term layer(s) is used).  Is that true?  I thought
there is a 1-1 association between a PL Layer and a TML Layer.

/On receive, the TML delivers the message to its destination PL

   layer(s)./

Section 3.1.1

/both the FE and associated LFB'ss operational parameters/ -->

?? /both the FE and associated LFBs' operational parameters/

Section 3.1.2

/etc are handled./ -->

/etc. are handled./

/The different TMLs each could/ -->

/The different TMLs could each/

Section 3.1.3

General comment -- some places have the use of "we", others use the
term, "this document" or "this spec" etc.

/We discuss/ -->

/This document discusses/

/An example of typical things FEM/CEM would configure/ -->

/An example of typical things FEM/CEM may configure/

Section 3.2 

After Figure 4

/when it looses its association/ -->

/when it loses its association/

Section 3.2.1

/saved config file./ -->

/saved configuration file./

/retrieve the config parameters instead of

   reading them from a static config file./ -->

/retrieve the configuration parameters instead of

   reading them from a static configuration file./

Section 3.3.1

Doesn't quite sound right.

/This section details the different modes of execution that a CE can

   order the FE(s) to perform in Section 3.3.1.1./

/It also describes the

   different modes a CE can ask the FE(s) to format the responses back

   after processing the operations requested./ -->

?? /It also describes the

   different modes a CE can ask the FE(s) to format the responses back
in

   after processing the operations requested./

Section 3.3.3.1

/spanning on one or more LFB selectors:/ -->

/spanning one or more LFB selectors:/

Section 3.3.1.1.1

Is this supposed to be the same as "Transactional execute-all-or-none"
as specified in Section 3.3.1.1?  If so, should use the same term to
ensure consistency.  If different, what is the difference?

/'all-or-none' Atomic transaction/

/A transaction maybe atomic:/ -->

/A transaction may be atomic:/

Section 3.3.1.1.2

/transactional operations maybe simplified/ -->

/transactional operations may be simplified/

Section 3.3.1.1.3

Specify acronym 2PC in Section 3.3.1.1 where Two Phase Commit is first
introduced prior to use it here.

Section 3.3.1.1.3

/containg/ --> /containing/

Typically, first usage of an acronym is preceeded by the
full-term/expansion followed by the acronym in parenthesis.

/SOT(start of transaction) and AT (Atomic Transaction)/ -->

/Start of Transaction (SOT) and Atomic Transaction (AT)/

Does "one" here imply the CE?  If so, good to specify it as CE.

/As an example, one

   could use the correlator field to mark transactions/

/causes the CE to execute an ABT (Abort

   Transaction)/ -->

/causes the CE to execute an Abort

   Transaction (ABT)/

/empty EOT configuration message./ -->

?? /empty End of Transaction (EOT) configuration message./

Section 3.3.1.1.5

Format as full sentence.

/In which several independent operations are targeted at one or more

   LFB selectors./

Should it state "even if one or more operations fail" versus "when one
..."?

/Execution continues at the FE when one or more

    operations fail./ -->

?? /Execution continues at the FE even if one or more

   operations fail./

Section 3.3.1.1.6

Format as full sentence.

/In which all operations are executed on FE sequentially until first

   failure./

Are these intended to be independent operations?  If so, should specify.
If not indepdendent, then not undoing what has completed may leave the
FE in a partial state.

/In which all operations/ --> 

?? /In which all independent operations/

Section 3.3.1.1.7

/by the MOT flag

   (Middle of Transaction)./ -->

/by the flag

   Middle of Transaction (MOT)./

Rephrase latter part, doesn't read right.

/If the first message starts with one mode (such as continue-

   execute-on-failure mode), then it implies the rest that are part of

   the same multi-part messages do./

Section 3.2

/Hearbeats between/ -->

/Hearbeats (HB) between/

Section 3.3.4

/one PDU/ -->

/one Protocol Data Unit (PDU)/

Section 4

Point #8

/priotity/ --> /priority/

/if the TML only support 2/ -->

/if the TML only supports 2/

From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Putzolu, David
Sent: Tuesday, November 01, 2005 6:12 PM
To: [email-masked]
Subject: ForCES Protocol Working Group Last Call - ends Tuesday,
November 15, 2005
Importance: High

All,

http://ietf.org/internet-drafts/draft-ietf-forces-protocol-05.txt
<http://ietf.org/internet-drafts/draft-ietf-forces-protocol-05.txt>  

Thanks,
David & Patrick