Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt
"Shahram Davari" <davari@broadcom.com> Wed, 05 June 2013 23:32 UTC
Return-Path: <davari@broadcom.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 BB05C11E80E1 for <tictoc@ietfa.amsl.com>; Wed, 5 Jun 2013 16:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 vcfFnJlDy62B for <tictoc@ietfa.amsl.com>; Wed, 5 Jun 2013 16:32:52 -0700 (PDT)
Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id A7CFF21F8A68 for <tictoc@ietf.org>; Wed, 5 Jun 2013 16:32:52 -0700 (PDT)
Received: from [10.9.208.53] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 05 Jun 2013 16:26:35 -0700
X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2
Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 5 Jun 2013 16:32:13 -0700
Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Wed, 5 Jun 2013 16:32:13 -0700
From: Shahram Davari <davari@broadcom.com>
To: "Meyer, Peter" <Peter.Meyer@microsemi.com>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt
Thread-Index: AQHOHrvIG9Qp4DAEq0WS7lIAjM8M8JkmuDRwgAE3KqCAADsOgIAABF6wgAAHahCAAAEIcIAAAdVwgAAFM5CAAAX/MIAABGhAgAADjKA=
Date: Wed, 05 Jun 2013 23:32:13 +0000
Message-ID: <4A6CE49E6084B141B15C0713B8993F281BE2FFE4@SJEXCHMB12.corp.ad.broadcom.com>
References: <20130223072233.32735.89371.idtracker@ietfa.amsl.com> <64683B4805156847B0ED373DAB3057CA015E930D@ottsrv0015.microsemi.net> <4A6CE49E6084B141B15C0713B8993F281BE28013@SJEXCHMB12.corp.ad.broadcom.com> <64683B4805156847B0ED373DAB3057CA01B19D5F@ottsrv0015.microsemi.net> <4A6CE49E6084B141B15C0713B8993F281BE2FD85@SJEXCHMB12.corp.ad.broadcom.com> <64683B4805156847B0ED373DAB3057CA01B19E70@ottsrv0015.microsemi.net> <4A6CE49E6084B141B15C0713B8993F281BE2FE6E@SJEXCHMB12.corp.ad.broadcom.com> <64683B4805156847B0ED373DAB3057CA01B19E80@ottsrv0015.microsemi.net> <4A6CE49E6084B141B15C0713B8993F281BE2FED7@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BE2FF54@SJEXCHMB12.corp.ad.broadcom.com> <64683B4805156847B0ED373DAB3057CA01B19E97@ottsrv0015.microsemi.net>
In-Reply-To: <64683B4805156847B0ED373DAB3057CA01B19E97@ottsrv0015.microsemi.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.16.203.100]
MIME-Version: 1.0
X-WSS-ID: 7DB116A11R026921994-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: Wed, 05 Jun 2013 23:32:58 -0000
How about rephrasing it as following: " A generic method is defined in this document that does not require deep packet inspection at line rate, and can deterministically identify Timing messages. This method is specifically beneficial for 1-step Transparent Clocking operation described in [IEEE-1588], while it also supports 2-Step Transparent Clocking." Thx SD -----Original Message----- From: Meyer, Peter [mailto:Peter.Meyer@microsemi.com] Sent: Wednesday, June 05, 2013 4:22 PM To: Shahram Davari; tictoc@ietf.org Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Hi Shahram, I think you are referring to 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, for one-step mode of operation. The generic method is applicable to MPLS and MPLS-TP networks." I was not intending to indicate two-step would not work. I was intending to highlight the important benefit of this document is specifically to enable one-step capability more easily. Without this specification one-step is more difficult due to the need for deep packet inspection. Two-step would probably not benefit as much as a result of this specification. If I have not worded correctly, it can be removed/changed back to original. Regards, Peter -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: June 5, 2013 7:04 PM To: Shahram Davari; Meyer, Peter; tictoc@ietf.org Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Peter, Could you please also explain why the 2 step won't work with the method in this draft. Thx Shahram -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Wednesday, June 05, 2013 3:43 PM To: Meyer, Peter; tictoc@ietf.org Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Hi Peter, Thanks, now I get it. I will update the draft as per your suggestion. Thx Shahram -----Original Message----- From: Meyer, Peter [mailto:Peter.Meyer@microsemi.com] Sent: Wednesday, June 05, 2013 3:35 PM To: Shahram Davari; tictoc@ietf.org Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Hi Shahram, I attempted to elaborate in section 19 Other Considerations, perhaps it is not well written. I tried to mirror the language that already existed. With the original -04 draft, section 19 covered the situation for an LSR acting as a TC when using peer-delay messages. An LSR would have to generate & terminate peer-delay messages from its physical neighbour, and the recommendation was to use a single-hop LSP. With your terminology, if I am using it correctly, the Sync messages are switched through the LSR without termination. However, this is not allowed for peer-delay messages which must be terminated for the TC to function properly. " 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. " I use this same approach for an LSR acting as a BC. A BC inside an LSR is the same as a peer-delay TC inside an LSR. The LSR would have to generate & terminate end-to-end messages from its physical neighbour. I modified the section to recommend a single-hop LSP for this purpose. " Likewise for BCs embedded in an LSR, a single-hop LSP SHOULD be created between the two adjacent LSRs that are acting as BCs. Other methods such as PTP transport over Ethernet MAY be used if the link between the two routers is Ethernet. " Hope this makes sense. Regards, Peter -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: June 5, 2013 6:18 PM To: Meyer, Peter; tictoc@ietf.org Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Peter, I think we have a difference in terminology. To me an LSR is a router that does Label Swap and not Label pop. May be what you have in mind is PE and P routers instead of LER and LSR. Thx Shahram -----Original Message----- From: Shahram Davari Sent: Wednesday, June 05, 2013 3:16 PM To: 'Meyer, Peter'; tictoc@ietf.org Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Hi Peter, I see that the majority of changes are related to LSR BC. I personally don't think this is possible, since we can't terminate packets in the middle of an LSP. Could you please provide an example for your suggestion of using LSR BC? How are the 1588 timing messages terminated? Thanks Shahram -----Original Message----- From: Meyer, Peter [mailto:Peter.Meyer@microsemi.com] Sent: Wednesday, June 05, 2013 2:48 PM To: Shahram Davari; tictoc@ietf.org Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Hi Shahram, I took the -04 that was advertised on the exploder in February (dated February 23, 2013). I then edited that copy. (I think the diff may show a ton of changes due to line length or word wrapping). Regards, Peter -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: June 5, 2013 5:32 PM To: Meyer, Peter; tictoc@ietf.org Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Thanks Peter. These edits where done before the publishing of draft-04. Correct? -Shahram -----Original Message----- From: Meyer, Peter [mailto:Peter.Meyer@microsemi.com] Sent: Wednesday, June 05, 2013 11:01 AM To: Shahram Davari; tictoc@ietf.org Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Hi Shahram, I hope in-line with my comments I have edited the text of draft -04. I'm not sure how the formatting worked out (PC-based, line length, page length). I modified sections 3, 4, 18, 19 & 20. I include here both original and modified version so you can diff (most of the changes in 3 are due to line length / re-org, not actual text changes). File attachment: "draft-ietf-tictoc-1588overmpls-04-org.txt" (52 KB) "draft-ietf-tictoc-1588overmpls-04-pm.txt" (53 KB) Regards, Peter -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: June 4, 2013 7:40 PM To: Meyer, Peter; tictoc@ietf.org Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt Hi Peter, Thanks for your god comments. Please see my responses inline. Please let me know whether you are satisfied with my responses since I am updating the draft in the next couple of days. Thanks 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. SD> For 2-step, all that is needed is for an interface to detect the Timing message (based on top MPLS Label) and record the Time along with some information from the Timing packet and send them to CPU while forwarding the Timing message as usual. Then the CPU based on the information received generates Follow-up message and injects it in to the LSP. Therefore it is the job of CPU to look at sourcePortIdentity & sequenceId fields not the Hardware. 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. SD> I rephrased it as following: " 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 in such deployment scenarios, LER BCs may interact with multiple grandmasters, and consequently multiple time references. Also, LER/LSR TCs MUST be synchronized to the same master clock (which is the service provider Master clock), which implies that they need to choose one master to synchronize to." 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"). SD> When a single-hop LSP is created then I call the both ends of that LSP, LERs and not LSRs. Note that a router can act as LSR for some LSPs and LER for other LSPs. The point is that we can't Terminate a packet in the middle of an LSP (i.e., in an LSR). So BC functionality can't exist in the middle Of a PTP LSP. So I think it is a matter of terminology otherwise I agree that you could have BC in the core (not edge). 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. SD> I don't see how in a TC LSR, one customer timing can affect other customer timings? Since in a TC, we just update the Timestamp of a packet based on the Service provider Time. May be I have not understood your point. Could you please clarify with an example. 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. SD> I have updated the text as following: " Timing messages MAY be encrypted or authenticated, provided that the LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the timing messages." 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