IETF Logo Mail Archive

Re: [TICTOC] Enterprise profile update

Richard Cochran <richardcochran@gmail.com> Tue, 08 April 2014 20:08 UTC

Return-Path: <richardcochran@gmail.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58521A0735 for <tictoc@ietfa.amsl.com>; Tue, 8 Apr 2014 13:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 qlwPAsaJSqe0 for <tictoc@ietfa.amsl.com>; Tue, 8 Apr 2014 13:08:38 -0700 (PDT)
Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3A1A0218 for <tictoc@ietf.org>; Tue, 8 Apr 2014 13:08:38 -0700 (PDT)
Received: by mail-ee0-f52.google.com with SMTP id e49so1076124eek.25 for <tictoc@ietf.org>; Tue, 08 Apr 2014 13:08:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=t18iBxBY85SzxtfhHOa/lNz7W3kCqqtFyld+1K1c0JY=; b=X/3KaaeMOnscIu/PfoK1wK+DH95S2/FrjpeY+CUo8PKU8/pcaSWfmb3EapnE3qugOM OganS5VX9pqD5+RNDf4Y0MWYaFSjTxD1iDVo9vk9FDCbwyyZUepbqCPuhdmjzuRAt5Qz TtpZBa776lWwbaM2jLlcl+NhZPFr3gQqJ7tY/xujtaWyJBj9L74mcx+d6aqdLNriWONO iyje/DJG3QwDOI2nbSqTQWGi5tgcr2iKlx1fw5OuUnAR2tN/R55MRQ+6rpryq7cBruL3 S8AvAb5hNotxIauC5HwjLyORaVWVi22P/xGEF30t5NSDx1LbNfGK8TGUnWK3n8vSL4Ng 6f6w==
X-Received: by 10.15.51.141 with SMTP id n13mr6700578eew.17.1396987717638; Tue, 08 Apr 2014 13:08:37 -0700 (PDT)
Received: from netboy (089144223168.atnat0032.highway.bob.at. [89.144.223.168]) by mx.google.com with ESMTPSA id w1sm6697781eel.16.2014.04.08.13.08.35 for <multiple recipients> (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 08 Apr 2014 13:08:36 -0700 (PDT)
Date: Tue, 08 Apr 2014 22:08:30 +0200
From: Richard Cochran <richardcochran@gmail.com>
To: Kevin Gross <kevin.gross@avanw.com>
Message-ID: <20140408200830.GA30453@netboy>
References: <CACQYgzE106JaKArgc=3HKkKcrdvSy5PmK-A0=_ZMdfrFUJbrtQ@mail.gmail.com> <20140405112034.GM22106@netboy> <20140405133748.GB4566@netboy> <CALw1_Q3hNRNpHzQ=1z0XRTqvcvm2W7=Gm_ZWa2UJT-BqYTvmZw@mail.gmail.com> <CF68E7A8.7488B%lmontini@cisco.com> <1D3F6A7C-AD27-4A63-9F63-41D9929AE285@owczarek.co.uk> <20140408144527.GA5087@netboy> <CALw1_Q1ObS652A+GazmmB4gfkNnnJ4DcsiJ5PoQCd6wxNw-mrA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALw1_Q1ObS652A+GazmmB4gfkNnnJ4DcsiJ5PoQCd6wxNw-mrA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/RlcMOJgHAAjL3nzsynMfV5IvihA
Cc: "tictoc@ietf.org" <tictoc@ietf.org>
Subject: Re: [TICTOC] Enterprise profile update
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Apr 2014 20:08:40 -0000

On Tue, Apr 08, 2014 at 01:09:58PM -0600, Kevin Gross wrote:
> 
> The objection I've heard to 16.1 is that it imposes arguably unnecessary
> overhead in setting up unicast delay request/response. It is simpler for a
> master just to know (based on profile) that when it receives a unicast
> delay request, it should simply generate a unicast response to the sender.
> If the enterprise profile is defined to work in this way, a slave can
> switch mode on the fly and quickly compare results between unicast and
> multicast and determine the best mode of operation.

Yes, I agree that 16.1 is a real PITA to implement. However, that is
what is in the standard. It seems strange to me that profiles should
try and second guess aspects that are already standardized. The more
profiles do that, the harder it gets for humble implementations to
support the many variations.

Is there a feeling that 16.1 was a mistake, is not implemented in real
life, and is disappearing in the next 1588 edition?

If so, I'll surely *not* bother to implement it in linuxptp.

Thanks,
Richard

v2.23.0 | Report a Bug | By Email