Re: [TICTOC] Enterprise Profile

"Laurent Montini (lmontini)" <lmontini@cisco.com> Sun, 26 October 2014 11:09 UTC

Return-Path: <lmontini@cisco.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 8F4D11A7D81 for <tictoc@ietfa.amsl.com>; Sun, 26 Oct 2014 04:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 JJpO5w9SLY9W for <tictoc@ietfa.amsl.com>; Sun, 26 Oct 2014 04:09:03 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0056A1A70FF for <tictoc@ietf.org>; Sun, 26 Oct 2014 04:09:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13658; q=dns/txt; s=iport; t=1414321742; x=1415531342; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=y8KTPmP8G8R3vw3VpqA+dPhJUiLzR+dU8pFFlQ1qvsk=; b=ksiQy42BPlSHbBuwdP5QTCHwilGmwFA+7Nr9CUXbIZPxPezD3T8GmJeI yjUZxEQiJMYudDC0N9TDX6LR/RdPU6McSF/Bxq6+CXul6PDGf/pDPhS83 Y3heVlWvsmqU4Kd4C4dTTxiks+1TumEfHgYXeHXxf2TcnoumRZDVwQBUz A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAPTUTFStJA2G/2dsb2JhbABZA4JIRoEsBNQ9AoEEFgF9hAIBAQEEeRACAQgOAwMBAigHMhQJCAIEDgWIQcdcAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BdGgEQBwYLhDoFj1QVgh6LWoExh0mGFYcfg3hsgUiBAwEBAQ
X-IronPort-AV: E=Sophos; i="5.04,790,1406592000"; d="scan'208,217"; a="90422494"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 26 Oct 2014 11:09:02 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9QB926l022160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Oct 2014 11:09:02 GMT
Received: from xmb-rcd-x11.cisco.com ([169.254.1.113]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 06:09:01 -0500
From: "Laurent Montini (lmontini)" <lmontini@cisco.com>
To: Douglas Arnold <doug.arnold@meinberg-usa.com>
Thread-Topic: Enterprise Profile
Thread-Index: AQHP5vfZmWn5KUphaUOE6sVgbNiqpJw+xbaAgAPap4A=
Date: Sun, 26 Oct 2014 11:09:01 +0000
Message-ID: <D0728DCE.A79B7%lmontini@cisco.com>
References: <D061B80C.A3DED%lmontini@cisco.com> <CACQYgzEW6DCezmgwoZGQ-grC0SyB_r5svDUWWSSmY8KCzZJwYg@mail.gmail.com>
In-Reply-To: <CACQYgzEW6DCezmgwoZGQ-grC0SyB_r5svDUWWSSmY8KCzZJwYg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.55.225.227]
Content-Type: multipart/alternative; boundary="_000_D0728DCEA79B7lmontiniciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/uWdehQ43zmnQZLUbG01mBDtCMiU
Cc: "tictoc@ietf.org" <tictoc@ietf.org>
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: Sun, 26 Oct 2014 11:09:06 -0000

Hi Doug,

Thanks for the clarifications.

1)    When Preferred Master Clocks are not the Best Master in one domain,
   they SHOULD operate as a master in another domain.

Any reason why this is not a MAY?

2) I find the draft still confusing wrt Unicast Negotiation.
>From Clauses 7 and 13, I understand the negotiation shall not be used for negotiating message rate.
But I don’t find a text mentioning this option is allowed for other matters such as to set the unicast delay mechanism communication path?
Looks implicit except that clause 14 mentions "the Enterprise Profile forbids Unicast Message Negotiation”.

If Unicast Message Negotiation is totally forbidden, why not telling so in clause 13 only and not limiting the restriction to message rate?
If Unicast Message Negotiation is not totally forbidden i.e. can be used optionally with restriction already listed, I believe this shall be explicit.

3) Wrt interoperability, why G.8275.1 and 802.1AS are not referenced as not interoperable due to pdelay mechanism and/or Ethernet mapping (as for C37.238 -and IEC 62439-3).
Any reason?

Thanks,
Laurent

From: Doug Arnold <doug.arnold@meinberg-usa.com<mailto:doug.arnold@meinberg-usa.com>>
Date: Friday 24 October 2014 02:17
To: lmontini <lmontini@cisco.com<mailto:lmontini@cisco.com>>
Cc: "Heiko.gerstung@meinberg.de<mailto:Heiko.gerstung@meinberg.de>" <Heiko.gerstung@meinberg.de<mailto:Heiko.gerstung@meinberg.de>>, "tictoc@ietf.org<mailto:tictoc@ietf.org>" <tictoc@ietf.org<mailto:tictoc@ietf.org>>
Subject: Re: Enterprise Profile

Hello Laurent,

Thank you for the feedback on the Enterprise Profile.  I have made the following changes in the draft [see inline comments below].  An update will be posted shortly.

On Mon, Oct 13, 2014 at 8:10 AM, Laurent Montini (lmontini) <lmontini@cisco.com<mailto:lmontini@cisco.com>> wrote:
Hi,

I have 3 comments:

1) Clause 8, first paragraph: is the sentence correct?
“When Preferred Master Clocks are not the Best Master in one domain, they SHOULD operate in another domain when they. “
Seems something missing.

   Text now reads:
   When Preferred Master Clocks are not the Best Master in one domain,
   they SHOULD operate as a master in another domain.

   Further explanation of multi-domain operation is added as well.

2) Unicast Discovery
Clause 12: Forbidden options: “Slave clocks operating in the Enterprise Profile SHALL NOT use Unicast Discovery to establish connection to Master clocks.”
Clause 13, 3rd paragraph:
“Clocks operating in the Enterprise profile will not interoperate with clocks operating in the Telecom Profile for Frequency Synchronization[G8265.1], because the Enterprise Profile forbids Unicast Message Negotiation, and Unicast Discovery.”
As neither Enterprise nor this Telecom profile use Unicast Discovery, how does it make this oiption an interoperability issue?

    Reference of Unicast Discovery has been removed from this passage.

3) Clause 13, paragraph before last, last sentence: “the Default Profile is…” : there are two default profiles in IEEE 1588-2008, in Annexes J.3 and J.4, one using the delay mechanism the other the pdelay mechanism.

  *   Obviously the Enterprise profile will not interop with J.4.
  *   Should the text be “The Default Profiles are described in Annexes J.3 and J.4.”

   This clause has been rewritten to discuss J.3 and J.4 cases separately.

Regards,
Laurent




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