Subject: [sfc] NSH Timestamp

From: "Browne, Rory" <[email-masked]>
Date: Fri, 23 Oct 2015 16:45:14 +0000

Please see below a link to a draft on performance monitoring of service chains using NSH

https://tools.ietf.org/html/draft-browne-ietf-sfc-nsh-timestamp-00

Comments welcome

BR Rory

--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 25 Oct 2015 12:49:13 +0000

Hi Rory,

I believe that in-band timestamps can certainly be a useful feature in NSH.

Major comments:

1.       The draft currently does not clarify the use case. While the draft describes how the timestamp is inserted into the NSH, I could not find a description of how the timestamp is *used*, and what is the expected accuracy. It is hard to assess whether the solution is adequate without understanding the requirement.

2.       Why does the draft mandate specific synchronization protocols (NTP, Sync-E, PTP)? It seems that if you are defining an NSH timestamp TLV, you can avoid limiting the solution, and leave the synchronization protocol out of scope.

3.       The timestamp formats are not clearly defined. Specifically, the term "UTC format" is used throughout the document. I believe UTC defines a time reference, not a timestamp format. Did you mean NTP Timestamp format / PTP Timestamp format / RFC 3339 / other?

Other comments:

*         Section 3.1:

You require both Synchronous Ethernet (2), and IEEE 1588 for frequency distribution (3). These seem like two overlapping requirements. Why do you require both? Perhap you meant that IEEE 1588 should be used for *time* distribution?

*         Could you explain why you require very accurate frequency synchronization, but inaccurate time synchonization (section 3.1)?

*         The format of the fields "UTC Reference", "Ingress Timestamp", and "Egress Timestamp" is not clear.

*         Section 3: the terms SCL and FTSN are used before they are defined. SCL is not defined at all. I guess you mean Service Classifier, but this should be specified.

*         The terms "time stamp" and "timestamp" are used intermittently. I believe "timestamp" is the most common form in IETF documents.

*         "The FTSN also writes the UTC value into the header so the" - this sentence is not clear at this point.

*         The terms NTP and IEEE 1588 are used without a reference to the relevant standards.

*         Could you please clarify the following sentence:
     "the UTC stamp is merely being used as a reference inserted into
      the TSDB for performance monitoring. It is not a reference for the
      timestamp itself."

Regards,
Tal.

From: sfc [mailto:[email-masked]] On Behalf Of Browne, Rory
Sent: Friday, October 23, 2015 7:45 PM
To: [email-masked]
Subject: [sfc] NSH Timestamp

Comments welcome

BR Rory

---

From: "Browne, Rory" <[email-masked]>
Date: Tue, 27 Oct 2015 18:38:29 +0000

Thanks for the detailed comments Tal

Replies inline

BR Rory

From: Tal Mizrahi [mailto:[email-masked]]
Sent: Sunday, October 25, 2015 12:49 PM
To: Browne, Rory; [email-masked]; [email-masked]
Subject: RE: NSH Timestamp

Hi Rory,

Major comments:

RB: We want to be able to tell if a VNF or and underlay segment is misbehaving on subscriber traffic. Expected accuracy in the low 10s of microseconds.

RB: True. We will consider this on next iteration.

RB: Sorry - sloppy on our behalf. Yes NTP timestamp format as per section 6 of RFC5905

Other comments:

*        Section 3.1:

RB: No we require either

RB: The time of day used at the start of the header does not have to be very accurate (Can be 10's of ms out for example) the PTP needs to me more accurate (in 10s of microsecond range)

RB: Can you explain

RB: FTSN is defined (could be improved though) before usage I think. SCL should be defined  - agreed.

RB: Noted. Will fix this in next revision

RB: FTSN writes NTP format into the header

RB: Thanks We will reference standards in next revision

RB: The NTP stamp is being used by performance management system (PMS) to identify when the monitoring of the flow begun. This is held in the TSDB and may be retrieved by the PMS for trend analysis of SC performance.

Regards,
Tal.

From: sfc [mailto:[email-masked]] On Behalf Of Browne, Rory
Sent: Friday, October 23, 2015 7:45 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] NSH Timestamp

Comments welcome

BR Rory

Intel Research and Development Ireland Limited

This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 28 Oct 2015 09:05:28 +0000

Hi Rory,

Thanks for the detailed response.

A few follow-up questions/comments:

>1.      The draft currently does not clarify the use case. While the draft
>describes how the timestamp is inserted into the NSH, I could not find a
>description of how the timestamp is *used*, and what is the expected
>accuracy. It is hard to assess whether the solution is adequate without
>understanding the requirement.
>
>RB: We want to be able to tell if a VNF or and underlay segment is
>misbehaving on subscriber traffic. Expected accuracy in the low 10s of
>microseconds.

10s of microsecond: do you see this as a requirement, or is it a best practice based on what common IEEE 1588 equipment can provide?
Can you please give a short example that explains why 10s of microseconds is necessary?
I would strongly recommend to add a section in the draft (preferably at the beginning) that would describe these use cases and accuracy requirements in detail.

>.        Could you explain why you require very accurate frequency
>synchronization, but inaccurate time synchonization (section 3.1)?
>
>RB: The time of day used at the start of the header does not have to be very
>accurate (Can be 10's of ms out for example) the PTP needs to me more
>accurate (in 10s of microsecond range)

- Can you please clarify this point: what is the difference between how the timestamp-at-the-start-of-the-header is used and how the other timestamps are used?
- PTP provides the time-of-day with a microsecond accuracy, so why would we need an additional less accurate time reference?

>
>.        The format of the fields "UTC Reference", "Ingress Timestamp", and
>"Egress Timestamp" is not clear.
>RB: Can you explain
>

Based on your response, I understand that <UTC Reference> uses the NTP 64-bit timestamp format.
Is the same format used also for <Ingress Timestamp> and <Egress Timestamp>? This should be defined explicitly in the draft.

Cheers,
Tal.

---

From: "Browne, Rory" <[email-masked]>
Date: Wed, 28 Oct 2015 10:15:28 +0000

More inline Tal

BR Rory

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Wednesday, October 28, 2015 9:05 AM
To: Browne, Rory; [email-masked]; [email-masked]
Subject: RE: NSH Timestamp

Hi Rory,

A few follow-up questions/comments:

>1.      The draft currently does not clarify the use case. While the 
>draft describes how the timestamp is inserted into the NSH, I could not 
>find a description of how the timestamp is *used*, and what is the 
>expected accuracy. It is hard to assess whether the solution is 
>adequate without understanding the requirement.
>

RB: That's probably a good idea. 10s of microsecond is a requirement as the transit times we are seeing for reasonably simple VNFs is in the order of low 100s of microseconds to over a millisecond depending on packet size, load etc. So an accuracy in the low 10s of microseconds should be ample to indicate user plane performance issues. We will know more once this is coded and tested.

>RB: The time of day used at the start of the header does not have to be 
>very accurate (Can be 10's of ms out for example) the PTP needs to me 
>more accurate (in 10s of microsecond range)

RB: The reasoning behind this is if the classifier does not support 1588, but does support NTP. This seems to be the case for some vendors at least with appliance based SCLs.

>
>.        The format of the fields "UTC Reference", "Ingress Timestamp", 
>and "Egress Timestamp" is not clear.
>RB: Can you explain
>

RB: Agreed

Cheers,
Tal.