Subject: [sfc] Review comments for : Performance Measurement Architecture for SFC

From: Phaneendra manda <[email-masked]>
Date: Tue, 22 Nov 2016 09:44:37 +0000

Hi,
Please find the below review comments for draft-agv-sfc-performance-measurement-architecture-02
1. In section 2
   Measurement Controller: An entity that controls and coordinates a set
   of measurement functions. The measurement controller is responsible
   for programming the performance measurement instance at measurement
   classifier and updating the same to measurement collector,
   additionally it can inject probe packets in SFP for measurement.

    can be

     Measurement Controller: An entity that controls and coordinates a set
   of measurement functions. The measurement controller is responsible
   for programming the performance measurement instance(PMI) at measurement
   classifier and updating the same to measurement collector,
   additionally it can inject probe packets in SFP for measurement.

   While going through document there is no abbreviation mapped for PMI. Marking this would improve the readability

2. In section 3
   Active measurement : Measurement controller induce probe packets
      with encoded performance measurement data or programs PMI at
      measurement classifier which will in turn induce probe packets
      with encoded performance measurement data. measurement controller
      updates the PMI to measurement collector. Participating
      measurement agents based on received encoded information carry out
      measurements and reports the collected data to measurement
      collector. measurement collector co-relates received data and
      provides measurement results.

   can be

  Active measurement : Measurement controller induce probe packets
      with encoded performance measurement data or programs PMI at
      measurement classifier which will in turn induce probe packets
      with encoded performance measurement data. Measurement controller
      updates the PMI to measurement collector. Participating
      measurement agents based on received encoded information carry out
      measurements and reports the collected data to measurement
      collector. measurement collector co-relates received data and
      provides measurement results.

3. In section 4.1
    "PMF identifier" - PMF is used without providing any abbreviation.

4. In section 4.3.3
    MA identifier has two parts
   1) Node identifier - 24 bit
      a) For SFF: MUST be unique number assigned by controller
      b) For SF: All zero. Context identifier itself identifies SF node.

   I think here it should be Service Index. Context identifier referred nowhere in the draft.

5. In section 4.3.3

  - At MA         : Presence of self service index triggers the
                            PM collection & reporting

  can be

  - At MA         : Presence of self MA identifier triggers the
                            PM collection & reporting

Because of below reasons
   -  A service function does not know its service index
   -  As mentioned in section 5, point 1, it is mentioned Measurement controller programs the MA identifier to MA. So the MA knows the MA identifier not the service index.

6. In section 2
   In the description of Measurement Classifier :  It can also generate probe packet. Need to be updated in description (In section 6 it is mentioned Measurement classifier may generate probe packet based on the instruction by measurement controller.

7. In Section 4.3.3
   A service function can be part of multiple service function chains, In this case the Measurement Agent will have 2 MA ID's configured.  As per the draft in section 4.3.3, there is no consideration for Service Path Index(SPI) while MA Identifier construction. So MA Identifier may have conflict.

8. In Section 4.3.3
  There is no clarity on Measurement Agent Identifier with PM type value on how it is encoded.  Like few bits are used for MA Identifier and few bits are used for PM type. It is just mentioned MA Identifier with PM type. I think more details can be provided here.

Thanks & Regards
Phaneendra Manda.

---

From: Gaurav agrawal <[email-masked]>
Date: Thu, 24 Nov 2016 12:34:29 +0000

Hi Phaneendra,

Thanks for your review and suggestions. Please find my in-line comments.

Thanks and Regards,
Gaurav

From: sfc [mailto:[email-masked]] On Behalf Of Phaneendra manda
Sent: 2016年11月22日 15:15
To: [email-masked]
Cc: Aruna kumar padhi
Subject: [sfc] Review comments for : Performance Measurement Architecture for SFC

Hi,

    can be

[Gaurav] Agree and text will be updated accordingly.

2. In section 3

   can be

[Gaurav] Agree and text will be updated accordingly.

3. In section 4.1

[Gaurav] Agree and will be added in abbreviation. We also want to add text that it’s only required
in deployments expecting to monitor fine grained flows within a coarse-grained flows.

4. In section 4.3.3

[Gaurav] Yes, it should be Service Index. Also we plan to provide more information about this:

1)      For SF, Node identifier needn’t be explicitly configured (it’s all 0), as SI is sufficient enough to uniquely identify SF.

2)      For SFF, Node identifier needs to be programmed.

3)      MA identifier is combination of Node Identifier + SI (SI value is obtained from packet itself)

4)      MA identifier is NOT required in case of E2E or Hop by hop measurement as PM type itself indicates

whether SF/SFF needs to participate in measurement.
Will update text to clarify this in draft.

5. In section 4.3.3

Because of below reasons

[Gaurav] Idea is to identify the SF or SFF in a chain (Note: This is not required for E2E or hop by hop measurement, only required in case measurement is specific to a set of SF/SFF).

Let me elaborate how draft plan to handle it.
Identify SFF: Since SPI+SI alone is not sufficient to identify SFF, draft introduce a new entity called node identifier to be configured by Controller in SFF. MA identifier for SFF is then the combination of “Node Identifier (programmed by Controller) + SI (this value is obtained from SFC service header in the packet)”. Now to identify whether it needs to carry out the measurement, SFF checks its MA identifier presence in the packet metadata.
Identify SF: For this node identifier is not required. MA identifier of SF is “Node identifier (all zero) + SI (SI value in packet)”. SF checks its MA identifier presence in packet metadata

Draft will add additional text to clarify this.

6. In section 2

[Gaurav] Agree, description will be updated accordingly.

7. In Section 4.3.3
   A service function can be part of multiple service function chains, In this case the Measurement Agent will have 2 MA ID’s configured.  As per the draft in section 4.3.3, there is no consideration for Service Path Index(SPI) while MA Identifier construction. So MA Identifier may have conflict.

[Gaurav] Yes for two different chains MA identifier computed may be same, but that is fine as this MA identifier is just used to check if the given SFF needs to carry out any measurement by checking its presence in SFC packet metadata. Please look at below example for more details.
In below example it’s expected to carry measurement at SFF1 Port P1, P2, P3, P4 and its also expected to carry out measurement at SF3. So below picture depicts the behavior.

8. In Section 4.3.3

[Gaurav] Agree and text will be added for the same.

Thanks & Regards
Phaneendra Manda.