Re: [mpls] review of draft-mirsky-mpls-residence-time

[Alexander Vainshtein <[e-mail]>]

Yaakov,

Lots of thanks for a very detailed review.

I defer to other co-authors to describe the relevant use cases in more detail.



I just wanted to comment on two points:

1. The draft does not use GACh TLVs (that have been deprecated BTW).

2. A legacy device that does not have RTM capabilities will never inspect the GAL/GACh construct used in the draft, because such inspection can only happen either at the LSP tail-end node or at an RTM- capable node that traps the RTM packet due to TTL expiration.

This last point is IMHO a major differentiator between this draft and one handled by the TICTOC WG:

- this draft does not change the MPLS DP as defined in RFC 3031 and RFC 3443

- the TICTOC draft (at least to the best of my recollection) assigned special handling to labels used by the LSPs carrying PTP packets that was not defined as a "label action" in RFC 3031 (neither Pop, nor Swap nor Push).



Regards,

Sasha





Thumb typed on my LG,
Sasha

------ Original message ------
From: Yaakov Stein
Date: 26/05/2015 08:11
To: [e-mail];
Subject:[mpls] review of draft-mirsky-mpls-residence-time

Loa asked me to comment on this draft before its acceptance as a MPLS WG draft.

As far as I understand, the purpose of this draft is to provide a form of what is called “on-path timing support” in the TICTOC WG.
The specific kind of on-path support is accumulation of residence times in LSRs which a time-sensitive flow traverses.
As such it is essentially the same as what is called “transparent clocking” (TC) in IEEE 1588, and the draft indeed re-uses TC technologies.

However this draft attempts to remedy a problem with TC as presently implemented – its layer violation.
This violation occurs since physical layer timing information is used to modify a field of a higher layer protocol.
The present draft remedies this by forcing hop-by-hop behavior by TTL field manipulation,
but at the price of having to transport timing flows in the associated channel,
previously limited to OAM and control/management plane uses.

As such the draft elegantly solves a theoretical problem.

I am less sure that it solves a real-world problem, for the following reasons :

1. First is the fact that there is a simpler alternative for on-path support of 1588 over MPLS that has already passed WG LC in TICTOC.
The existing TICTOC draft was purposely constrained
(following advice of reviewers who are MPLS experts)
to not touch the MPLS forwarding plane, while this draft defines GACh TLVs and sub-TLVs.
The present draft is admittedly much wider in applicability, but no use other than 1588 on-path support is described in the draft.

2. One conceivable use would be for highly accurate one-way delay estimation without synchronized clocks
(and I am not sure when this use is really needed).
Of course the present method only accounts for residence time in LSRs, not for propagation latencies on links (which 1588 can handle as well).
The methodology to overcome this limitation would assumably be to rely on a co-routed round-trip, to us this draft to cancel residence times,
and then to measure the remaining round-trip time and divide by two.
However, existing algorithms do a pretty good job at cancelling residence times
except when the flow traverses a large number of network elements which are heavily loaded with plesiochronously related interfering flows.
Do the authors have another use case in mind ?

3. The primary documented application for 1588 in telecom networks is cellular backhaul.
This application already has a plethora of solutions, based on GPS, 1588 over Ethernet with boundary clocks (BC), distributed grand masters, etc. etc. etc.
Note that BC as widely deployed is already hop-by-hop, and in that way similar to this draft.
Is yet another solution really needed ?

4. Related to the previous questions is the issue of implementation in already existing networks.
This solution requires hardware upgrades at least for the accurate time-stamping and possibly for the accumulation and field modification
(although the latter may software upgrades, especially if 2-step correction is utilized).
If we need to upgrade hardware, why not deploy BCs ?
A few years back I would have said that TC could be implemented in miniaturized devices where BC could not,
but advances in miniaturization of OCXOs have severely reduced this advantage to cases where atomic-clock hold-over is required.

5. If another solution for this specific application is needed, is it needed for MPLS ?
Cellular backhaul over carrier Ethernet is widely deployed, is cellular backhaul over MPLS sufficiently widespread to merit this extension ?

6. MPLS does not define its own physical layer (which Ethernet does – the layer called ETY in the ITU).
As such it is not clear that MPLS is the right place to solve the timing distribution problem.
MPLS necessarily runs over some physical layer which may already have on-path support, or may more economically support it.

All of the authors work for vendors – have these vendors implemented this or do they plan implementing ?
If the answer is a resounding yes, then I assume that we will hear rebuttals to most of the above remarks.

Regarding the content of the draft, I have a major issue with the use of the term “Scratch Pad” for the correction field
(and BTW, it is sometimes called “Scratch Pad” and sometimes “ScratchPad” and sometimes “scratch pad”).
This field is not some opaque meta-data transported by this newly defined header,
it is the very crux of the solution and requires manipulation to work.
Calling it a “scratch pad” (with any of the spellings) is tantamount to calling an MPLS label an “arbitrary bit-field”.
Both terms may be technically correct, but hide the meaning of the field and increase the load on reader in understanding the technology.

As an aside, the aforementioned TICTOC WG draft originally contained extensions to OSPF, RSVP-TE, etc.
It was decided to separate the control extensions from the forwarding plane draft, and to pursue each in the most appropriate WG.
It might be a good idea to do the same here.

One of the facts of life with on-path support of timing distribution is that it is often only partial.
What happens to this solution when there is only partial support?
I can imagine unrecognized GACh packets being booted to CPU in such cases, severely impacting uncompensated residence time.

Y(J)S