Subject: [TICTOC] draft minutes of TICTOC WebEx conference

From: Yaakov Stein <[email-masked]>
Date: Fri, 24 Sep 2010 11:18:28 +0200

Hi all,

Below are draft minutes of the conference call.
I don't have the complete list of participants since

1)    at least one person called in and thus was listed without a name,

2)    I wrote the notes from memory a day later.
Please fill me in if you were there and I left you out.

I also missed a few minutes of the conference. If I missed anything critical I would appreciate someone filling me in.
Other corrections and comments welcomed as well.

Y(J)S

On Monday, 20 Sept 2010, a TICTOC WebEx conference took place.
The call started 45 minutes late due to problems in getting the WebEx system up
(thanks to Alexa for help in getting the system to work). Several people did not manage to get into the conference.

Participants :
Karen, Yaakov, Stewart, Luca, Antti, Stefano, Michael, Michel, Laurent, Gaby, <can anyone I missed send me a note?>

1)    The first question (raised by Antti) that was raised was whether we are talking about

frequency or time (uncalibrated or calibrated) distribution.

Most of those on the call felt that frequency is handled well enough today, and that we should be focusing on time.

This feeling was reinforced by three facts :

a)    one of the main problems in networking is how to ensure symmetry, and this is irrelevant to frequency distribution

b)    highly precise frequency distribution is probably going to be carried out at the physical layer (e.g., SyncE)

c)     moderately precise frequency distribution is handled today using packet methods without MPLS-layer intervention

2)    The second question (raised by Luca) was whether we are talking about a network or an over-the-top service.

After discussion, it was agreed by all participants that we should initially focus on a network service.

The main reasoning was :

a)    user time distribution packets can be quite complex to recognize, e.g., UDP/IP in Ethernet in a PW in MPLS,

or 1588 over Ethernet over EoS over a CEP PW over MPLS, etc.

b)    if the network operator can provide an inexpensive time delivery service,

it could potentially change the modus operandi of those who presently use their own time systems

c)     a certain trust level is required by the customer for the network operator,

so the enhancement of the trust to full proventication is not a major step (although it will require protocol development)

3)    The third issue (raised by Antti) was whether an MPLS encapsulation is needed at all.

If the problem is solved or going to be solved at all the server layers of MPLS (Ethernet, OTN, SDH),

and in general lower layers are better at time delivery than higher ones,

then it does not make sense to re-solve the problem at the MPLS layer.

There was discussion as to what happens when the MPLS end-to-end path is supported by a concatenation

of several disparate transport technologies, but since one of the trends is hop-by-hop clock stabilization,

this problem may be automatically solved by the developing architecture.

We did not reach full agreement on this point. Stewart warned that the service provider may not have access

or even know what the underlying layer is, and warned participants not to focus solely on the mobile backhauling problem.

4)    Yaakov started discussion of the encapsulation options, but there was not enough time to present the topic.

5)    The chairs proposed to hold a conference call every third Tuesday of the month at 8 AM Pacific time

(which corresponds to 11 AM East Coast time, 4 PM UK, and usually 6 PM Israel time).

This proposal will be made on the list.

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 24 Sep 2010 11:24:09 +0200

With WG chair hat off, I don't agree with the statement

d)    a certain trust level is required by the customer for the network operator,
             so the enhancement of the trust to full proventication is not a major step (although it will require protocol development)

There is a huge gap between believing that a service provider prioritorizes timing traffic or provides TC,
and trusting that SP to block malicious timing traffic or MiM attacks.

Regarding the question as to whether we need an MPLS encap at all,
I think we should hear from SPs.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Friday, September 24, 2010 11:18
To: [email-masked]
Subject: [TICTOC] draft minutes of TICTOC WebEx conference

Hi all,

Y(J)S

Participants :

The main reasoning was :

Y(J)S

---

From: Michel Ouellette <[email-masked]>
Date: Fri, 24 Sep 2010 11:47:05 -0400

Yaakov,

-          There was another general discussion in item#3 about the fact
that there might not be any IP awareness in the data path, and as such a
PTPoMPLS mapping and detection might be required

-          There was another item raised on the "network service"
discussion: the techniques to do so must be identified as well as
requirements and constraints

