Re: [TICTOC] Enterprise profile update

"Dowd, Greg" <Greg.Dowd@microsemi.com> Tue, 08 April 2014 20:49 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 F1F4D1A074C for <tictoc@ietfa.amsl.com>; Tue, 8 Apr 2014 13:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 lbxsL_9QlJZt for <tictoc@ietfa.amsl.com>; Tue, 8 Apr 2014 13:49:50 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1DD1A0742 for <tictoc@ietf.org>; Tue, 8 Apr 2014 13:49:46 -0700 (PDT)
Received: from BY2PR02CA001.namprd02.prod.outlook.com (10.255.247.21) by BY2PR02MB491.namprd02.prod.outlook.com (10.141.145.17) with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 20:49:44 +0000
Received: from BN1BFFO11FD001.protection.gbl (2a01:111:f400:7c10::1:165) by BY2PR02CA001.outlook.office365.com (2a01:111:e400:2c16::21) with Microsoft SMTP Server (TLS) id 15.0.908.10 via Frontend Transport; Tue, 8 Apr 2014 20:49:43 +0000
Received: from avsrvexchhts2.microsemi.net (208.19.100.22) by BN1BFFO11FD001.mail.protection.outlook.com (10.58.144.64) with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Tue, 8 Apr 2014 20:49:43 +0000
Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by avsrvexchhts2.microsemi.net (10.100.34.106) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 8 Apr 2014 13:49:42 -0700
Received: from SJSRVEXCHMBX1.microsemi.net ([fe80::19b5:ac43:d8de:5120]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.02.0347.000; Tue, 8 Apr 2014 13:49:29 -0700
From: "Dowd, Greg" <Greg.Dowd@microsemi.com>
To: Richard Cochran <richardcochran@gmail.com>, Kevin Gross <kevin.gross@avanw.com>
Thread-Topic: [TICTOC] Enterprise profile update
Thread-Index: AQHPPi1eBr8WMCicuUq6V+2F/hm7i5sDex6AgAAmVwCAAqSSgIACAoOAgAAOSACAABSIgIAASegAgAAQWgD//5LmkA==
Date: Tue, 08 Apr 2014 20:49:28 +0000
Message-ID: <8D2BF679AAC7C346848A489074F9F8BF4E91C2@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>
In-Reply-To: <20140408200830.GA30453@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.22; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(51704005)(24454002)(164054003)(377454003)(13464003)(20776003)(76482001)(94946001)(47776003)(93516002)(77982001)(86362001)(94316002)(93136001)(55846006)(2656002)(19580395003)(97756001)(2009001)(80022001)(95666003)(98676001)(19580405001)(74662001)(92726001)(23726002)(16796002)(74502001)(50986002)(31966008)(63696004)(65816002)(56816006)(4396001)(59766002)(46102001)(53806002)(92566001)(79102001)(76786001)(95416001)(53416003)(69226001)(49866001)(76796001)(83072002)(80976001)(85852003)(81542001)(81686001)(81342001)(81816001)(33656001)(74876001)(85306002)(90146001)(84676001)(46406003)(15975445006)(83322001)(99396002)(6806004)(44976005)(77096001)(97186001)(97336001)(97736001)(74366001)(87936001)(74706001)(50466002)(47446003)(87266001)(54356002)(47736002)(56776002)(54316003)(47976003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR02MB491; H:avsrvexchhts2.microsemi.net; FPR:BE84F55E.A4C2DFD2.71F7BF77.40E9D162.20447; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Forefront-PRVS: 017589626D
Received-SPF: None (: microsemi.com does not designate permitted sender hosts)
X-OriginatorOrg: microsemi.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/o8WSUcO_Vjha2GalkcniC0BOQb8
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:49:55 -0000

I don't think unicast negotiation will go away.  16.1 works quite well for managed networks.  An original premise here was that we were trying to move to support an "Internet" profile.  From that perspective, the ntp protocol has had the same requirements and handled them pretty well, although we all debate certain aspects.  One big problem is scaleability.  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.  This allows the slaves to be bootstrapped without configuration.  They register the listen, similar to ntp multicast, they discover ptp service stream and then act appropriately.  They could just jam the offset occasionally, they could have a short "ranging" session for path delay (again, like ntp multicast) or they could mobilize an association and perform ranging functions at a rate similar to the server transmission rate.  One other note about having a profile is to correct a profile nit which I see almost as a bug.  Currently, the default profiles mandates that event messages originate from 319 while data messages can originate from any source port.  This limitation provides little value in my opinion and breaks NAT.  Obviously, a non-PTP aware gateway device doing NAT opens a whole other can of worms but protocol, or data flow, is one layer of operation and performance is another.




-----Original Message-----
From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Richard Cochran
Sent: Tuesday, April 08, 2014 1:09 PM
To: Kevin Gross
Cc: tictoc@ietf.org
Subject: Re: [TICTOC] Enterprise profile update

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

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc