Subject: Re: [issue78] Comments from Chawla

From: Weiming Wang <[email-masked]>
Date: Sun, 5 Feb 2006 22:32:00 +0800

Avri and all,

To summarize the issue process,

1) Typos have already been fixed by Avri.

2) Questions regarding Section 2 and Section 3.1  have been answered with
explanations, and no further questions have been received.

3) Questions regarding Section 3.2, the FE UP/DOWN state machine,  the answer
the corresponding update has been given by a new text section on the state
machine, which is in the issue 76.

4) Questions regarding Section 3.3, some of the answers have been given by a
totally re-written Section 4.3(formally section 3.3), related to issue 76.

I suppose this issue can also be closed if theres no further comments.

Thanks to chawla very  much for the valuble comments.

Weiming

----- Original Message -----
From: "Weiming Wang" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 19, 2005 10:59 PM
Subject: [issue78] Comments from Chawla

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

----------
category: Editorial
draft: draft-ietf-forces-protocol
messages: 388
nosy: weiming
priority: May fix
status: Pending
title: Comments from Chawla

___________________________________________________
Forces issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/forces/issue78>
___________________________________________________