Re: [TICTOC] Enterprise Profile

Tim Frost <tim.frost@calnexsol.com> Fri, 04 July 2014 13:25 UTC

Return-Path: <tim.frost@calnexsol.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 DE7531B28D6 for <tictoc@ietfa.amsl.com>; Fri, 4 Jul 2014 06:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 61Y9yVAiVMLK for <tictoc@ietfa.amsl.com>; Fri, 4 Jul 2014 06:25:12 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0010.outbound.protection.outlook.com [213.199.154.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC071B27F3 for <tictoc@ietf.org>; Fri, 4 Jul 2014 06:25:11 -0700 (PDT)
Received: from AMXPR05MB102.eurprd05.prod.outlook.com (10.242.70.16) by AMXPR05MB104.eurprd05.prod.outlook.com (10.242.70.28) with Microsoft SMTP Server (TLS) id 15.0.974.11; Fri, 4 Jul 2014 13:25:08 +0000
Received: from AMXPR05MB102.eurprd05.prod.outlook.com ([169.254.13.206]) by AMXPR05MB102.eurprd05.prod.outlook.com ([169.254.13.206]) with mapi id 15.00.0974.002; Fri, 4 Jul 2014 13:25:08 +0000
From: Tim Frost <tim.frost@calnexsol.com>
To: Douglas Arnold <doug.arnold@meinberg-usa.com>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: [TICTOC] Enterprise Profile
Thread-Index: AQHPlnBK6y7T6yum+06AHaRXzS9T+JuP5MmA
Date: Fri, 04 Jul 2014 13:25:08 +0000
Message-ID: <61b82b3e70874d868d42a6810eaf57e2@AMXPR05MB102.eurprd05.prod.outlook.com>
References: <CACQYgzGvM880STROQ28MNTSJ_JGiBKC5J+n9JGKZr0HLPsVvag@mail.gmail.com>
In-Reply-To: <CACQYgzGvM880STROQ28MNTSJ_JGiBKC5J+n9JGKZr0HLPsVvag@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [80.47.123.127]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02622CEF0A
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(57704003)(53754006)(76482001)(21056001)(15202345003)(92566001)(83322001)(81542001)(86362001)(81342001)(46102001)(80022001)(99396002)(66066001)(106356001)(105586002)(4396001)(106116001)(107886001)(95666004)(79102001)(33646001)(101416001)(74662001)(19625215002)(74502001)(74316001)(19580395003)(19580405001)(77096002)(85306003)(76176999)(76576001)(54356999)(31966008)(50986999)(83072002)(85852003)(16236675004)(64706001)(19300405004)(15975445006)(2656002)(87936001)(20776003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR05MB104; H:AMXPR05MB102.eurprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_61b82b3e70874d868d42a6810eaf57e2AMXPR05MB102eurprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: calnexsol.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/S24Qkv14edxpxDhVxI2j9kZ5zeA
Subject: Re: [TICTOC] Enterprise Profile
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: Fri, 04 Jul 2014 13:25:15 -0000

Hi Doug,

Sorry, I hadn’t read the previous versions, so I hadn’t commented before.

The one big technical comment I have is on security and multiple domains.  You talk about slave clocks being capable of synchronizing to (and by implication ensembling information from) multiple masters in multiple domains.  This has to be outside of the IEEE1588 protocol, since what happens in one domain shouldn’t influence what happens on another.  I accept G.8265.1  has set a precedence for this type of “outside of IEEE1588” behaviour, but at least that makes clear what the rules and expected behavior are.  This is a little vague on what you are allowed to do; that may be intentional to not narrow down implementations or prevent innovation, but it doesn’t make for easy interoperability.

In clause 14 you present this as the main plank of your security strategy, but don’t really make it clear how it should work. I think some elaboration here is required.

Some other minor comments:

-          There is none of the expected “boiler plate” for a profile, i.e. profileName, profileIdentifier, profileVersion etc.

-          In clause 6, you don’t mention if Follow-up messages are multicast or unicast (I assume it should be multicast, but it doesn’t say)

-          In clause 8, you should elaborate on what a “preferred master” is and why it is different from other masters

-          In clause 8, paragraph 1, sentence 3 stops abruptly: “…they SHOULD operate in another domain when they.” What’s missing?

-          In clause 8, what is the main purpose and expected use of the TLV? What should subsequent clocks do with it and why do they need to receive it?

Best regards,
Tim


Tim Frost   |   Calnex Solutions Ltd.   |   +44 (0) 7825 706 952   |   www.calnexsol.com<http://www.calnexsol.com/>

From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Douglas Arnold
Sent: 03 July 2014 04:39
To: tictoc@ietf.org
Subject: [TICTOC] Enterprise Profile

Hello Everyone,

I have posted a new version (v03) of the PTP Enterprise Profile.  The only difference since the last time is to change the location of the port address in the announce TLV.  The purpose of this is to bring the TLV structure into alignment with the IEEE C37.238 (Power Profile) revision which has gone to ballot with the IEEE.  That would make two profiles with the same general announce TLV structure, which hopefully starts a trend.

Aside from this minor cosmetic change the document has been stable since the February version.  All comments have been addressed one way or another, so I hope to see this go to last call.

--
Doug Arnold
Principal Technologist
JTime! Meinberg USA
+1-707-303-5559