Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

["Shahram Davari" <[e-mail]>]

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" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Shahram Davari
> Sent: 12 March, 2013 02:59
> To: Meyer, Peter; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Meyer, Peter
> Sent: Monday, March 11, 2013 5:49 PM
> To: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of [e-mail]
> Sent: February 23, 2013 2:23 AM
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc
> 
> 
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc
> 
> 
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc
>