IETF Logo Mail Archive

Re: [TICTOC] Enterprise profile update

Richard Cochran <richardcochran@gmail.com> Wed, 09 April 2014 06:42 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 DC0EF1A0132 for <tictoc@ietfa.amsl.com>; Tue, 8 Apr 2014 23:42:21 -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 TMEPeSir9Vgl for <tictoc@ietfa.amsl.com>; Tue, 8 Apr 2014 23:42:20 -0700 (PDT)
Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0221E1A012C for <tictoc@ietf.org>; Tue, 8 Apr 2014 23:42:19 -0700 (PDT)
Received: by mail-ee0-f53.google.com with SMTP id b57so1461174eek.12 for <tictoc@ietf.org>; Tue, 08 Apr 2014 23:42:19 -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=mQ1KVXXsXqLwP/o47Aa2wOvRYixpVlgKF3AJj5xndgg=; b=KVuDJDEnbqrHZ5HalNMxDr7iSimiIbJ8OGPBAQW17pRUcrcYKXeHmQeT6BDRLsPXP7 A9JX4hNqxxbcTyWSUdF8j1ZrN+hsfxjVG8oCvfUEZCDj43y2qcVXJRNzU8XtFmp73oX2 wpFff9Ckq7qldts1LUbVSDl69hI1Yp9QeEkkguH9ie7lpiQsP1DEu940w0tBbAboGfh7 oGHqDEUieVHo5EVwVJtTB4Tg+if/Exuk2btOYNNHLIYCB8lGHkUQ7nsJ0T37nE0Ksk11 M69v5FLtcTNOkoYcJXhvTZ/cA2jkCtBxCLg+rcqi3hoTmQxl3BU56wcbdaA31B4w2YCf Jtzg==
X-Received: by 10.14.105.4 with SMTP id j4mr10340255eeg.41.1397025739237; Tue, 08 Apr 2014 23:42:19 -0700 (PDT)
Received: from netboy (089144223168.atnat0032.highway.bob.at. [89.144.223.168]) by mx.google.com with ESMTPSA id 48sm205500eee.2.2014.04.08.23.42.14 for <multiple recipients> (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 08 Apr 2014 23:42:18 -0700 (PDT)
Date: Wed, 09 Apr 2014 08:42:10 +0200
From: Richard Cochran <richardcochran@gmail.com>
To: "Dowd, Greg" <Greg.Dowd@microsemi.com>
Message-ID: <20140409064210.GA9631@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> <20140408200830.GA30453@netboy> <8D2BF679AAC7C346848A489074F9F8BF4E91C2@sjsrvexchmbx1.microsemi.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8D2BF679AAC7C346848A489074F9F8BF4E91C2@sjsrvexchmbx1.microsemi.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/cyB7_o0Q0rdQRUhTknthC7vI__s
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: Wed, 09 Apr 2014 06:42:22 -0000

On Tue, Apr 08, 2014 at 08:49:28PM +0000, Dowd, Greg wrote:

> It would be ideal for ptp servers to be stateless.  Default profile
> is fine for that.  But the overhead of the multicast delay
> request-response system is scales poorly.  So, the hybrid profile.

You can still implement 16.1 without using any state. Consider the
following options.

1. Requests for unicast Sync are always denied.
2. Requests for unicast Delay_Resp are always granted.
3. Incoming unicast Delay_Req messages receive a unicast response.

If the enterprise profile would recommend this, then you could have
the hybrid behavior using standard 1588 options.

In my opinion, profiles should ideally be a menu of 1588 options to be
used together. If it can be avoided, then profiles should not mandate
new behaviors.

It appears to me that the use case addressed in the enterprise profile
is already covered by 16.1 without needing anything more.

Thanks,
Richard

v2.23.0 | Report a Bug | By Email