IETF Logo Mail Archive

Re: [TICTOC] Enterprise profile update

"Dowd, Greg" <Greg.Dowd@microsemi.com> Wed, 09 April 2014 15:39 UTC

Return-Path: <Greg.Dowd@microsemi.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 5B4561A0293 for <tictoc@ietfa.amsl.com>; Wed, 9 Apr 2014 08:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 V3LZaVzXJ8uE for <tictoc@ietfa.amsl.com>; Wed, 9 Apr 2014 08:39:18 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 99BAC1A0330 for <tictoc@ietf.org>; Wed, 9 Apr 2014 08:39:18 -0700 (PDT)
Received: from BLUPR02CA040.namprd02.prod.outlook.com (25.160.23.158) by BLUPR02MB488.namprd02.prod.outlook.com (10.141.82.22) with Microsoft SMTP Server (TLS) id 15.0.908.10; Wed, 9 Apr 2014 15:39:17 +0000
Received: from BN1BFFO11FD003.protection.gbl (2a01:111:f400:7c10::1:168) by BLUPR02CA040.outlook.office365.com (2a01:111:e400:8ad::30) with Microsoft SMTP Server (TLS) id 15.0.918.8 via Frontend Transport; Wed, 9 Apr 2014 15:39:17 +0000
Received: from avsrvexchhts1.microsemi.net (208.19.100.21) by BN1BFFO11FD003.mail.protection.outlook.com (10.58.144.66) with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Wed, 9 Apr 2014 15:39:16 +0000
Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by avsrvexchhts1.microsemi.net (10.100.34.105) with Microsoft SMTP Server (TLS) id 14.2.347.0; Wed, 9 Apr 2014 08:39:15 -0700
Received: from SJSRVEXCHMBX1.microsemi.net ([fe80::19b5:ac43:d8de:5120]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.02.0347.000; Wed, 9 Apr 2014 08:39:01 -0700
From: "Dowd, Greg" <Greg.Dowd@microsemi.com>
To: Richard Cochran <richardcochran@gmail.com>
Thread-Topic: [TICTOC] Enterprise profile update
Thread-Index: AQHPPi1eBr8WMCicuUq6V+2F/hm7i5sDex6AgAAmVwCAAqSSgIACAoOAgAAOSACAABSIgIAASegAgAAQWgD//5LmkIABHiYAgAAfZ1A=
Date: Wed, 09 Apr 2014 15:39:00 +0000
Message-ID: <8D2BF679AAC7C346848A489074F9F8BF4E9514@sjsrvexchmbx1.microsemi.net>
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> <20140409064210.GA9631@netboy>
In-Reply-To: <20140409064210.GA9631@netboy>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.160.250]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:208.19.100.21; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019001)(6009001)(428001)(13464003)(377454003)(189002)(199002)(24454002)(164054003)(99396002)(85852003)(83072002)(97736001)(2009001)(87266001)(79102001)(94946001)(53416003)(85306002)(74502001)(81342001)(74706001)(20776003)(74876001)(74662001)(4396001)(98676001)(92566001)(44976005)(95666003)(47446003)(56776002)(47776003)(54356002)(47736002)(54316003)(47976003)(76482001)(50466002)(1411001)(76786001)(46406003)(81686001)(90146001)(92726001)(2656002)(76796001)(81816001)(80976001)(19580395003)(94316002)(83322001)(87936001)(6806004)(97336001)(93516002)(97756001)(49866001)(95416001)(84676001)(80022001)(86362001)(31966008)(77982001)(69226001)(74366001)(81542001)(23726002)(93136001)(46102001)(16796002)(77096001)(50986002)(53806002)(19580405001)(55846006)(56816006)(63696004)(33656001)(59766002)(97186001)(65816002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR02MB488; H:avsrvexchhts1.microsemi.net; FPR:FC2CF211.9CD25CC1.39F5B570.4EF1C9C1.202FB; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Forefront-PRVS: 01762B0D64
Received-SPF: None (: microsemi.com does not designate permitted sender hosts)
X-OriginatorOrg: microsemi.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/KLeXRV9Hf7peWkiGgJjMPUFmBSw
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 15:39:23 -0000

How would that be using 16.1?  It provides no utility and just wastes bandwidth.  What would we achieve by doing this?  It is an optional element to the protocol so I don't understand the necessity.  I agree trying to work within the bounds of the protocol as defined is a good goal but if you read the protocol specification, profiles were indeed meant for exactly this purpose.  A subset of functions defined by the protocol agreed upon for a particular application, interoperable amongst a set of members.

-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com] 
Sent: Tuesday, April 08, 2014 11:42 PM
To: Dowd, Greg
Cc: Kevin Gross; tictoc@ietf.org
Subject: Re: [TICTOC] Enterprise profile update

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