Go Yaakov Thanks for your comments. I will incorporate them in next version and will send you for review before publishing so we can go for last call in draft-05
Regards, Shahram On Mar 11, 2013, at 8:26 PM, "Yaakov Stein" <[email protected]> wrote: > 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: [email protected] [mailto:[email protected]] On Behalf Of > Shahram Davari > Sent: 12 March, 2013 02:59 > To: Meyer, Peter; [email protected] > 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: [email protected] [mailto:[email protected]] On Behalf Of > Meyer, Peter > Sent: Monday, March 11, 2013 5:49 PM > To: [email protected] > 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: [email protected] [mailto:[email protected]] On Behalf > Of [email protected] > Sent: February 23, 2013 2:23 AM > To: [email protected] > Cc: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
