Subject: [issue76] Comments from Alex

From: Weiming Wang <[email-masked]>
Date: Fri, 18 Nov 2005 01:45:40 +0000

New submission from Weiming Wang <[email-masked]>:

Hi All,
 
I read the latest protocol draft and these are my comments:  
 
The authors did a good job in documenting the structure of the messages in 
detail. That is great for
consistent API implementation and interoperability.  However, there was not the 
same attention 
given to documenting the protocol behavior.  This can easily lead to different 
implementations 
behaving differently - a classic interoperability problem.
 
There was an attempt to address some of this in the scenario section. But this 
section  only contains few examples and is typically not exhaustive. If there 
are normative beahoirs called out here, they should be moved into the protocol 
message description section for the respective messages. 
 
Also the protocol state machine needs more work. It needs to be redundancy-
aware.  Remember that
accurate element state management is key to providing loss-free service.  
 
Please see attachment for full details of comments.
 
Regards,
Alex.

----------
category: Editorial
draft: draft-ietf-forces-protocol
files: forces-protocol-05-comments.txt
messages: 377
nosy: weiming
priority: May fix
status: No discussion
title: Comments from Alex

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 18 Nov 2005 11:43:04 +0800

Hi Alex,

Thanks very much for the comments. I think Avri will fit in the edititorial
parts of your comments.  Some more reply from me is inline.

Avri and Jamal,  could also definitely check it?

Thanks,
Weiming

General comments:  Structures of protocol messages are well documented. This
   is good for consistent API implementation.  However, more still needs to
   be done to document protocol behavior.   Also the State Machine needs
   to be updated to be redundancy-aware.

   Details follow:

   =======================================================================

1. Introduction:
   Change:
   --->
                                                              ForCES FE
   model [FE-MODEL] represents the capabilities, state and configuration
   of FEs within the context of the ForCES protocol, so that CEs can
   accordingly control the FEs in a standardizded way and by means of
   the ForCES protocol.
   --->

   To:
   --->
                                                              ForCES FE
   model [FE-MODEL] presents the capabilities, state and configuration
   of FEs within the context of the ForCES protocol, so that CEs can
   accordingly control the FEs in a standardizded way and by means of
   the ForCES protocol.
   <---
[Weiming]ok.

2. Definitions:

i) Control Element (CE)
   Change:
   --->
   Control Element (CE) - A logical entity that implements the ForCES
   protocol and uses it to instruct one or more FEs how to process
   packets.  CEs handle functionality such as the execution of control
   and signaling protocols.
   <---

   To:
   --->
   Control Element (CE) - A logical entity that implements the ForCES
   protocol and uses it to instruct one or more FEs on how to process
   packets.  CEs handle functionality such as the execution of control
   and signaling protocols.
   <---
[Weiming]ok.

ii) FE Manager
   Comments: I am not sure if FE Manager is only useful during pre-association
   phase.  I think this definition needs to be modified appropriately. I
   suggest the following:

   Change:
   --->
   FE Manager (FEM) - A logical entity that operates in the pre-
   association phase and is responsible for determining to which CE(s) a
   FE should communicate.  This process is called CE discovery and may
   involve the FE manager learning the capabilities of available CEs.  A
   FE manager may use anything from a static configuration to a pre-
   association phase protocol (see below) to determine which CE(s) to
   use.  Being a logical entity, a FE manager might be physically
   combined with any of the other logical entities such as FEs.
   <---

   To:
   --->
   FE Manager (FEM) - A logical entity responsible for generic FE management
   tasks. It is used during pre-association phase to determine with which
   CE(s) an FE should communicate.  This process is called CE discovery and may
   involve the FE manager learning the capabilities of available CEs.  An
   FE manager may use anything from a static configuration to a pre-
   association phase protocol (see below) to determine which CE(s) to
   use.  Being a logical entity, an FE manager might be physically
   combined with any of the other logical entities such as FEs.
   <---
[Weiming]I basically agree with this change, i.e., not to explicitly and
strictly limit the FEM definition to pre-association, and also not explicitly
say it should be applied to post-association for the moment.