Bye.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: September 24, 2010 05:18 AM
To: [email-masked]
Subject: [TICTOC] draft minutes of TICTOC WebEx conference

Hi all, 

I also missed a few minutes of the conference. If I missed anything critical
I would appreciate someone filling me in.

Y(J)S

The call started 45 minutes late due to problems in getting the WebEx system
up

(thanks to Alexa for help in getting the system to work). Several people did
not manage to get into the conference.

Participants :

Karen, Yaakov, Stewart, Luca, Antti, Stefano, Michael, Michel, Laurent,
Gaby, <can anyone I missed send me a note?>

1)      The first question (raised by Antti) that was raised was whether we
are talking about 

Most of those on the call felt that frequency is handled well enough today,
and that we should be focusing on time.

a)      one of the main problems in networking is how to ensure symmetry,
and this is irrelevant to frequency distribution

b)      highly precise frequency distribution is probably going to be
carried out at the physical layer (e.g., SyncE)

c)       moderately precise frequency distribution is handled today using
packet methods without MPLS-layer intervention

2)      The second question (raised by Luca) was whether we are talking
about a network or an over-the-top service.

After discussion, it was agreed by all participants that we should initially
focus on a network service.

The main reasoning was :

a)      user time distribution packets can be quite complex to recognize,
e.g., UDP/IP in Ethernet in a PW in MPLS,

b)      if the network operator can provide an inexpensive time delivery
service, 

it could potentially change the modus operandi of those who presently use
their own time systems

c)       a certain trust level is required by the customer for the network
operator,

so the enhancement of the trust to full proventication is not a major step
(although it will require protocol development)

3)      The third issue (raised by Antti) was whether an MPLS encapsulation
is needed at all.

If the problem is solved or going to be solved at all the server layers of
MPLS (Ethernet, OTN, SDH),

There was discussion as to what happens when the MPLS end-to-end path is
supported by a concatenation

of several disparate transport technologies, but since one of the trends is
hop-by-hop clock stabilization,

We did not reach full agreement on this point. Stewart warned that the
service provider may not have access

or even know what the underlying layer is, and warned participants not to
focus solely on the mobile backhauling problem.

4)      Yaakov started discussion of the encapsulation options, but there
was not enough time to present the topic.

5)      The chairs proposed to hold a conference call every third Tuesday of
the month at 8 AM Pacific time

(which corresponds to 11 AM East Coast time, 4 PM UK, and usually 6 PM
Israel time).

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 26 Sep 2010 19:07:11 +0200

Michel

I missed the discussion on the IP awareness (I had to leave for a few minutes to reschedule my next meeting).
Can you summarize it in a sentence ?

I will write something for the network service requirements.

Y(J)S

From: Michel Ouellette [mailto:[email-masked]]
Sent: Friday, September 24, 2010 17:47
To: Yaakov Stein; [email-masked]
Subject: RE: [TICTOC] draft minutes of TICTOC WebEx conference

Yaakov,

-        There was another general discussion in item#3 about the fact that there might not be any IP awareness in the data path, and as such a PTPoMPLS mapping and detection might be required
-        There was another item raised on the "network service" discussion: the techniques to do so must be identified as well as requirements and constraints

Bye.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: September 24, 2010 05:18 AM
To: [email-masked]
Subject: [TICTOC] draft minutes of TICTOC WebEx conference

Hi all,

Y(J)S

Participants :

The main reasoning was :

Y(J)S

---

From: Stefano Ruffini <[email-masked]>
Date: Mon, 27 Sep 2010 09:38:15 +0200

Hi Yaakov,

I think on eimportnat aspect that was also mentioned is :

- It was noted that when there is a Boundary Clock in every node (i.e. PTPpackets are terminated in each node), there might not be the need for specific MPLS support  (e.g. encapsulation options). This assumption is true also in case of MPLS-TP assuming multicast is used.

Best Regards
Stefano

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: venerdì 24 settembre 2010 11.18
To: [email-masked]
Subject: [TICTOC] draft minutes of TICTOC WebEx conference

Hi all,

Y(J)S

Participants :

The main reasoning was :

Y(J)S