Re: [sfc] Few Querries from draft-agv-sfc-packet-delay-measurement-00

[Gaurav agrawal <[e-mail]>]

Hi Nobin,

Please find the in-line response [Gaurav-2]

Also we have revised the draft, kindly review the new versions

https://datatracker.ietf.org/doc/draft-agv-sfc-performance-measurement-architecture/
https://tools.ietf.org/html/draft-agv-sfc-packet-delay-measurement-01
https://datatracker.ietf.org/doc/draft-agv-sfc-packet-loss-measurement/

Thanks and Regards,
Gaurav

From: Nobin Mathew [mailto:[e-mail]]
Sent: 2016年6月28日 16:06
To: Gaurav agrawal
Cc: Anil Kumar S N (VRP Network BL); VinodS Kumar; [e-mail]
Subject: Re: [sfc] Few Querries from draft-agv-sfc-packet-delay-measurement-00

Hi Gaurav,
Thank you for the clarification. I have few more queries, please find them in-line. [tag: NOBIN-1]
Please address these points in both packet-delay and packet-loss measurement drafts.

On Tue, Jun 28, 2016 at 11:35 AM, Gaurav agrawal <[e-mail]<mailto:[e-mail]>> wrote:
Hi Nobin,

Thanks for your comments, please find the response in-line.

From: Nobin Mathew [mailto:[e-mail]<mailto:[e-mail]>]
Sent: 2016年4月20日 18:35
To: Anil Kumar S N (VRP Network BL); Gaurav agrawal; VinodS Kumar
Cc: [e-mail]<mailto:[e-mail]>
Subject: [sfc] Few Querries from draft-agv-sfc-packet-delay-measurement-00


Hi Anil Kumar S N, Gaurav Agrawal,Vinod Kumar S,

I have few question with respect to the delay calculation method described in the draft "draft-agv-sfc-packet-delay-measurement-00".
Please let me know your opinion on this queries.


1)
-------------------------draft section---------------------------------------
   3.6 Incoming Packets Processing at MA

      On receiving the packet with NSH header following operations are
      carried out:

      Step 1: Detection of PM Context Header in a packet, by verifying
              the PM TLV Class as allocated by IANA.
              (If not detected, move to step 6)

      Step 2: Check if PM Type field value is 6 to 10.
              (If not move to step 6).

      Step 3: If PM Type Value = 7 to 10 move directly to Step 5

      Step 4: Check Presence of self Service index in Service Index List
              (If not present, move to step 6)
---------------------------------------------------------------------------

MA can be SF or SFF , but based on the steps given here, SFF cannot do the time recording or report to collector because
step 4 checks the SI index and SFF we do not have Si index.

[ SI: List of participating Service functions in the SFP. It SHOULD be
   in decreasing order of the SI for optimized traversal of the SI
   participation. ]

So i thing we need to address SFF scenario as well.

[Gaurav-1] Initially we thought of handling SFF during hop by hop measurement scenario only. But we see a valid point here from you, in the new revision of

draft we are planning to introduce MA identifier which will be combination of node identifier (unique number configured by controller) and order identifier (SI)

to address performance measurement of SFF in all scenarios.

   [NOBIN-1]   Unique number for SFF is assigned per Flow or its global ? if its global then how you will track different paths ? I think you may need to include the Path/flow identifier along with other two identifiers given here.
                     Do you have plan to assign a unique number for each SF in a service path ? If you do not do this , then i think the context header structure will be different for SF and SFF, please clarify.

[Gaurav-2] Unique number for SFF will be global and yes you are right flow identifier (PMF id) is used together for identification
For Example: Please refer section 3.2 in packet delay measurement draft
   1) Rx-Time[P][M][W]
   2) Tx-Time[P][M][W]

For SF identification, SFC already incorporates a mechanism of Service Index and we re-use the same. Unification of context header is taken care of, kindly refer section 2.2 of packet delay draft
   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.
    2) Context identifier - 8 bit
       a) For SFF: Service index of next SF.
       b) For SF: Service index


