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

["Meyer, Peter" <[e-mail]>]

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:[e-mail]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [e-mail]
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: [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.

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: [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