iii) CE Manager
   Comments: Same as above; CE Manager could be called into action way past
   the pre-association phase.

   Change:
   --->
   CE Manager (CEM) - A logical entity that operates in the pre-
   association phase and is responsible for determining to which FE(s) a
   CE should communicate.  This process is called FE discovery and may
   involve the CE manager learning the capabilities of available FEs.
   <---

   To:
   --->
   CE Manager (CEM) - A logical entity responsible for generic CE management
   tasks. It is particularly used during the pre-association phase to determine
   with which FE(s) a CE should communicate.  This process is called FE
   discovery and may involve the CE manager learning the capabilities of
   available FEs.
   <---

3.1. Protocol Framework:
  Comments: In fig2 (Example of CE and FE functions), indicate which part
            is CE and which is FE.

  Change:

         -------------------------------------------------
         |       |       |       |       |       |       |
         |OSPF   |RIP    |BGP    |RSVP   |LDP    |. . .  |
         |       |       |       |       |       |       |
         -------------------------------------------------
         |               ForCES Interface                |
         -------------------------------------------------
                                 ^   ^
                                 |   |
                         ForCES  |   |data
                         control |   |packets
                         messages|   |(e.g., routing packets)
                                 |   |
                                 v   v
         -------------------------------------------------
         |               ForCES Interface                |
         -------------------------------------------------
         |       |       |       |       |       |       |
         |LPM Fwd|Meter  |Shaper |MPLS   |Classi-|. . .  |
         |       |       |       |       |fier   |       |
         -------------------------------------------------

  To:
         -------------------------------------------------
         |       |       |       |       |       |       |
         |OSPF   |RIP    |BGP    |RSVP   |LDP    |. . .  |
         |       |       |       |       |       |       | CE
         -------------------------------------------------
         |               ForCES Interface                |
         -------------------------------------------------
                                 ^   ^
                                 |   |
                         ForCES  |   |data
                         control |   |packets
                         messages|   |(e.g., routing packets)
                                 |   |
                                 v   v
         -------------------------------------------------
         |               ForCES Interface                |
         -------------------------------------------------
         |       |       |       |       |       |       | FE
         |LPM Fwd|Meter  |Shaper |MPLS   |Classi-|. . .  |
         |       |       |       |       |fier   |       |
         -------------------------------------------------

[Weiming] Good catch.

3.2.  ForCES Protocol Phases

      Comments: 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.

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

 3.3.1.1.3.  Transaction protocol

   Comment: This section still has the editorial note in it as seen below.
   Please address it.

   --->
   A 2PC [2PCREF] configuration message starts with the header flags
   containg a SOT(start of transaction) and AT (Atomic Transaction) 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, one
   could use the correlator field to mark transactions and a sequence
   field to label the different messages within the same atomic
   transaction.

   Any failure notified by the FE causes the CE to execute an ABT (Abort
   Transaction) to all FEs involved in the transaction, rolling back all
   previously executed operations in the transaction.

   [Editorial Note: We need to discuss how to issue the ABORT - flags vs
   type]
   <---
[Weiming] Jamal, could you give a modification to this?

3.3.1.1.6.  execute-until-failure

   Comment: Editorial note in text. Please address.
   --->
   In which all operations are executed on FE sequentially until first
   failure.  The rest of the operations are not executed but everything
   up to failed is not undone unlike the case of all-or-none execution.

   Editorial note we need an extra main header flag to signal this .
   EUF for lack of a better name.
   <---
[Weiming] Jamal, we need to fix this also. Thanks Alex.

5.2. TLV Structuring.
   Remember to add definitions of the data types used in this draft as an
   appendix at the end of the draft.
[Weiming] Avri has had TLV type included in the IANA consideration, only the
contents are still missing. Avri, could you add it?

5.3.  ILV

   Comment: This paragraph doesn't parse well. Please correct. Also
   include a graphical representation of the ILV.

   --->
   A slight variation of the TLV known as the ILV is introduced to allow
   to the "T" to be a 32-bit index that is a ForCES element ID.  The
   Length part of the ILV is also 32 bits to allow of the referenced
   data to be arbitrarily large in size.
   <---
[Weiming] Avri, could you add a figure in the section on ILV as below?

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Identifier                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Length                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Value                                  |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.1.1.1.5.  LFB select TLV
   Comment: The last two lines of the following text don't parse well.
            Please fix.
   --->
   Operation TLV:
       It describes an operation nested in the LFB select TLV.  Note
       that usually there SHOULD be at least one Operation TLV present
       for an LFB select TLV, but for Association Setup Message defined
       in Section 6.4.1, Operation TLV is totally optional, therefore
       there might be no any Operation TLV followed in the LFB select
       TLV there.
   <---