2)
     +---+                                          +----+
     |SF |--------------------+        +------------|SF  |
     |   |....... ----------+  \      / /+----------|    |
     +---+                   \  \    / /            +----+
                         +---2 -3-+-4--5--+
                         |   SF Forwarder |
                   -----1|      (SFF)     |6------
                         +-------+--------+

As per the method specified in this draft MA will record 'timestamp' when a packet ENTER and EXIT and this 'timestamp'
will be notified to the controller. but if we consider the above topology SFF has multiple entry and exit ports so
each time these entries[timestamp] will be overwritten by the MA when the packet traverse and we will not get the correct delay
because of this.

I feel we need to track each ENTRY and EXIT separately to track the delay correctly.

[Gaurav-1] We agree with your point, MA identifier MUST be present while reporting statistics to collector using which we can track the same. We will handle this in new revision of our

Draft.


[NOBIN-1] "MA identifier MUST be present while reporting statistics to collector"   Do you mean [SI + unique number for SFF] ?
                          You may also need to include Path/flow identifier along with other two identifiers given here as i given above at point 1

     [Gaurav-2] Yes you are right, statistics are maintained and reported as a three dimensional array
   1) Rx-Time[P][M][W]
   2) Tx-Time[P][M][W]
P stands for PMF ID, M stands for MA identifier and W   stands for window ID
3.8<https://tools.ietf.org/html/draft-agv-sfc-packet-delay-measurement-01#section-3.8> MA Reporting the Statistics to Collector


   Reporting timer will run on each MA. Consistency of this timer should
   be ensured across the entire MA in the SFP, ensuring the same is out
   of scope of this document.

   On expiry of this timer following information needs to be sent to the
   collector.

       - MA identifier

       - PM type value

       - Value of all the collected Rx-Time[P][M][W], Rx-Sum-
         Time[P][M][W], & Rx-Sample-Count[P][M][W] parameters along with
         the corresponding PMF ID and window Id

       - Value of all the collected Tx-Time[P][M][W], Tx-Sum-
         Time[P][M][W], & Tx-Sample-Count[P][M][W] parameters along with
         the corresponding PMF ID and window Id


3)
------------------------------draft section----------------------------------------------------------------
3.8 MA Reporting the statistics to Collector

   Reporting timer will run on Each MA. Consistency of this timer should
   be ensured across the entire MA in the SFP, ensuring the same is out
   of scope of this document.

   On expiry of this timer following information needs to be sent to the
   Collector.

       - Service Index

       - PM Type Value

       - Value of all the collected Rx-Time[P][W], Rx-Sum-Time[P][W],
         & Rx-Sample-Count[P][W] parameters along with the
         corresponding PMF ID and Window Id

       - Value of all the collected Tx-Time[P][W], Tx-Sum-Time[P][W],
         & Tx-Sample-Count[P][W] parameters along with the
         corresponding PMF ID and Window Id

   MA may delete the parameters after sending the same to collector.
-----------------------------------------------------------------------------------------------------------

If the MA is in SFF the what is the ID to track the device, Service index can be used for SF but not for SFF ?

[Gaurav-1] Point 1 and 2 will be taking care of this point too.

4)
------------------------draft section------------------------------------------
   - If Value = 0x7, 0x8, 0x9, 0x10
          o No need to encode SI, since the type dictates the involved
            participating MA
-------------------------------------------------------------------------------

I think 0x10 should be 0xA ?

[Gaurav-1] Will be addressed in new version


5)
----------------------------draft section---------------------------------------

3.7 Outgoing Packets Processing at MA

      At outgoing port of MA following operations are carried out.

      Step 1: If Option 1 is used then go to Step 2a, if Option 2 is
              used then go to Step 2b

      Step 2: If Option 1 is used then go to Step 2a, if Option 2 is
              used then go to Step 2b
--------------------------------------------------------------------------------

Steps 1 and 2 is same here.

[Gaurav-1] Will be addressed in new version


Regards
Nobin