Re: [sfc] Review comments for draft-agv-sfc-packet-loss-measurement-01

[Gaurav agrawal <[e-mail]>]

Hi Phaneendra,

Thanks for your feedback and suggestions again on this draft as well :).

Please find in-line comments.

Thanks and Regards,
Gaurav

From: sfc [mailto:[e-mail]] On Behalf Of Phaneendra manda
Sent: 2016Äê11ÔÂ23ÈÕ 18:18
To: [e-mail]
Cc: Aruna kumar padhi
Subject: [sfc] Review comments for draft-agv-sfc-packet-loss-measurement-01

Hi Authors,

Please find the below review comments for draft-agv-sfc-packet-loss-measurement-01


1.      In Section 1.3

   This document defines the implementation mechanism for the packet
   loss measurement as per performance measurement architecture [SFC-PM-
   arch]. This document defines a new NSH message format for carrying
   packet loss measurement related control information. It also defines
   operations to be carried out for packet loss measurement.
   communication mechanism between measurement controller, measurement
   collector and MA is out of scope of this document.

   Can be


   This document defines the implementation mechanism for the packet

   loss measurement as per performance measurement architecture [SFC-PM-

   arch]. This document defines a new NSH message format for carrying

   packet loss measurement related control information. It also defines

   operations to be carried out for packet loss measurement.

   Communication mechanism between measurement controller, measurement

   collector and MA is out of scope of this document.



[Gaurav] Agree, text will be updated accordingly.


2. In section 2.1

The length is only 5 bits in Performance Measurement Context Header TLV. In the TLV, it includes the list of MA Identifiers. So the max MA Identifiers that can be in the list is 31 (4 byte used for Measurement Window Index and Reserved). This list can include max of 31 MA Identifiers for both SFF and SF. Where there is no limit for SF¡¯s can be max of 31 in a Service Function Chain. I think the length field need to be revised.



[Gaurav] Performance measurement specific to SF/SFF is expected to be carried out when a problem is identified using the E2E and then Hop by hop measurement. So, to check specific limited sets of SF/SFF max limit of 31 is considered in the draft, text will be added to clarify the same.



3. In section 2.2

 Reserved: Reserved 16 bits for future purpose.   ¨C Is repeated twice.

[Gaurav] Agree, text will be updated accordingly.



4. In section 2.3,

      The method of encoding the PMF id is done using the flow id defined in [I-D.ietf-sfc-nsh<https://tools.ietf.org/html/draft-agv-sfc-packet-loss-measurement-01#ref-I-D.ietf-sfc-nsh>]. ¨C But I could not find any flow id defined in ietf-sfc-nsh draft.

[Gaurav] Will update with correct reference.



5. In section 3.5

I think it should collect the stats at outgoing port only when packet loss measurement is initiated.



[Gaurav] Agree, text will be updated to mention about carrying out the measurement only when required.



6. In section 3.7

I think this can include one more scenario, packet loss when a Service function is Down.



[Gaurav] Yes you are right with this mechanism we can find out if a specific MA is down,  we will add a text to mention the same.



7. I think this draft considers only static Service Function Path. I suggest this draft can also include the below scenarios

- Dynamic SFP as mentioned in RFC 7665 section 5.2

                    [Gaurav] Frankly speaking, I am not clear about the scenario specified in section 5.2 of RFC 7665, we can further explore this.

- Bidirectional SFC

                    [Gaurav] Actually draft approach can very well accommodate this, I can add a text to clarify this.

- Reclassification and branching as mentioned in RFC 7665 section 4.8

    [Gaurav] Its basically programming re-classifier to update required metadata, I will add a section to cover this.






Thanks & Regards,
Phaneendra Manda.