[Weiming] Supposed change:
        ....... Operation TLV is totally optional. As a result,
       there might be no any Operation TLV followed in the LFB select
       TLV there.

6.1.1.1.6.  Operation TLV

   Replace the following text:
   --->
   The Operation TLV is an instance of TLV Idefined in Section 5.2.  It
   is assumed that specific operations are identified by the Type code
   of the TLV.  Definitions for individual Types of operation TLVs are
   in corresponding message description sections followed.
   <---

   with:

   --->
   The Operation TLV is an instance of TLV defined in Section 5.2.  It
   is assumed that specific operations are identified by the Type code
   of the TLV.  Definitions for individual Types of operation TLVs are
   in corresponding message description sections that follow.
   <---
 [Weiming] Ok, thanks.

   Replace the following text:

   --->
   A SET operation on a variable length element with a length of 0 for
   the item is not the same as deleteing it.  If the CE wishes to delete
   then the DEL operation should be used whether the the path refers to
   an array element or an optional structure element.
   <---

   with:

   --->
   A SET operation on a variable length element with a length of 0 for
   the item is not the same as deleting it.  If the CE wishes to delete
   then the DEL operation should be used whether the the path refers to
   an array element or an optional structure element.
   <---
[Weiming] Alex, do you mean to fix the two 'the' s in the text? Yes, that's a
typo error.

   6.1.1.1.7.  Result TLV

   Replace the following text:
   --->
   A RESULT TLV contains a integer (probably 4 bytes, but we only need 1
   byte) value.
   <---

   with:
   --->
   A RESULT TLV contains an integer (probably 4 bytes, but we only need 1
   byte) value.
   <---
[Weimig] Ok

6.1.1.1.9.  SET and GET Relationship

  Replace the following text:
  --->
   It is expected that a GET-RESPONSE would satisfy the following
   desires:

   o  it would have exactly the same path definitions as that was sent
      in the GET.  The only difference being a GET-RESPONSE will contain
      FULLDATA TLVs.
   <---

   with:
   --->
   It is expected that a GET-RESPONSE would satisfy the following
   desires:

   o  it would have exactly the same path definitions as what was sent
      in the GET.  The only difference being a GET-RESPONSE will contain
      FULLDATA TLVs.
   <---
[Weiming] Avri, pls decide if it should be changed.

6.2.  Core ForCES LFBs

   Coemmtn: The following text introduces the core LFBs.  They are meant to
   be statically defined, and yet they are logical elements.  How are they
   instantiated? Who creates them?

   --->
   There are two LFBs that are used to control the operation of the
   ForCES protocol and to interact with FEs and CEs:

      FE Protocol LFB

      FE Object LFB

   Although these LFBs have the same form and interface as other LFBs,
   they are special in many respects: they have fixed well-known LFB
   Class and Instance IDs.  They are statically defined (no dynamic
   instantiation allowed) and their status cannot be changed by the
   protocol: any operation to change the state of such LFBs (for
   instance, in order to disable the LFB) must result in an error.
   Moreover, these LFBs must exist before the first ForCES message can
   be sent or received.  All attributes in these LFBs must have pre-
   defined default values.  Finally, these LFBs do not have input or
   output ports and do not integrate into the intra-FE LFB topology.
   <---
[Weiming] Alex, I think the text above has addressed in some way what you
concerned, hasn't it?

6.2.1.  FE Protocol LFB

   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.  The FE Protocol LFB Instance ID is assigned
   the value 0x1.  There MAY be one and only one instance of the FE
   Protocol LFB in an FE.  The values of the attributes in the FE
   Protocol LFB have pre-defined default values that are specified here.
   Unless explicit changes are made to these values using Config
   messages from the CE, these default values MUST be used for the
   operation of the protocol.

   Comment:  How and when is the FE Protocol LFB instantiated? Is there
   supposed to be a message to effect this?
[Weiming] No, the FEPO will be static and will always be there when FE is
booted.

6.4.1.  Association Setup Message

   --->
   This message is sent by the FE to the CE to setup a ForCES
   association between them.  This message could also be used by CEs to
   join a ForCES NE, however CE-to-CE communication is not covered by
   this protocol.
   <---

    Comment: What does the CE do with this message? How does the CE process
    it?   What determines success or failure of this request?
