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

Gregory Mirsky <gregory.mirsky@ericsson.com> Mon, 08 June 2015 05:04 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85F81B2B8C for <mpls@ietfa.amsl.com>; Sun, 7 Jun 2015 22:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.5
X-Spam-Level:
X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpkVQUcACfoC for <mpls@ietfa.amsl.com>; Sun, 7 Jun 2015 22:04:06 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB4D1B2B8B for <mpls@ietf.org>; Sun, 7 Jun 2015 22:04:06 -0700 (PDT)
X-AuditID: c618062d-f79a96d000007fb1-82-5574c8a55915
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.55.32689.5A8C4755; Mon, 8 Jun 2015 00:41:42 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Mon, 8 Jun 2015 01:04:04 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Yaakov Stein <yaakov_s@rad.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: review of draft-mirsky-mpls-residence-time
Thread-Index: AdCXce5XYGawVXbQSuScrPNidlsKQAKNkxlw
Date: Mon, 08 Jun 2015 05:04:04 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B9B3417@eusaamb103.ericsson.se>
References: <DB5PR03MB0999B4968F075828150C99FCE5CC0@DB5PR03MB0999.eurprd03.prod.outlook.com>
In-Reply-To: <DB5PR03MB0999B4968F075828150C99FCE5CC0@DB5PR03MB0999.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B9B3417eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPiO6yEyWhBks62S1uLV3JavGh6wer A5PHkiU/mTwmrU0LYIrisklJzcksSy3St0vgytj8Q6/gex9jxfHjE9gbGBdWdjFyckgImEj0 Lz3ABmGLSVy4tx7I5uIQEjjKKLHy2iwWCGcZo8S2G/+ZQarYBIwkXmzsYQexRQRcJHZt3M0I YgsLmEvs3TGLDSJuIbG6/xZQDQeQbSRxYoMVSJhFQEVi7pt7rCA2r4CvxNMl78HKhQRiJDY3 PAIbwykQK9H6sQEszgh00PdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQtpLEnNfX mCHq8yX2TD7OCLFLUOLkzCcsExhFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyE LL6AkX0VI0dpcWpZbrqRwSZGYOwck2DT3cG456XlIUYBDkYlHt4Ev5JQIdbEsuLK3EOM0hws SuK8jlF5oUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY5xdziQkzrJlvfkyk6m9JTeFNwYbp J5z6Zj4RO+MX0BTfXd4s5r1YsMzj3gfFFhb39gdvXpU9bFOTL9zcwcDqcerGgisa7JNf7Umb Ojfj8fH57fv/vzISfGoXOs9sutbjMnM9b5vDZ6y1+B8+nD1r24L531lcTT8E3rkkseFFY/zc nZ/8WS9vVGIpzkg01GIuKk4EAC1X9Q1+AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/548ph9Idwu7XPvqawpEP1LQaGMo>
Subject: Re: [mpls] review of draft-mirsky-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2015 05:04:11 -0000

Hi Yaakov,
greatly appreciate your most detailed review. We are looking forward to continue the discussion in Prague.

                Regards,
                                Greg

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent: Monday, May 25, 2015 10:11 PM
To: mpls@ietf.org
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