Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt
Yaakov Stein <yaakov_s@rad.com> Tue, 12 March 2013 03:26 UTC
Return-Path: <yaakov_s@rad.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6E621F8884 for <tictoc@ietfa.amsl.com>; Mon, 11 Mar 2013 20:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.216
X-Spam-Level:
X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mig1lebQZBHq for <tictoc@ietfa.amsl.com>; Mon, 11 Mar 2013 20:26:20 -0700 (PDT)
Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id C18AB21F86E1 for <tictoc@ietf.org>; Mon, 11 Mar 2013 20:26:18 -0700 (PDT)
Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 12 Mar 2013 05:26:33 +0200
Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Tue, 12 Mar 2013 05:26:15 +0200
From: Yaakov Stein <yaakov_s@rad.com>
To: Shahram Davari <davari@broadcom.com>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt
Thread-Index: AQHOHruucQStouftOUWpQiXwkvwMiZihGqGAgABAcxA=
Date: Tue, 12 Mar 2013 03:26:15 +0000
Message-ID: <07F7D7DED63154409F13298786A2ADC904C98194@EXRAD5.ad.rad.co.il>
References: <20130223072233.32735.89371.idtracker@ietfa.amsl.com> <64683B4805156847B0ED373DAB3057CA015E930D@ottsrv0015.microsemi.net> <4A6CE49E6084B141B15C0713B8993F281BD9A385@SJEXCHMB12.corp.ad.broadcom.com>
In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BD9A385@SJEXCHMB12.corp.ad.broadcom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.232.33.112]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Commtouch-Refid: str=0001.0A090207.513EA058.00E6,ss=1,fgs=0
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Mar 2013 03:26:22 -0000
Shahram A few more comments. First, I don't like the terminology "both MPLS and MPLS-TP". MPLS-TP is MPLS too. And in any case "environments" (in the plural). "Extensions to signaling protocols (e.g., RSVP-TE) are required" well, you COULD set them up manually, in which case no extensions are required. Section 5 GAL/ACH -> GAL/G-Ach (and throughout the document you have various mis-spellings of G-Ach) In section 6.2 you require the Ethernet to be tagged, and in fact to be double tagged. Since we now have an offset from BoS to the TC, why is this required ? I realize that we want to limit the number of different encaps to be supported, but I believe this is too harsh a limitation. And why must the tagged mode of 4448 be used ? You can have tags and still use raw mode. Section 6.3 - If NTP or some new method is used, with which part of the packet is the timestamp associated ? Also "the control and signaling requirements in this document are defined ..." needs to be removed (they are NOT defined here any more). Section 7: technically a TC is not a timestamp, it is a time difference. Also updating the TC is not time-stamping either. I see that in Section 8 the recommendation regarding protection switching is SHOULD be used. As you know I don't agree, but let's see if the WG agrees to this in LC. Taking my view to the extreme, why outlaw ECMP in Section 9? I agree with ruling it out, but if you allow protection switching, then why not ECMP? Properly performed TC will remove the major portion of the delay differences. Section 11: entropy -> entropy label Perhaps sections 14 and 15 can be combined. I am not sure which way is better. If I remember the last meeting correctly, we asked for the signaling material to be mentioned in an Appendix. Here it is in Sections 16 and 17. I am not sure that this is terrible, but I don't think these belong in the body of a PS draft. Section 19 ware -> aware, it needs -> they need I am not sure we need the applicability statement. In the Acknowledgements: Luca Moniti -> Luca Martini Y(J)S -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Shahram Davari Sent: 12 March, 2013 02:59 To: Meyer, Peter; tictoc@ietf.org Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Peter, Good feedback. I will update the draft after the Orlando to include your comments. Thx Shahram -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Meyer, Peter Sent: Monday, March 11, 2013 5:49 PM To: tictoc@ietf.org Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Hi Shahram et al, Some comments on draft -04. 1) Section 3. "A generic method is defined in this document that does not require deep packet inspection at line rate, and can deterministically identify Timing messages. The generic method is applicable to MPLS and MPLS-TP networks." May want to add that this would apply only to one-step TC (I imagine that is the point of the correction at line rate). A two-step TC would need to do deep packet inspection as it uses sourcePortIdentity & sequenceId fields for Follow_up or Delay_Resp. 2) Section 4. "An MPLS domain can serve multiple customers. This means that the MPLS domain (maintained by a service provider) may provide timing services to multiple customers, each having their own Timing domain. Therefore LER BCs need to interact with multiple grandmasters, and consequently multiple time references." This should be re-phrased. It switches from an optional situation ("may provide timing services") to mandatory situation ("LER BCs need to interact"). Some words such as "in such a deployment scenario, ...." and replace "can" with "may". We have seen at ITU at least (with participation from operators BT, FT, DT, CMCC, AT&T, Sprint, etc.) that this multiple operator domain case was not useful enough to be included in standardization process for Telecom networks. 3) Section 19. "For transporting such peer delay measurement messages a single-hop LSP SHOULD to be created between the two adjacent LSRs engaged in peer delay measurement to carry peer delay measurement messages. Other methods such as PTP transport over Ethernet MAY be used for transporting peer delay measurement messages if the link between the two routers is Ethernet." This new statement to handle peer-delay (which in earlier drafts did not have a communication path listed), also allows a BC to be embedded in an LSR with a communication path between BC's as a single-hop LSP (mentioned March 22, 2012 in my feedback to draft -03, subject "[TICTOC] Updated 1588 over MPLS draf-03"). Architecture diagrams Figure 1 and Figure should be updated to reflect the possibility of either BC or TC implementation. Section 18.2 and section 18.3 and section 21 should also be updated to reflect the possibility of either BC or TC. I understand the RFC is intended to be generic and not targeted only at TC. 4) Section 20. "When the MPLS network (provider network) serves multiple customers, it is important to maintain and process each customers clock and Timing messages separately from other customers to ensure there is no cross- customer effect. For example if an LER BC is synchronized to a specific grandmaster, belonging to customer A, then the LER MUST use that BC clock only for customer A to ensure that customer A cannot attack other customers by manipulating its time." This seems much more applicable to the TC LSR and should be stated. >From section 4 we see the TC uses the primary synchronization domain (that of the service provide) to correct PTP messages. 5) Section 20. "Timing messages (as opposed to regular customer data) SHOULD not be encrypted or authenticated on an end-to-end basis." I think there is a security draft in parallel being developed that may be relevant to that statement. Regards, Peter -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: February 23, 2013 2:23 AM To: i-d-announce@ietf.org Cc: tictoc@ietf.org Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Timing over IP Connection and Transfer of Clock Working Group of the IETF. Title : Transporting Timing messages over MPLS Networks Author(s) : Shahram Davari Amit Oren Manav Bhatia Peter Roberts Laurent Montini Filename : draft-ietf-tictoc-1588overmpls-04.txt Pages : 36 Date : 2013-02-22 Abstract: This document defines the method for transporting Timing messages such as PTP and NTP over an MPLS network. The method allows for the easy identification of these PDUs at the port level to allow for port level processing of these PDUs in both LERs and LSRs. The basic idea is to transport Timing messages inside dedicated MPLS LSPs. These LSPs only carry timing messages and possibly Control and Management packets, but they do not carry customer traffic. Two methods for transporting Timing messages over MPLS are defined. The first method is to transport Timing messages directly over the dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for MPLS networks. The second method is to transport Timing messages inside a PW via Ethernet encapsulation, which is suitable for both MPLS and MPLS-TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588overmpls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588overmpls-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc
- [TICTOC] I-D Action: draft-ietf-tictoc-1588overmp… internet-drafts
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Meyer, Peter
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Yaakov Stein
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Meyer, Peter
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Stefano Ruffini
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Meyer, Peter
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Meyer, Peter
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Meyer, Peter
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Lars Ellegaard
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Meyer, Peter
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Meyer, Peter
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Stefano Ruffini
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Stefano Ruffini
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Shahram Davari
- Re: [TICTOC] comments on draft-ietf-tictoc-1588ov… Lars Ellegaard