Subject: Re: [TICTOC] draft minutes of TICTOC WebEx conference

From: [email-masked]
Date: Tue, 28 Sep 2010 13:51:45 +0800

Hi Yaakov and all,
Unfortunately, I have not attend this meeting. From the minutes below, is 
it possible, a boundary clock (not in every node) might require MPLS to 
support multicast with co-routed reverse path which has been presented at 
IETF78 on TICTOC? Actually this is the only thing I can see now.

BR
Lizhong

----------------------------------------------------------------------

Message: 1
Date: Mon, 27 Sep 2010 09:38:15 +0200
From: Stefano Ruffini <[email-masked]>
Subject: Re: [TICTOC] draft minutes of TICTOC WebEx conference
To: Yaakov Stein <[email-masked]>, "[email-masked]"
                 <[email-masked]>
Message-ID:
 <[email-masked]>
 
Content-Type: text/plain; charset="iso-8859-1"

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,

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://www.ietf.org/mail-archive/web/tictoc/attachments/20100927/eb38920d/attachment.htm

------------------------------

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.