[Weiming] I also think this text on CE use of the message leads to some
confusion. I suppose  to remove the latter sentence "This message could also be
used by CEs to  join a ForCES NE, however CE-to-CE communication is not covered
by  this protocol." totally.

6.4.3.  Association Teardown Message

   --->
   This message can be sent by the FE or CE to any ForCES element to end
   its ForCES association with that element.

   Message transfer direction:
       CE to FE, or FE to CE (or CE to CE)
   <---

   Comments:  This request needs a handshake between peers involved in the
   transaction.  So, you need a response couterpart.  This is be crucial
   for breaking down association in a redundant network where you are
   running active/standby and the active association is being torn down.
   It affords graceful teardown of association, allowing the standby
   element to assume operation and thereby preventing loss of traffic that
   will otherwise occure if you don't handshake.
[Weiming] We may need to have more discussion on the necessity of teardown ACK.
My personal thought is we may not have it, just considering the teardown sender
side may even not able to work further even if the teardown is not ACKed by peer
side, i.e., Teardown may have to be a little rude for the sender side to do.

 6.5.1.  Config Message

   --->
   This message is sent by the CE to the FE to configure LFB attributes
   in the FE.  This message is also used by the CE to subscribe/
   unsubscribe to LFB events.

   As usual, a config message is composed of a common header followed by
   a message body that consists of one or more TLV data format.
   Detailed description of the message is as below.
   <---

   Comments: What does the FE do with this message? How is it handled?
   In otherwords, what is the protocol mechanism for this request in the FE?
[Weiming]Configing FE is to command FE to do the configuration. I'm not very
sure what you really mean here, could give more text?

6.7.  Event Notification Message

   Comments: It seems to me that events can also travel from CEs to FEs.
   The paragraph below needs to acknowledge that fact.

   --->
   Event Notification Message is used by FE to asynchronously notify CE
   of events that happen in the FE.

   All events happen in FE are subscribable by CE.  A config message is
   used by CE to subscribe/unsubscribe for an event in FE.  To subscribe
   to an event is usually by specifying to the path of such an event as
   described by FE-Model and defined by LFB library.
   <---
[Weiming] pls see Jamal's comment on this.

6.8.  Packet Redirect Message
   Comment: Replace the following text:
   --->
   Packet redirect message is used to transfer data packets between CE
   and FE.  Usually these data packets are IP packets, though they may
   sometimes associated with some metadata generated by other LFBs in
   the model, or they may occasionally be other protocol packets, which
   <---

   with:
   --->
   Packet redirect message is used to transfer data packets between CE
   and FE.  Usually these data packets are IP packets, though they may
   sometimes be associated with some metadata generated by other LFBs in
   the model, or they may occasionally be other protocol packets, which
   <---
[Weiming] Ok, Thanks.

6.10.  Operation Summary
   Comments: Replace the following text:
   --->
   The following talbe summarises the applicability of the FULL/SPARSE
   DATA TLV and the RESULT TLV to the Operation TLVs.
   <---

   with:
   --->
   The following table summarises the applicability of the FULL/SPARSE
   DATA TLV and the RESULT TLV to the Operation TLVs.
   <---
[Weiming] Thanks. Avri, pls note the typo 'table'.

7.1.  Association Setup state

   Comments: The third sentence in the paragraph below doesn't parse.
             Please correct.
   --->
   This is typically followed by capability query, topology query, etc.
   When the FE is ready to start forwarding data traffic, it sends a FE
   UP Event message to the CE.  When the CE is ready, it by enabling the
   FE by setting the FEStatus to Adminup [Refer to Model draft for
   details].  This indicates to the FE to start forwarding data traffic.
   At this point the association establishment is complete.  These
   sequences of messages are illustrated in the Figure below.
   <---
[Weiming] Avri, pls fix it.

9.1.2.  Message authentication
   Comments: Recommend a method or protocol to use here.

   --->
   When CE or FE generates initiates a message, the receiving endpoint
   MUST validate the initiator of the message by checking the common
   header CE or FE identifiers.  This will ensure proper protocol
   functioning.  We recommend this extra step processing even if the
   underlying TLM layer security services.
   <---
[Weiming] Hormuzd, could you give some comments here? BTW, I just found we may
need to check Section 9 (security) for the consistency also. I think there may
be some inconsistency regarding HA and backup CEs.